The cost of a failed migration isn’t just lost data — it’s lost trust in the system that inherited it. A migration that technically "completes" but leaves duplicate accounts, broken relationships, or silently dropped records does more damage than a migration that takes an extra two weeks and gets reconciliation right. Here’s the checklist I run every migration against, phase by phase.
Phase 1 — Pre-migration planning
- Data audit and quality review. Know what’s actually in the source system before deciding how to move it — duplicate rates, null-field rates, and orphaned records are easier to fix before migration than after.
- Validation rules setup. Decide which validation rules apply during load versus after — a rule that’s correct for ongoing use can block a legitimate historical record during import.
- User communication plan. The business needs to know what’s changing and when, especially if there’s a freeze window on the source system during extraction.
Phase 2 — Extraction & transformation
- Data Loader configuration for standard-volume loads, with field mappings documented and reviewed before the first test run.
- API preparation for higher-volume loads — bulk API batching, governor limit planning, and a realistic timeline for the actual load window.
- Deduplication strategy decided and tested before anything touches the target system — deduplicating after load means untangling relationships that have already been created.
Phase 3 — Validation & rollback
- Pre-load testing in a sandbox using a representative data sample, not just a handful of clean test records.
- A documented rollback plan — know exactly how to undo a load before you run it in production, not after something goes wrong.
- Stakeholder sign-off on the sandbox results before production load — the business owner should see and approve a sample of migrated records, not just a summary count.
Phase 4 — Cutover
- Final load executed against the plan agreed in Phase 3, not an improvised variant of it.
- Real-time monitoring during the load window — someone watching for errors as they happen, not reviewing a log after the fact.
- A plan for handling issues that surface mid-load, including a clear threshold for pausing versus pushing through.
Phase 5 — Post-migration
- Validation verification against the source — record counts and spot-checks that confirm the target system actually matches where it should.
- User training on anything that changed — a migration that moves the data but not the team’s understanding of it creates its own support burden.
- A monitoring period before calling the migration complete — issues from a large migration often surface in the first few weeks of real usage, not on day one.
Checklist template
A condensed, printable version of this checklist — ready to hand to a project team — is available on request; ask on a consultation call and I’ll send it over.
Worried about your data migration? A 30-minute call is usually enough to tell you where the real risk is in your specific move.