How to Create a Data Migration Checklist (Copy-Paste Template Included)

If you're planning a migration, you don't need another generic list. You need something you can actually run against.

This guide gives you:

• A 7-step, gate-based migration framework
• A decision matrix (big bang vs phased vs trickle)
• A copy-paste checklist template (Markdown + CSV + YAML)
• Validation SQL examples
• Concrete pass/fail criteria for every phase

You can use this whether you're migrating data between systems, changing database engines, or moving infrastructure.

First — What Kind of Migration Are You Actually Doing?

Before we go further, let's remove ambiguity.

If you mix these up, your checklist will be wrong from day one.

If you're unsure, ask yourself:

• Are schemas changing?
• Are stored procedures involved?
• Are physical assets moving?

Answer those honestly. That determines the complexity tier.

The 7-Step Migration Framework

Here's the high-level model I recommend.

Discover → Plan → Prepare → Pilot → Execute → Validate → Operate

Every step has a gate. You don't move forward until the gate passes.

1. Discover & Inventory

Objective: Know exactly what exists before you touch anything.

If you skip this, everything after becomes reactive.

Typical effort: 1–3 weeks for mid-size migrations (10–50 tables, under 1TB). Larger estates with undocumented dependencies can take significantly longer.

What to capture

Minimum required inventory fields:

asset_id
asset_type (database/table/file/api)
owner
size_gb
row_count
sensitivity_level (public/internal/confidential/regulatory)
dependencies
last_updated

You should produce:

• inventory.csv
• Dependency map (diagram or table)
• Data profiling report

Data profiling metrics to calculate

For each critical table:

• % null values per column
• Duplicate key rate
• Orphan record rate
• Max/avg row size
• Encoding anomalies

If you don't measure these now, you'll discover them mid-migration.

Compliance checkpoint

If your data falls under GDPR, HIPAA, SOX, or other regulatory frameworks, this is where you identify it. Tag every asset with its compliance obligations now — data residency requirements, retention policies, consent constraints, and any restrictions on cross-border transfer. Discovering these mid-migration is how projects get paused by legal.

Gate 0 PASS Criteria

• Inventory file exists
• All critical tables have row counts
• Dependency mapping completed
• Backup exists AND restore test performed (not just backup)
• Compliance-sensitive assets tagged with applicable regulations

Yes, restore test. Backups don't matter if they don't restore.

2. Plan & Strategy

Now you decide how you migrate.

There are three real strategies.

Typical effort: 1–2 weeks. Mostly stakeholder alignment and document review.

Strategy Decision Matrix

Decision Rules

• If downtime tolerance < 30 minutes → avoid big bang.
• If dependencies are undocumented → use phased or trickle.
• If schema changes are heavy → pilot first, phased preferred.

For trickle migrations specifically, Change Data Capture (CDC) is the mechanism that makes continuous sync feasible. CDC tools track row-level changes in the source system and replay them to the target in near real-time. Tools in this category include Debezium (open-source, Kafka-based), AWS DMS, and built-in CDC features in databases like SQL Server and PostgreSQL. If you're choosing a trickle strategy, your CDC tooling decision should be made during this phase — it directly affects your architecture, latency guarantees, and rollback approach.

Document:

• RACI
• Rollback criteria
• Acceptable data variance %
• Communication plan

Gate 1 PASS Criteria

• Strategy document approved
• Rollback defined
• Timeline with contingency buffer included
• Stakeholder signoff obtained

3. Prepare & Map

This is where migrations quietly succeed or fail.

You need a versioned mapping specification.

Typical effort: 2–4 weeks depending on schema complexity and number of transformations.

Example Mapping YAML

mapping_version: "1.0.0"
created_by: "data_team"
created_on: "2026-02-17"
 
tables:
  - source: customers_v1
    target: customers
    primary_key: customer_id
    transforms:
      - field: phone
        transform: normalize_e164
      - field: created_at
        transform: timezone_to_utc

The normalize_e164 transform refers to the E.164 international phone number format, the ITU standard for globally unique phone numbers. Standardizing to E.164 during migration prevents format inconsistencies between systems.

Put this in version control.

Never allow undocumented mapping changes.

Preparation Checklist

• Data cleansing rules defined
• Transformations documented
• Test dataset anonymized (if required)
• Mapping reviewed by business owner

Gate 2 PASS Criteria

• Mapping v1.0 committed to repository
• Transform logic peer reviewed
• Test dataset created

All known data anomalies documented

4. Pilot (Start With the Hardest Data)

Most teams test average data first.

That's a mistake.

Start with:

• Largest tables
• Most complex joins
• Highest null/duplicate rates
• Most transformation logic

Typical effort: 1–2 weeks. Includes execution, analysis, and remediation of issues found.

Pilot Metrics to Capture

• Parity % (row match rate)
• Transformation error rate
• Throughput (rows/sec)
• Retry rate

Example Acceptance Threshold

• Parity ≥ 99.9%
• Error rate ≤ 0.5%
• Rollback test successful

Gate 3 PASS Criteria

• Pilot report generated
• Variance explained
• Rollback executed successfully in test

