---
title: How to Create a Data Migration Checklist (Copy-Paste Template Included)
slug: data-migration-checklist-template
date: 2026-02-23
author: Raaj
categories: [General]
excerpt: "Need a reliable data migration checklist? This guide provides a 7-step, gate-based framework with concrete pass/fail criteria for every phase. Learn to choose between big bang, phased, and trickle strategies and grab our copy-paste templates available in Markdown, CSV, and YAML."
canonical: https://clonepartner.com/blog/data-migration-checklist-template/
---

# 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 your goal is…** | **You’re doing…** | **Use which checklist?** |
| --- | --- | --- |
| Move data between apps (CRM → ERP) | Data migration | Use the full checklist below |
| Change DB engine (SQL Server → PostgreSQL) | Database migration | Use full checklist + schema compatibility checks |
| Move physical servers / racks | Data center migration | Use addendum section |

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:

```javascript
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

| **Factor** | **Big Bang** | **Phased** | **Trickle** |
| --- | --- | --- | --- |
| Downtime tolerance | High | Medium | Low |
| Data volume | Small-medium | Medium-large | Large |
| Dependency complexity | Low | Medium | High |
| Risk tolerance | High | Medium | Low |

### 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

```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:

```javascript
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)

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

**Aggregate Check Example**

```javascript
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

```javascript
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

| **Metric** | **Threshold** |
| --- | --- |
| Error rate | &lt;0.5% |
| Query latency | ±20% baseline |
| Missing record alerts | 0 |
| Job retries | &lt;2% |

### 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

```javascript
# 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

```javascript
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

```yaml
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.

> Book a free consultation to understand how ClonePartner can help you migrate
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)