Journeys Through Search

Salesforce data migration best practicesThe rules that keep your old data trustworthy after the move.

A load that runs without errors can still be wrong: contacts on the wrong account, dates reset to the load day, statuses spelled three ways. These are the rules we follow on every Salesforce load, so what lands in your org matches what you had, and your reports still add up.

  • Salesforce built to fit the data before a row is loaded
  • An External ID on every record, a mapped value for every picklist
  • Sandbox first, automations paused, results checked against the source

900+ integrations completed · Salesforce partner · We sign BAAs

The order we hold to

  1. 1
    Decide

    What comes over, what gets archived, and who owns old records

  2. 2
    Prepare

    Target fields and objects built, data cleaned and mapped

  3. 3
    Prove

    Sandbox load checked by your team, then production, then a side-by-side check

Why Salesforce data migration best practices matter more than the tool

Every Salesforce load tool does the same job: it takes rows and writes records. What goes wrong is upstream. A field that does not exist yet, a value the picklist will not take, a parent that was loaded after its children. Best practice is mostly about the order of decisions.

So we start with the target. Fields, record types, picklist values and any custom objects exist in Salesforce before the data arrives. Salesforce can be changed in any way, so data that has no natural home gets one, built for it, instead of being pushed into a notes field.

Then every record gets its old system ID, every picklist value gets a mapped value, and every owner and created date gets a rule. Once those are written down and signed off, the load is the predictable part.

What's included

What Salesforce data migration best practices includes

Using Salesforce External ID for data migration

A custom field marked External ID holds each record's ID from the old system. Child rows point to their parent by that ID, so links are built by the load itself, and an upsert on it means a second run updates instead of duplicating.

One External ID per source

An old CRM, an EMR and a phone system each get their own ID field, so two systems that both use "1001" cannot collide.

Salesforce data migration picklist mapping

Every distinct source value listed and matched to a Salesforce value. Restricted picklists reject unknown values; unrestricted ones accept them and split your reports. Both are handled before the load.

Picklists in step everywhere

Web forms, chat and integrations send the same values Salesforce holds, so lead conversion does not fail on a value that only exists on the form.

Owners decided up front

Records stay with people who have left, as inactive users, or move to a current owner with the original name kept. The rule is written per object.

Created dates kept

Original dates set on insert, or held in an "Original Created Date/Time" field, so aging and trend reports stay true.

Duplicates stopped twice

Merged before the load, and duplicate rules on phone and email set up so new ones are caught after it.

Files in file storage

Attachments loaded as Salesforce Files, which count against file storage, not data storage.

Automations paused and restored

Flows, triggers, validation rules and connected apps that would fire on old records are turned off for the load and back on after, with a check that they work.

Proof before switching

Counts by object, sample records side by side, and key reports compared with the old system. See the full Salesforce data migration checklist.

Works with

All Salesforce integrations

Every system we connect to Salesforce, in one list

Call tracking

CallRail and CallTrackingMetrics native integrations, with recordings and AI call summaries on the lead

Web forms

Gravity Forms, Jotform and Typeform fills create leads with tracking attached

Chat and texting

LiveChat, SnapEngage, Tawk.to and Avochato conversations saved to the lead

EMR

Kipu and Sunwave: admissions in Salesforce, clinical in the EMR, kept in step

Billing and financial

CollaborateMD, AdvancedMD and HiLite, with insurance payments on the patient

Payments

Stripe, PayTrace and PayPal payments recorded on the opportunity

Ad platforms

Google Ads, Microsoft Ads, Meta and TikTok leads in, offline conversions out

Email marketing

ActiveCampaign lists and automations that follow Salesforce

Single sign-on

Open other systems from the Salesforce record with SSO

Reporting

Salesforce data in Google Sheets, BigQuery and Looker Studio

Anything with an API

No app for it? We build the connection with Apex and the APIs

Want these rules applied to your migration?

Book a free call. We look at your sources and your Salesforce org, point out where a load would go wrong, and tell you how we would run it. No obligation.

Book a free call →

What clients say

900+ integrations completed
The JTS team are extremely knowledgeable when it comes to advertising attribution and maximizing the potential of customer and leads. They know software extremely well, and how all the pieces fit together perfectly. I highly recommend his services to anyone looking to streamline their technology and maximize their sales potential.
Jason Landver
CEO, Recovery Beach
I have been thoroughly impressed with the results. JTS team expertise in systems and software integration has given me clear and concise reports, they help me also with generating qualified leads, has been instrumental in driving my business forward. Thank you for everything you have done for my business.
Mike Kwak
On-Site Adjusting
For the past five years, Journeys Through Search has been an incredible marketing company to assist in our PPC, web development and support. Quick responses, vast knowledge and marketing creativity made them such a value add to our organization.
Tarra Boggs
EHS & Compliance Operations Manager

How it works

How Salesforce data migration best practices works

  1. 01

    Free call

    Your sources, your objects and the questions that need a decision, like owners and created dates.

  2. 02

    Project quote

    Priced by project, not by the hour. You approve before we start.

  3. 03

    Map, build and test

    The mapping sheet signed off, the target built, and a sandbox load you check.

  4. 04

    Load and prove it

    Production loaded with automations paused, checked against the source, automations back on.

Working with us

Salesforce data migration best practices FAQ

Which Salesforce data migration best practice matters first?

Keep the old system ID on every record in an External ID field. It links related records, makes reloads safe and lets anyone trace a record back to its source.

Do I need a separate External ID field for each source?

Yes. IDs from two systems can overlap, so each source gets its own field, named for that source.

What happens to picklist values that do not exist in Salesforce?

On a restricted picklist the row fails. On an unrestricted picklist the value goes in but sits off the list. We map every value first, merging old values that mean the same thing.

Should we clean data before or after the load?

Before. Merging duplicates and fixing formats in the source files is far easier than fixing them record by record in Salesforce.

Is there a template we can follow?

Yes. Our mapping sheet template is described on the Salesforce data migration template page, and we walk you through it on a free call.

How is it priced?

By project, not by the hour. The first call is free, and you get a project quote after it.

Related