Data Migration Checklist: Before, During and After
A usable data migration checklist has more than 30 controls across 3 stages: before, during and after migration. Each item needs an owner, evidence, status and blocker. A checked box without proof cannot tell a steering team whether cutover is safe.
This page is the verification artifact. It does not replace the data migration framework, detailed source-to-target mappings or the cutover runbook. Use it to confirm that those materials exist, are approved and have passed their gates.
What should a data migration checklist contain?
Track each control in a table with these fields:
| Field | Purpose |
|---|---|
| Checklist ID | Stable reference for meetings, evidence and defects |
| Stage | Before, during or after migration |
| Control | The result that must be true |
| Owner | One accountable person or role |
| Evidence | Link to an approved file, report, query or test result |
| Status | Not started, in progress, passed, failed or waived |
| Blocker | Decision or dependency preventing completion |
| Due date | Time-bound accountability |
| Sign-off | Approver, date and decision note |
Use red, amber and green only as a summary. The underlying status and evidence should remain readable without colour.
Before migration: scope and ownership
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| PRE-01 | Business outcome and migration scope are approved | Charter and scope statement | Sponsor |
| PRE-02 | Source systems, environments and populations are inventoried | System and dataset inventory | Data owner |
| PRE-03 | In-scope and excluded records are defined | Filter specification and count baseline | Business owner |
| PRE-04 | Target release and dependencies are confirmed | Release plan | Project manager |
| PRE-05 | Decision rights and escalation path are named | RACI or decision register | Sponsor |
| PRE-06 | Success, acceptance and rollback criteria are measurable | Acceptance plan | Business and technical owners |
| PRE-07 | Downtime or zero-downtime requirement is approved | Service continuity requirement | Operations owner |
| PRE-08 | Regulatory, contractual and retention obligations are recorded | Compliance assessment | Security or compliance owner |
Do not start detailed build work while record scope is disputed. Source counts should be reproducible by environment, date and filter. If the project plans zero downtime, name the allowed replication lag, write-freeze conditions and authority to switch systems.
Before migration: data discovery and quality
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| PRE-09 | Source fields are profiled with real values | Profiling report | Data analyst |
| PRE-10 | Nulls, duplicates, invalid formats and outliers are quantified | Data quality baseline | Data owner |
| PRE-11 | Business keys and duplicate-resolution rules are approved | Key and survivorship specification | Business owner |
| PRE-12 | Sensitive data is classified | Classification register | Security owner |
| PRE-13 | Cleansing responsibility is assigned | Issue log with source or migration owner | Project manager |
| PRE-14 | Historical, obsolete and test data have dispositions | Retain, archive or exclude decision | Records owner |
Profile the actual extraction, not a sample chosen because it is clean. Record distributions and exceptions so the post-migration result can be compared with the same measures.
Before migration: mappings and target readiness
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| PRE-15 | Source-to-target mapping covers every in-scope field | Approved mapping specification | Mapping owner |
| PRE-16 | Every required target field has a valid source, derivation or default | Reverse-coverage report | Target owner |
| PRE-17 | Schema splits, merges, types, keys and relationships are approved | Schema mapping | Data architect |
| PRE-18 | Lookup values and unknown-code handling are defined | Controlled crosswalks | Business owner |
| PRE-19 | Null, default, reject and quarantine rules are explicit | Exception specification | Data owner |
| PRE-20 | Target capacity, configuration and access are tested | Environment readiness report | Platform owner |
| PRE-21 | Downstream reports and integrations are inventoried | Dependency map | Application owner |
| PRE-22 | Backup and restore procedures have been rehearsed | Restore test evidence | Infrastructure owner |
Mappings should connect requirements, code and tests through stable IDs. A required target field discovered during user acceptance testing is a planning failure, not a late content task.
Before migration: security and test planning
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| PRE-23 | Least-privilege access is approved for every environment | Access review | Security owner |
| PRE-24 | Transfer and stored data use approved encryption | Security design | Security owner |
| PRE-25 | Production data in tests is masked or otherwise approved | Test-data decision | Privacy owner |
| PRE-26 | Unit, integration, performance and user tests are planned | Test plan | Test lead |
| PRE-27 | Positive, null, boundary and failure cases exist for mappings | Test-case inventory | Test lead |
| PRE-28 | Reconciliation queries and tolerances are approved | Reconciliation specification | Finance or data owner |
| PRE-29 | Defect severity and release thresholds are defined | Defect policy | Project manager |
| PRE-30 | At least one representative rehearsal is scheduled | Rehearsal plan | Migration lead |
During migration: build and rehearsal controls
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| RUN-01 | Code, mappings and schema versions are aligned | Release manifest | Migration lead |
| RUN-02 | Extraction is repeatable and logged | Extract log and checksums | Data engineer |
| RUN-03 | Transformations preserve lineage and exception reasons | Transformation and reject logs | Data engineer |
| RUN-04 | Unit and integration tests pass | Test results | Test lead |
| RUN-05 | Representative volumes meet the performance window | Timed rehearsal report | Platform owner |
| RUN-06 | Defects have owners and release dispositions | Defect register | Project manager |
| RUN-07 | Rehearsal counts and totals reconcile | Reconciliation report | Data owner |
| RUN-08 | Runbook timings and dependencies are updated from rehearsal | Approved runbook | Cutover manager |
A rehearsal is useful only when it changes the production plan. Record observed durations, failed steps, manual interventions, throughput and recovery time. Update the runbook rather than relying on meeting notes.
During migration: cutover and rollback controls
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| CUT-01 | Go or no-go approvers are present | Attendance and decision record | Sponsor |
| CUT-02 | Final backup or recovery point is verified | Backup confirmation | Infrastructure owner |
| CUT-03 | Source freeze or change capture starts as planned | System log | Application owner |
| CUT-04 | Initial load completes without unresolved critical errors | Execution log | Migration lead |
| CUT-05 | Delta changes are captured and applied | Change-capture reconciliation | Data engineer |
| CUT-06 | Smoke tests pass in the target | Smoke-test report | Test lead |
| CUT-07 | Counts, control totals and key relationships reconcile | Cutover reconciliation | Data owner |
| CUT-08 | Rollback threshold has not been breached | Go or no-go record | Sponsor and technical owner |
| CUT-09 | Users and dependent systems are switched deliberately | Cutover checklist | Application owner |
| CUT-10 | Communication is sent with known issues and support route | Release communication | Operations owner |
For zero-downtime migration, confirm that change data capture is healthy before routing writes to the new database. Measure replication lag, reconcile the final delta and keep the source recoverable until the target meets the agreed stability gate.
The minimum go or no-go checklist
Do not approve cutover if any required item below lacks evidence:
- A recoverable backup or restore point exists.
- The production runbook was rehearsed at representative scale.
- Critical and high-severity defects meet the release threshold.
- Mapping, code and target schema versions match.
- Rollback triggers, steps and decision authority are clear.
- Reconciliation queries are ready and tolerances are approved.
- Security, access and production support owners are available.
- Source freeze or change-capture behavior has been tested.
A waiver should name the risk, owner, expiry date and compensating control. “Accepted by the team” is not sufficient.
After migration: validation and reconciliation
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| POST-01 | Record counts reconcile by entity and approved filter | Count comparison | Data owner |
| POST-02 | Financial or operational totals reconcile within tolerance | Control-total report | Business owner |
| POST-03 | Required fields, formats and allowed values pass | Validation report | Test lead |
| POST-04 | Primary keys are unique and traceable | Key audit | Data architect |
| POST-05 | Foreign keys resolve and expected cardinality holds | Relationship audit | Data architect |
| POST-06 | Exceptions are classified, assigned and retained | Exception register | Data owner |
| POST-07 | Reports, APIs and downstream workflows behave correctly | End-to-end test results | Application owner |
| POST-08 | Users approve representative business scenarios | Acceptance record | Business owner |
Validation checks whether each rule produced acceptable data. Reconciliation compares populations, counts and totals between systems. You need both. A table can pass field validation while missing 5% of the intended records.
After migration: stabilization and closure
| ID | Control | Evidence required | Typical owner |
|---|---|---|---|
| POST-09 | Error rate, latency and processing volumes are monitored | Stability dashboard | Operations owner |
| POST-10 | Hypercare incidents have owners and response targets | Support queue | Support lead |
| POST-11 | Remaining defects have accepted plans | Residual issue register | Project manager |
| POST-12 | Rollback window closes through an explicit decision | Closure decision | Sponsor |
| POST-13 | Source access and retention follow the approved plan | Decommission record | Security and records owners |
| POST-14 | Mapping, lineage, runbook and operating documents are archived | Handover pack | Migration lead |
| POST-15 | Business owner signs final acceptance | Signed acceptance | Business owner |
| POST-16 | Lessons and reusable controls are recorded | Retrospective | Project manager |
Do not decommission the source because the target loaded successfully. Close only after the agreed observation window, stable processing, accepted reconciliation and recoverability decision.
How to adapt the checklist for Excel, CSV or a project tool
One row per control works in Excel, CSV, Notion, Jira or a governance platform. Keep the IDs stable. Store large evidence files in their controlled location and link to them rather than pasting results into one workbook.
Recommended status values are Not started, In progress, Passed, Failed, Waived and Not applicable. Require a reason and approver for the final 2 states. Add filters for stage, owner, status, system and due date.
For Git-based delivery, store the checklist or its export with the release manifest. This connects the approved mapping, code version, schema version and test evidence used for a particular migration run.
FAQs about the data migration checklist
What should be checked before data migration?
Confirm scope, owners, source inventory, quality baseline, mappings, target readiness, security, test cases, reconciliation, backup, rollback and a representative rehearsal.
What should be checked after data migration?
Reconcile counts and totals, validate fields and relationships, test business workflows, resolve exceptions, monitor stability, archive evidence and obtain final business acceptance.
Who signs off a migration checklist?
Each control has an accountable owner. Business owners approve meaning and acceptance, technical owners approve execution and recovery, and the sponsor makes the final go or no-go decision.
Is a data migration checklist enough?
No. It verifies that required work and evidence exist. The project still needs a framework, project plan, mapping specification, schema design, test cases, cutover runbook and rollback plan.
What is the difference between validation and reconciliation?
Validation checks whether migrated values satisfy rules and expected behavior. Reconciliation compares source and target populations, counts, totals and exceptions to confirm completeness.
How does the checklist change for zero downtime?
Add controls for change data capture, replication lag, final delta reconciliation, write switching, dual-system behavior, rollback authority and the period for which the source remains recoverable.
If you need this checklist converted into a project-specific runbook, Acelerar can map the controls to your systems, owners and evidence. Discuss your data migration requirements with the source, target, volume, downtime requirement and acceptance criteria.
Test the checklist against a representative sample
Acelerar can help identify missing mappings, exception work and reconciliation checks before production movement.
Get a Custom QuoteChakshu founded Acelerar in 2010 and has spent more than 16 years building it into an AI-native outsourcing company with 500+ team members.
You may also like
What Is Data Conversion? A Practical Business Guide
Data conversion changes information from one format or structure into another so a target system can use it. See practical examples, risks and quality checks.
Data Conversion vs Data Migration vs Data Transformation
Conversion changes format, migration changes location or system, and transformation changes structure or meaning. Compare the goals, tasks, owners and examples.
Data Conversion Process: Steps From Source Audit to Validation
The data conversion process runs from scope and source inventory through profiling, mapping, cleansing, pilot conversion, reconciliation and accepted delivery.