How to plan a Salesforce data migration without go-live surprises
Key points
- Review a representative sample or full backup before fixing the migration budget and timeline.
- Agree which data belongs in Salesforce and which historic records can remain in secure storage.
- Map legacy fields and relationships to the correct Salesforce objects.
- Run several sandbox test loads and give business users time to review them.
- Rehearse the cutover and keep migration support available after go-live.
George Tye
CEO & Founder
What needs to happen before a Salesforce migration?
Data migration often gets one line in a Salesforce implementation plan. That line can conceal weeks of discovery, mapping, testing and client decisions.
Older systems reflect years of changes and workarounds. Fields may be used differently from their original purpose. The same person may appear several times. Information that looks complete on screen may rely on hidden relationships or values stored elsewhere in the database.
Until someone reviews a sample or backup, there is no reliable way to judge how much work the migration will require.
Migrate Data begins its Salesforce data migration projects by looking at the source data and asking the client how it is used. This gives both teams a clearer picture of the scope before the final schedule is agreed.
The five stages of a Salesforce data migration
1. Discovery
Discovery begins with the source systems, the available backups and the way people currently use the data.
Migrate Data reviews a representative sample or full backup to identify issues that could affect the scope. These may include:
- Duplicate records
- Missing values
- Inconsistent field formats
- Damaged or unclear relationships
- Unexpected data sources
- Historic records that may no longer be needed
- Differences between the documented database structure and its actual use
The client also needs to explain which information matters to each department. A field that appears redundant to an external analyst may still support an important report, fundraising process or service history.
This review gives the project team evidence for its initial budget and timeline. It also identifies decisions that need to be made before mapping begins.
2. Data Quality Review and mapping
A Data Quality Review, or DQR, examines the source data for gaps, duplicates and conflicting criteria.
The review does not assume that every issue has one automatic solution. Some duplicates can be merged confidently. Others need input from the client because the records contain conflicting details or represent people with similar names.
Mapping then establishes where the agreed data will sit in Salesforce.
Depending on the implementation, this may include:
- Accounts
- Contacts
- Opportunities
- Cases
- Custom Objects
- Salesforce Nonprofit Cloud structures
Each source field needs a destination, a transformation rule or an agreed reason for exclusion.
Relationships require particular care. A donation has limited value without the correct donor and campaign. A Contact may need to remain connected to an Account, activity history or recurring payment. Moving the individual records while losing those connections leaves Salesforce with an incomplete version of the original data.
3. Sandbox test loads
Migrate Data runs several test loads into a Salesforce sandbox before the live migration.
The first load often reveals questions that could not be answered from the source system alone. A value may fit the agreed mapping but display badly in Salesforce. A relationship may load correctly but behave differently in a new workflow or report.
Each test cycle gives the migration team an opportunity to correct those issues and load the data again.
Client review is essential during this stage. Technical checks can confirm that records loaded successfully and totals match the agreed scope. Business users need to confirm that the information makes sense in practice.
They should be able to answer questions such as:
- Can we find the people and organisations we work with?
- Are their histories complete?
- Do recurring donations and active opportunities appear correctly?
- Can our reports use the migrated fields?
- Are important files and notes still connected to the right records?
- Does the data support the workflows planned for Salesforce?
Time for this review needs to appear in the implementation plan. If department heads first inspect the migrated data shortly before launch, essential corrections become last-minute change requests.
4. Go-live
The final import should follow a process already exercised during the sandbox loads.
Before the cutover, the project team agrees:
- When changes to the legacy system will stop
- When the final backup will be taken
- The order in which the data will be loaded
- Which checks will be completed after the import
- Who will review the result
- Who can approve the migration for general use
- How urgent issues will be reported and handled
Rehearsal makes the duration and dependencies of the final migration easier to predict. It also gives the team a known process to follow if an issue appears during the cutover.
5. Post-migration support and legacy storage
Users may uncover unusual records once they begin working in Salesforce. Post-migration support gives them a clear route for raising those cases while the migration team still has the project context.
The original backup also needs an agreed home.
Some organisations attempt to place their entire legacy history in Salesforce because they are worried about losing access to it. This can fill the live system with obsolete records and make the migration more complicated than necessary.
Secure legacy storage preserves the original information while allowing Salesforce to contain the data people need for current work. Retention requirements and access arrangements should be agreed as part of the migration plan.
"Their meticulous planning and execution made the transition to Salesforce Nonprofit Cloud a success."
A Salesforce migration from Raiser’s Edge to Nonprofit Cloud
One Migrate Data project involved a healthcare charity moving its full legacy database from Blackbaud Raiser’s Edge into Salesforce Nonprofit Cloud.
The database contained complex donor histories, campaign information and relationships between different types of records. The migration also had to fit within a tight implementation timetable.
Sample analysis before the full migration
The project began with an analysis of sample data.
This identified the likely complexity before the full backup was supplied and gave the client an initial view of the expected cost and timeline.
Once the complete backup became available, the estimate could be refined using the actual database rather than the sample alone.
Mapping donor and campaign data
The data was categorised and mapped to the appropriate Salesforce objects and relational structures.
Donor histories needed to remain connected to the correct people, campaigns and transactions. Preserving those relationships required more than matching individual field names between the two systems.
Several sandbox test loads
Multiple test loads gave the client time to inspect the migrated data and explain where changes were needed.
Feedback from those reviews was incorporated into the following load. By the time the final import took place, the client had already seen how its data would appear and behave in Salesforce.
Support after the final import
Migrate Data remained available for final adjustments after go-live.
The original backup was also placed in secure storage, giving the charity continued access to its legacy information without loading every historic record into Salesforce.
Migration decisions that need to be tested against the data
Rules that look sensible in a meeting can create unexpected results when applied across connected records.
For example, a rule excluding older Accounts may also remove the context for current Contacts or active payments. A duplicate-matching rule may merge two people who share a name but have different addresses and supporter histories.
Testing the proposed rules against real data shows where these exceptions exist.
| Decision | What needs to be checked | Possible consequence |
|---|---|---|
| Exclude historic Accounts | Are current Contacts, files or transactions still linked to them? | Useful records may lose their context or be excluded with the Account. |
| Merge duplicate Contacts | Which fields reliably identify the same person? | Separate people may be merged or genuine duplicates may remain. |
| Populate required Salesforce fields | Does every relevant source record contain a usable value? | Records may fail to load or require an agreed default. |
| Migrate attachments | Will the related parent records also be migrated? | Files may become inaccessible or lose their meaning. |
| Transform source values | Do reports and workflows rely on the original categories? | Segmentation, automation or reporting may produce different results. |
| Exclude older transactions | Are they needed for histories, totals or retention requirements? | Salesforce may show incomplete histories or figures that do not reconcile. |
The results may lead to a revised rule, an exception process or a client decision about what should remain in legacy storage.
What changes when data issues appear late?
When data issues are discovered late, they rarely remain isolated technical problems. They begin affecting the wider implementation.
The original estimate stops being useful
A budget based on record counts alone cannot account for damaged relationships, unexpected sources or extensive client decisions.
If these are discovered after the implementation schedule has been fixed, the project either needs more time or has to reduce its scope.
Testing time gets squeezed
A late first test load leaves little room for review and correction.
The migration team may be able to fix a technical mapping quickly, but client users still need time to check whether the result works for their departments.
Connected data arrives incomplete
Accounts, Contacts, donations, opportunities, files and activities may all load successfully as individual records while their relationships remain wrong.
These errors are easy to miss if validation focuses on record counts alone.
Users begin with unreliable information
People form an opinion of a new CRM quickly.
Missing histories, obvious duplicates and totals that do not match the previous system give users a practical reason to distrust Salesforce. Correcting the data later does not immediately restore that confidence.
Why does Salesforce migration planning get left until the end?
Salesforce implementation plans tend to focus on configuration, integrations, workflows, reporting and training.
Migration can appear to be the final import that fills the completed system. Its complexity remains difficult to see while everyone is discussing “the database” as though it were one consistent set of records.
The source review usually changes that understanding. It shows which departments use different definitions, which relationships need to be preserved and where earlier decisions have left gaps in the data.
Migration planning needs to happen early enough for those findings to influence the implementation.
When should migration planning begin?
Begin once the organisation can provide a representative sample and has enough information about the intended Salesforce environment to discuss its main objects and processes.
Every Salesforce field does not need to be finalised at this stage. Early migration work can still establish:
- Which systems are in scope
- The condition of the source data
- Which teams own important decisions
- Where cleansing may be required
- How much user validation will be needed
- Whether legacy storage forms part of the solution
- Which dates or business events affect the cutover
The mapping can then develop alongside the Salesforce configuration rather than being forced into the end of the project.
What does the client team need to provide?
Migration specialists can analyse, map, transform and test the data. Several decisions still belong to the organisation that created and uses it.
A Salesforce migration project needs:
Someone who understands the data
The project should have a data owner who can explain how fields are used, identify the right department for a question and make or escalate decisions.
Access to representative source data
A sample or backup gives the migration team something real to analyse. Screenshots and database documentation rarely expose the full condition of the records.
People who can review test loads
Department heads and end-users should be given specific areas to validate. Asking everyone to “check the data” tends to produce inconsistent feedback and missed issues.
Clear retention requirements
The team needs to know which historic records must remain available, how quickly they may need to be accessed and whether they belong in Salesforce or secure legacy storage.
Important project dates
Campaigns, reporting periods, financial processes and other operational commitments may affect when data can be frozen and when the final migration can take place.
How Migrate Data manages Salesforce migrations
Migrate Data has spent 30 years working specifically with data, including migration, cleansing, quality and legacy storage.
Salesforce projects are handled by a UK-based team, with dedicated analysts assigned to the relevant legacy systems. Regular project calls keep decisions, issues and client feedback visible throughout the work.
The company’s “Unity Through Data” approach focuses on the condition and usefulness of the information after migration. In practice, this involves agreeing the right scope, resolving quality problems, preserving relationships and testing the data with the people who will use it.
Organisations with several source systems, complex histories or a limited window for go-live can find out more about Migrate Data’s Salesforce migration service.
Frequently Asked Questions
How long does a Salesforce data migration take?
Most projects take between a few weeks and a few months.
The source systems, data quality, relationship complexity and client review process all affect the timeline. Reviewing a sample or full backup provides the evidence needed for a more accurate estimate.
What data can be migrated into Salesforce?
Most structured business data can be migrated, including Accounts, Contacts, Opportunities, Cases and Custom Objects.
Salesforce Nonprofit Cloud migrations may also include donor histories, campaigns, recurring payments and other fundraising information.
Does all historic data need to move?
Historic data can be archived or excluded under agreed rules.
The decision depends on its current value, retention requirements and the frequency with which people need to access it. Secure legacy storage can keep older information available without placing it in the live Salesforce environment.
What is a Data Quality Review?
A Data Quality Review examines the source data for missing values, duplicates, inconsistent formats, broken relationships and conflicting criteria.
Its findings inform the cleansing, mapping and exception rules used during the migration.
Why are several sandbox loads needed?
Each load gives the migration team and the client another opportunity to test the agreed rules.
Issues found during review can be corrected and included in the next load before the final Salesforce environment is populated.
Who should review the migrated data?
Migration specialists complete technical checks, including record counts, load errors and mapping validation.
Client data owners and end-users review whether the information is complete, understandable and suitable for their day-to-day processes.
What happens if an issue is found after go-live?
Post-migration support covers unusual records or issues found once users begin working in Salesforce.
The discovery and sandbox stages should resolve broader problems before launch, leaving post-go-live support to handle exceptions and final adjustments.
Planning a Salesforce data migration?
Speak with a Migration Expert
Migrate Data can review a sample of your source data, identify the main migration risks and provide a clearer basis for the project scope, budget and timeline.