Salesforce Migration Testing
Salesforce migration testing proves that what arrives in Salesforce is complete, correct and usable before users depend on it. Whether records and configuration are moving from a legacy CRM, a homegrown database or another Salesforce org, the load finishing without errors is not the same as the migration succeeding. Records can load while relationships, owners, history and the processes that act on them quietly break.
A SyntraFlow Salesforce testing use case. Capabilities described here are available for demonstration and proof-of-concept validation.
The situation
A migration is one of the few Salesforce projects with a single, unforgiving moment: cutover. Before it, users work in the old system. After it, years of customer history, open opportunities, active cases, contracts and entitlements must be in Salesforce, attached to the right accounts and owners, and ready for the business processes built on top of them.
Migrations come in several shapes. A legacy CRM such as Microsoft Dynamics 365, Siebel or a homegrown application is retired in favor of Salesforce. Two or more Salesforce orgs are consolidated after an acquisition or reorganization. A single org is split for a divestiture. An organization moves to a different Salesforce data model, such as from the Nonprofit Success Pack to Nonprofit Cloud, or from Classic-era custom objects to an industry cloud. Each involves extracting, transforming and loading data, usually through Data Loader or the Bulk API with external IDs, and re-establishing the configuration and integrations that depend on it.
This use case covers testing that migration: the data itself, the mappings that transform it and the processes that must work on it once it lands. Building the new org's features is covered by implementation testing, which often runs alongside.
Typical triggers
Migration testing becomes necessary in situations like these.
Retiring a legacy CRM
Customer, sales and service history is moving from an older platform into Salesforce, with the old system being switched off.
Consolidating orgs
An acquisition or reorganization means merging two Salesforce orgs with overlapping accounts, users, picklists and automation.
Splitting an org
A divestiture requires separating records, users and configuration cleanly without leaving data behind or taking too much.
Changing data models
Moving to an industry cloud or a new product such as Nonprofit Cloud requires mapping existing objects into a different structure.
Replacing a connected system
An ERP, billing or marketing platform is replaced, and the Salesforce data and integrations that depended on the old one must be re-pointed.
Archiving and cleanup
Large volumes are being moved out of Salesforce or restructured to address storage and performance, and what remains must still work.
What is at risk if it goes wrong
The most damaging migration defects do not produce load errors. Contacts attach to the wrong account because a legacy key was reused. Opportunities lose their owners because inactive users were not mapped. Picklist values are transformed into defaults, so every migrated case shows the same priority. Currency amounts are converted twice. Activity history is loaded without its parent links. Created dates reset to the load date, and reports built on age or tenure become meaningless.
Process defects follow. Automation that was switched off for the load is not switched back on, or is switched on too early and fires thousands of emails and assignment rules against historical records. Sharing recalculation leaves users unable to see records they owned. Integrations begin sending migrated records to downstream systems as if they were new. Once users start working in the new system, correcting any of this means repairing live data under business pressure, and trust in the new platform is lost at the moment it most needs adoption.
What migration testing has to reconcile
Layers of verification, from simple counts to working processes. Each layer catches defects the previous one cannot; the mechanics of comparing systems are covered on data reconciliation testing.
| Layer | What is checked | Defects it catches |
|---|---|---|
| Record counts | Source versus target counts per object and per segment, accounting for intentional exclusions | Rows dropped by filters, failed batches or rejected by validation rules. |
| Field values | Field-by-field comparison on samples and aggregates such as sums of amounts | Truncation, encoding problems, wrong picklist mapping, double currency conversion. |
| Relationships | Lookups and master-detail links, account hierarchies, junction objects, via external IDs | Orphaned child records and records attached to the wrong parent. |
| Ownership and audit fields | Record owners, queues, created and last-modified dates where preserved | Records owned by the migration user and history dates reset to load time. |
| Files and history | Attachments converted to Files, notes, emails and activity timelines | Missing documents and activities disconnected from their records. |
| Access | What each role and profile can see after sharing recalculation; see role hierarchy testing | Users unable to see their own records, or seeing records they should not. |
| Business processes | End-to-end journeys run on migrated records, not only on new ones | Validation rules, Flows and approvals that fail on legacy data shapes. |
Teams involved
Migration quality is shared between people who know the old data and people who know the new platform.
Data migration lead
Owns the extract, transform and load design, mapping documents and load sequence.
Salesforce architect and admins
Own the target data model, automation bypass strategy, sharing and the configuration the data must fit.
QA and test engineering
Build reconciliation checks and process tests and run them after every mock load.
Business data owners
Confirm mapping rules, sign off samples of their own records and define acceptable exclusions.
The SyntraFlow approach
SyntraFlow is designed to treat a migration as something to rehearse and measure, not a one-time event. Reconciliation checks between the source and Salesforce are defined once and rerun after every mock load, so each rehearsal produces a comparable result and the team can see defects falling toward zero. Where the source is another system such as an ERP or legacy database, SyntraFlow can be configured to query both sides in the same run.
Data checks are paired with process tests on migrated records: converting a migrated lead, progressing a migrated opportunity, working a migrated case, renewing a migrated contract. Legacy data rarely has the same shape as data created through the new user interface, and that is where Flows and validation rules fail. For org consolidations, org comparison helps identify configuration conflicts before data moves.
A migration testing workflow
A rehearsal-based sequence that builds confidence before cutover.
Agree mappings and acceptance criteria
With business data owners, confirm field mappings, value translations, exclusions and the reconciliation thresholds that define success.
Build reconciliation and process tests
Define count, value, relationship, ownership and access checks, plus process tests that operate on migrated records.
Run a mock load into a full-size sandbox
Load a representative or full volume using the planned tools, automation bypass and load order, and time each step against the cutover window.
Reconcile and triage
Run every check, classify failures as mapping, transformation, load or configuration defects, and fix at the source rather than patching target data.
Repeat until stable
Rerun mock loads until results meet the acceptance criteria and load timings fit the cutover plan.
Validate cutover in production
After the production load, run the reconciliation suite and smoke tests on key journeys before automation, integrations and users are switched on.
Monitor the first days live
Keep running process tests and reconciliation on delta loads until the legacy system is fully retired.
Test data and environments
In a migration, the production data is the thing under test, which creates a tension: rehearsals need realistic volume and real data shapes, but sandboxes should not hold more sensitive data than necessary. A full copy sandbox gives the storage and performance characteristics needed to time loads, while masking protects personal and financial fields; SyntraFlow can be configured to apply data masking that preserves formats and relationships so reconciliation still works.
Legacy data also contains the edge cases that break migrations: accounts with thousands of contacts, records with no owner, invalid emails, picklist values that no longer exist and duplicates across source systems. Test sets should include these deliberately, and a few named records per segment should be traced by business owners from source to target.
Deliverables and expected outcomes
What a tested migration hands to the go-live decision.
- Signed-off mapping and acceptance criteria covering fields, values, exclusions and reconciliation thresholds.
- A reusable reconciliation suite with results from every mock load, showing defect trends toward cutover.
- Process test results proving critical journeys work on migrated records, not only new ones.
- Access test results confirming users see the right records after sharing recalculation.
- Measured load timings that fit the cutover window, with a rehearsed sequence for re-enabling automation and integrations.
- Post-cutover reconciliation and smoke results that support the decision to retire the legacy system.
- Qualitative outcomes: a go-live backed by evidence, fewer data repairs after launch and faster user adoption.
Related pages
Use Cases hub
Every Salesforce testing scenario SyntraFlow supports, organized by situation.
Salesforce implementation testing
Proving the new org's features alongside the migrated data.
Data reconciliation testing
Comparing records between Salesforce and source systems.
Bulk API testing
Validating the high-volume load path most migrations use.
Org comparison
Finding configuration conflicts before consolidating orgs.
Data masking
Rehearsing with realistic volume without exposing sensitive fields.
Migration Testing testing FAQs
What is Salesforce migration testing?
It is testing that proves data and configuration moved into Salesforce, from a legacy system or another org, are complete, correctly mapped and usable by the business processes that depend on them. It covers reconciliation of records and relationships as well as process and access testing on migrated data.
Why is a successful load not enough?
A load can succeed while records attach to the wrong parent, owners map to the migration user, picklist values default, dates reset or automation fires on historical records. None of these produce load errors, so they must be found by reconciliation and process tests.
How many mock loads should we run?
Enough that reconciliation results meet the agreed thresholds and load timings fit the cutover window consistently. Many programs plan at least two or three rehearsals, but the right number depends on data complexity and how quickly defects converge.
How should automation be handled during a migration load?
Most teams bypass Flows, triggers, validation rules and assignment rules during the load using a custom setting, custom permission or deactivation, then re-enable them in a rehearsed sequence. Testing must confirm both that automation did not fire during the load and that it works correctly once it is re-enabled.
Can created dates and owners from the legacy system be preserved?
Salesforce allows audit fields such as created date and created by to be set on insert when the Set Audit Fields upon Record Creation feature is enabled and the loading user has the permission. Owners can be set directly if the users exist. Testing should confirm the values were preserved where the design requires it.
Is moving from NPSP to Nonprofit Cloud a migration?
Yes. Salesforce positions it as a reimplementation on a different data model rather than an upgrade, so it needs mapping, reconciliation and process testing like any other migration. See Salesforce testing for nonprofits for the sector context.
Go live on data you can prove
See how SyntraFlow reconciles migrated records and tests the processes that depend on them before cutover.