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.

Let’s break it down.

1. Discover & Inventory

Objective: Know exactly what exists before you touch anything.

If you skip this, everything after becomes reactive.

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.

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)

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.

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.

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.

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

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

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

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 Concept)

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 NUL

This must equal zero.

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

7. Cutover, Hypercare & Decommission

The migration isn’t done at cutover.

It’s done after stability.

Hypercare Window

Minimum: 48–168 hours.

Dedicated on-call coverage.

Monitor These KPIs

Decommission Checklist

• Old system backed up
• Data archived
• Secure wipe completed
• 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
 
## 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
- [ ] 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,Prepare,Create mapping v1.0,DataEngineer,mapping.yml committed
004,Pilot,Run pilot migration,DataEngineer,Parity >= 99.9%

YAML Version

migration_version: "1.0"
phases:
  - name: Discover
    tasks:
      - inventory_completed: true
      - restore_tested: 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.

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.