If pilot fails, fix before scaling.

5. Execute (Automated, Never Manual)

Manual migration is how errors multiply.

You want:

• Idempotent jobs
• Versioned pipeline code
• Monitoring dashboards
• Real-time alerts

Typical effort: Days to weeks depending on data volume and strategy. Big bang executions are compressed; phased and trickle migrations run over longer windows.

Required Logs

Every migration job must log:

job_id
initiated_by
start_time
end_time
rows_processed
rows_failed
exception_summary
checksum_value

CI/CD Requirements

• Dry-run test on small dataset
• Schema diff validation
• Parity test automatically triggered

Gate 4 PASS Criteria

• No manual steps in execution
• Monitoring dashboard active
• Rollback script tested

6. Validate & Reconcile

This is where migrations become authoritative.

You must prove data integrity.

Row Parity Example (SQL)

SELECT
  COUNT(*) as src_count,
  (SELECT COUNT(*) FROM target_schema.orders) as tgt_count
FROM source_schema.orders;

Aggregate Check Example

SELECT
  SUM(amount) as src_total
FROM source_schema.invoices;

Compare against target.

Checksum Approach

Generate hash of primary key + critical columns.

Referential Integrity Check

SELECT COUNT(*)
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE c.id IS NULL

This must equal zero.

Compliance Validation

For regulated data, validate that compliance constraints survived the migration:

• Data residency: confirm regulated records landed in the correct geographic region
• Retention policies: verify expiration dates and deletion rules are intact
• Access controls: confirm permission models in the target system match or exceed source
• Audit trail: ensure the migration itself is logged in a way that satisfies your compliance framework

Business Validation

Run 10 business-critical workflows end-to-end.

If business logic breaks, the migration failed.

Gate 5 PASS Criteria

• All parity checks within tolerance
• No orphan records
• UAT signed by business owners
• Performance within ±20% baseline
• Compliance constraints verified (for regulated data)

7. Cutover, Hypercare & Decommission

The migration isn't done at cutover.

It's done after stability.

Hypercare Window

Minimum: 48–168 hours. The duration should scale with migration complexity — simple single-system migrations may stabilize within 48 hours, while multi-system migrations with complex dependencies typically need the full 168-hour window (or longer) to surface intermittent issues.

Dedicated on-call coverage.

Monitor These KPIs

Decommission Checklist

• Old system backed up
• Data archived
• Secure wipe completed (per NIST SP 800-88 guidelines for media sanitization)
• Contracts terminated
• CMDB updated

Gate 6 PASS Criteria

• Stability confirmed for defined window
• Audit log archived
• Decommission authorized

Copy-Paste Migration Checklist Template

Markdown Version

# Data Migration Checklist v1.0
 
## Discover
- [ ] Inventory completed
- [ ] Row counts captured
- [ ] Dependencies mapped
- [ ] Backup restore tested
- [ ] Compliance-sensitive data tagged
 
## Plan
- [ ] Strategy selected
- [ ] Rollback defined
- [ ] Timeline approved
- [ ] Stakeholders signed off
 
## Prepare
- [ ] Mapping v1.0 created
- [ ] Transform logic reviewed
- [ ] Test dataset prepared
 
## Pilot
- [ ] Pilot run executed
- [ ] Parity >= 99.9%
- [ ] Rollback tested
 
## Execute
- [ ] Automated pipeline deployed
- [ ] Monitoring enabled
- [ ] Logs validated
 
## Validate
- [ ] Row parity confirmed
- [ ] Aggregate checks passed
- [ ] Compliance constraints verified
- [ ] UAT signed
 
## Operate
- [ ] Hypercare active
- [ ] KPIs stable
- [ ] Old system decommissioned

CSV Version

task_id,phase,task,owner,acceptance_criteria
001,Discover,Complete inventory,DataOwner,inventory.csv exists
002,Discover,Test restore,ITOps,Restore test successful
003,Discover,Tag compliance data,DataOwner,All regulated assets tagged
004,Prepare,Create mapping v1.0,DataEngineer,mapping.yml committed
005,Pilot,Run pilot migration,DataEngineer,Parity >= 99.9%

YAML Version

migration_version: "1.0"
phases:
  - name: Discover
    tasks:
      - inventory_completed: true
      - restore_tested: true
      - compliance_data_tagged: true
  - name: Pilot
    acceptance:
      parity_threshold: 99.9
      rollback_tested: true

Common Mistakes (And How This Checklist Prevents Them)

1. Not testing restore → Gate 0 requires restore drill.
2. Undocumented mapping → versioned YAML mapping required.
3. Testing only easy data → pilot hardest dataset first.
4. Manual execution → automation gate required.
5. Skipping business validation → UAT required before decommission.
6. Ignoring compliance requirements → compliance checkpoint at Discover and Validate gates.

Final Thoughts

If you follow this gate-based model, you'll always know:

• Where you are
• What's missing
• Whether you're safe to proceed

A migration isn't complete because the data moved. It's complete because integrity is proven.

If you need expert help executing migrations at scale, ClonePartner specializes in structured, low-risk migrations across systems and infrastructure.