A lesson learned the hard way, and one I now consider a non-negotiable step in any migration playbook. The conventional wisdom is to secure a final, validated export from your *source* system before the migration cutover. This is, of course, correct. However, a critical and often overlooked step is to create a second, immutable "golden copy" export from the *old* system *after* you have declared the migration complete and the new system live.
The rationale is twofold, pertaining to data lineage and contractual disentanglement:
* **The Source System Continues to Operate:** During your migration window—which could be a weekend or a series of phased cutovers—the legacy CRM is often not fully decommissioned. Support teams may create "just one more" ticket, a sales rep might log a last-minute call, or an automated workflow may still fire. Your migrated data is now instantly outdated. The golden copy serves as the definitive system of record for the *exact* state of the old platform at the moment of decommissioning, which is frequently different from the state at the moment your primary extract ran.
* **Legal and Audit Requirements:** When you terminate your contract, your access to the legacy SaaS platform will be revoked, typically within 30-90 days. If a data quality issue surfaces six months later—perhaps a missing custom field on key accounts or corrupted activity history—you cannot go back. Having a independently stored, verifiable export allows you to perform forensic data comparison without relying on the vendor. It is your only source of truth.
In a recent Salesforce to HubSpot migration I oversaw, this practice proved invaluable. Post-migration, we discovered a discrepancy in opportunity stage history for a subset of records. Our migration scripts had correctly moved the data, but a timestamp interpretation issue in the new system created a sequencing problem. Because we had the golden copy from the day after cutover, we were able to:
* Isolate the 427 affected records definitively.
* Verify the correct sequence of stage changes from the source, without needing Salesforce login credentials (which had already been reclaimed by the IT security team).
* Build a targeted remediation script in HubSpot using the golden copy as the reference data, rather than initiating a costly and disruptive partial re-migration.
The procedure I now mandate is as follows:
1. After final user sign-off on the new system and the disablement of all write functions in the legacy system, schedule a final, comprehensive data export.
2. Use the vendor's native export functionality (e.g., Salesforce Data Loader, Microsoft Dynamics 365 Data Export Service) to ensure schema fidelity.
3. Generate and store SHA-256 checksums for all exported data files.
4. Archive the entire export package—data files, checksums, and a manifest file noting the exact date/time and extraction method—to a secure, immutable cloud storage location with restricted access, separate from your operational backups.
This is not a backup of the migration. It is a historical artifact of the source system, and it is the single most important piece of evidence you can possess if post-migration data disputes arise. The minor additional effort pales in comparison to the cost of uncertainty.
—Anna
Migrate slow, validate fast.