A Salesforce data migration is won or lost before the first load. The loading tools exist and do their job. What is usually missing is the decisions: who owns each object, which count proves nothing is missing, how many rehearsals come before the real cutover, and who says go or roll back.
“Zero data loss” appears in many requirement documents. Until someone has written down what the phrase covers and who checks it, it cannot serve as an acceptance criterion.
Three kinds of loss, three kinds of proof
Physical loss is the simplest: a record that exists in the source does not exist in the target. A count per object, source against target, catches it.
Semantic loss passes that count. The record is there, but its meaning has changed: a Status value mapped to the wrong target, a parent-child relationship reversed, a currency converted wrongly. Only someone who knows the business will spot it, on a sample chosen for its edge cases.
Context loss passes both checks. The values are right, but the original owner, the creation date or the history were overwritten during the load. On personal data this is also a GDPR question, which data quality alone does not settle.
Each kind of loss needs its own proof and its own signatory. A programme that produces only counts has dealt with the first and left the other two to production.
One owner per object, before the first load
Ownership comes before every other decision. For each migrated object (Account, Contact, Opportunity, Case, custom objects), one person from the business answers for the transformation rules, for what happens to orphan records, and for the key that reliably identifies a record.
The project team can propose the transformation rules. Approving them belongs to someone who knows what a status or an account type means in the business. When the rules live in one consultant’s head or in a script nobody reviewed, semantic loss becomes likely.
Orphans (contacts without an account, opportunities whose owner has left, tasks attached to deleted records) cannot be migrated as they are. Archive, delete or attach to a generic record: that is a business decision, and it takes time. Taken during the load, it stalls the plan.
Salesforce record IDs do not carry over from one org to another. Relationships between records are rebuilt with business keys: a customer number, a product code, a contract reference. If those keys are missing or unreliable in the source, cleansing comes first, and the object owner decides which key is authoritative.
On the Sanofi programme (a Cognizant client, 2021-2022), six systems were migrated into a single Salesforce org. The control model rested on explicit source-to-target mappings, reusable templates for mappings and checks, reconciliation controls, and stop conditions that surface discrepancies before acceptance. With six sources, the question “which source is authoritative for this customer?” has to be settled before any load. The tool does not answer it.
Reconciliation gets signed
A reconciliation report nobody signs stays a technical document. For each batch the programme produces source and target counts per object, the rejects with their reason, and the accepted exceptions. The business owner of the object signs that report, not the team that loaded the data.
The acceptable error threshold is set before the project starts, object by object, as a number of records rather than a percentage. A rate that looks small on a large volume is thousands of records, each with a customer or a contract behind it.
Semantic checks need a reference set: representative records chosen with the business to cover edge cases (complex relationships, multi-select fields, long histories). Business reviewers check it by hand after each rehearsal. No automated control replaces that review for semantic loss.
Data is not the only thing at stake. An Account loaded correctly can trigger a Flow that fails because a record type was renamed in the target. The automations, validation rules, profiles and integrations that touch migrated objects belong in the test scope. The note on Salesforce technical debt describes how those dependencies build up.
Rehearse, freeze, decide
A cutover is rehearsed. A full rehearsal, on a realistic volume in an environment close to production, gives what the plan cannot: the real load duration and the time business reviewers need to validate. Those durations set the cutover window.
During the migration the source goes read-only, or every change is logged so it can be replayed in the target. Without a freeze or a delta mechanism, migrated data is stale the next morning. The freeze date is a business decision, because business teams are the ones who stop entering data.
Rollback is decided in advance. The plan describes how to return to the starting state if the load fails halfway, and it has been tested in a sandbox. It also sets a decision point: the time in the cutover window after which rollback is no longer possible, and the criteria that force it before then.
That leaves the go decision. The sponsor or the programme owner makes it on the basis of signed reports, not the integrator on the basis of its plan. If that name is not written down before the dress rehearsal, the decision will be made at two in the morning by the most tired person in the room.
What to check
- Every migrated object has a named business owner who approves the transformation rules and the fate of orphans.
- “Zero data loss” is defined in writing: orphans, activity history, attachments and encrypted fields included or excluded.
- Error thresholds are set per object, as a number of records, before the first load.
- A full rehearsal has run, and its durations set the cutover window.
- The rollback plan has been tested, and its cut-off time is in the cutover plan.
- The name of the person who says go is written down.