A data migration checklist is the structured set of steps an organisation works through to move data safely from a source system to a target system, covering planning, mapping, quality checks, testing, cutover, and post-migration validation. Skipping steps in this sequence — particularly mock runs and reconciliation — is the single biggest cause of failed or delayed cutovers.
Before Migration: Planning and Preparation
Before working through this checklist, make sure you’ve settled on a migration strategy — big bang or phased — since that choice shapes how several of these steps get executed.
Define Scope and Success Criteria — Agree what’s actually migrating, what “done” looks like, and who signs off at each stage.
Source-to-Target Mapping — Document, field by field, how source data maps to the target system’s structure. This needs business sign-off, not just technical review.
Data Quality Assessment and Cleansing — Profile the source data to identify duplicates, missing mandatory fields, and orphaned records before migration, not during it.
During Migration: Build and Test
ETL/Migration Build — Build the extract, transform, and load routines against the agreed mapping specification, including error handling and logging.
Mock Runs and Reconciliation — Run the full migration against production-like data well before the real cutover, more than once if possible. This is where most defects are found.
Rollback Plan — Define, in writing, the conditions under which the migration would be aborted or rolled back.
Cutover Day
Execute cutover following a detailed runbook with named owners for each step, defined go/no-go checkpoints, and a communication plan. Lock down source system changes before extraction begins.
After Migration: Validation and Hypercare
Once the new system is live, run final reconciliation between source and target, confirm downstream systems are receiving correct data, and keep a hypercare period active for a defined window afterward. Only decommission the source system once the business has formally signed off.
Agilus builds this checklist into every migration engagement as a structured methodology rather than a loose set of best practices, because the projects that go wrong are almost always the ones that compress or skip the mock-run and reconciliation steps under schedule pressure. We run mock migrations as a standard, non-negotiable stage, work with client teams to define go/no-go criteria before cutover day, and build rollback planning in from the start.
FAQ:
What is the most commonly skipped step in a data migration checklist?
Mock runs and reconciliation are the most frequently compressed or skipped under time pressure, and they’re also the step most likely to catch defects before they become production incidents.
Who should own the data migration checklist — IT or the business?
Both, with clearly split responsibilities: IT typically owns technical build and execution, while the business owns scope decisions, data quality sign-off, and go/no-go authority at cutover checkpoints.