Start with what “done” means
Every migration plan should begin by agreeing how the business will judge success. “All the data is in Salesforce” is not a test anyone can pass. “Every active customer, with their open opportunities and the last three years of cases, owned by the right user, with totals that match the legacy system to the cent” is.
Write these acceptance criteria down per object, agree them with the data owners, and design everything else to prove them.
Profile the source before you map it
Source documentation is rarely accurate. Before mapping, profile the actual data: row counts, null rates, distinct values in picklist-like fields, duplicates, orphaned child records and the date range that really matters. On large migrations, rebuilding the structure of the source systems from the data itself is often faster and more reliable than relying on their documentation.
Profiling also forces the scope conversation early. Many migrations shrink dramatically once the business sees how much of the legacy data is closed, duplicated or no longer used.
Design the load, not just the mapping
A mapping document says where each field goes. A load design says how millions of records get there safely.
- External ID fields on every migrated object, so loads can be upserted, re-run and traced back to the source.
- A load order that respects relationships: users and reference data first, then parents, then children.
- A bypass for triggers, Flows and validation rules during loads, controlled by a setting rather than by deactivating automation in production.
- Bulk API for volume, with batch sizes tuned to avoid record locks on shared parents.
- A decision on audit fields: if created dates and owners must reflect the legacy system, the load user needs the “Set Audit Fields upon Record Creation” permission, which an admin first enables for the org in Setup, under User Interface settings.
- Sharing recalculation planned around the load window, because large ownership changes can recalculate for hours.
Reconcile at three levels
Reconciliation is how you prove the acceptance criteria. Do it after every rehearsal, not just on cutover weekend.
- Counts: records extracted, transformed, loaded and rejected, per object, with every rejection explained.
- Totals: sums of the values the business cares about, such as balances, amounts and quantities, compared between source and target.
- Samples: a set of real records, chosen with the business, checked field by field by the people who use them.
Rehearse until the cutover is boring
A full-volume rehearsal in a sandbox with production-like data shows how long each step really takes, which is usually longer than expected. Run at least one rehearsal end to end against the cutover plan, with the same people, and record the timings.
The cutover plan itself is a run sheet: every step, who owns it, how long it takes, and the check that must pass before the next step starts. It includes the freeze on the legacy system, the final extract, any delta loads, reconciliation, the go/no-go decision and the communication to users.
Be honest about rollback
There is rarely a clean “undo” for a large migration once users start working in the new system. Rollback has to be designed before cutover, with explicit limits.
Before go-live, rollback usually means not switching users over: the legacy system stays the system of record, and loaded records can be identified by their external IDs or a load batch marker and removed or reloaded. After go-live, the realistic options are fixing forward or replaying changes into the legacy system, and both get harder by the hour. That is why the go/no-go decision, based on the reconciliation results, is the most important checkpoint of the weekend.
Consolidations are migrations too
Merging two Salesforce orgs, or two products such as Financial Services Cloud and nCino, adds a harder question to every one of the steps above: which record wins when both systems hold the same customer. Settle survivorship rules, ownership and identifiers in the design phase, and treat data, automation, security and reporting as separate workstreams that are tested together.