TL;DR
A data migration checklist runs four gated phases, each with a named owner and a go/no-go check; pick big bang or phased cutover per workload. Assessment comes first, with every source inventoried, profiled, classified and assigned to a named owner. Design then writes the source-to-target mapping, the tests and the rollback triggers before any data moves. Execution runs a mock migration, loads in waves and holds a go/no-go review against thresholds the team agreed in advance. Sign-off needs more than matching row counts, because checksums and business totals catch the mapping errors that counts miss. If a critical go/no-go check is red, roll back; if all are green, cut over and retire the old system.
Key Takeaways
A data migration checklist splits the work into four phases: assessment, planning and design, execution and cutover, and post-migration.
Every item needs one accountable owner and a piece of evidence that proves it is done.
Pick the approach per workload: big bang for small datasets, and phased waves or CDC trickle loads when downtime must stay near zero.
Write acceptance criteria and rollback triggers before the first load, so the go/no-go review compares results with numbers agreed in advance.
Reconcile at three levels before sign-off: row counts, column checksums and business totals.
Retire the legacy system on purpose: archive what retention rules require, then sanitize the media under NIST SP 800-88 Rev. 2.
Watch on YouTube
Data Migration Life Cycle: 7-Phase Step-by-Step Guide (2026)
Kanerika walks through the data migration life cycle one phase at a time. Watch it alongside this checklist to see how each stage hands off to the next.
When the Row Counts Match and the Revenue Report Does Not
Picture the Monday after a weekend cutover. Every table in the new warehouse matches the old one row for row, so the migration lead sends the all-clear at 7 a.m.
Then, at 10 a.m., the finance controller calls. Quarter-to-date revenue in the new dashboard is higher than the ledger says it should be. Yet not a single row was missing. A mapping rule that turned credit notes into negative amounts never made it into the new pipeline, so refunds now count as sales.
Row counts proved the data arrived, but they could not prove it still meant the same thing. A good data migration checklist closes that gap by tying every check to a phase, an owner and a piece of evidence.
The checklist below also follows the order the work really happens in. Copy it, assign the owners, and then set the thresholds for your own systems.
What a Data Migration Checklist Is and the Four Phases It Covers
A data migration checklist is an ordered list of tasks, owners and exit checks for moving data to a new system. Its job is to make sure nothing is lost on the way: not records, not business meaning and not access control.
The four phases below carry the whole checklist, so start there. Each one also has a goal, one accountable owner and the evidence that lets the team move on.
Phase Goal Accountable owner Exit evidence
1. Pre-migration assessment Know what you are moving and what state it is in Business sponsor, with data owners Signed scope, source inventory, profiling baseline, data classification 2. Planning and design Decide how data moves and how success is judged Migration lead, with the data architect Approved approach, source-to-target mapping, test plan, rollback plan 3. Execution and cutover Move the data in controlled, rehearsed loads Migration lead, with the platform team Mock run results, load and reject logs, go/no-go decision record 4. Post-migration Prove the target is correct, then retire the source Data owners, with the QA lead Reconciliation report, user acceptance sign-off, decommission record
Conversion is the narrower job: it changes the format or structure of data, while migration moves data between systems and often converts it too. If you are unsure which one your project is, the guide to data conversion vs data migration draws the line.
Why Gates and Owners Matter More Than Task Count
A flat list of 60 tasks is hard to run, because nobody can tell which items block the next step. Grouping the work into phases fixes that, because each phase has a clear end. Each phase ends at a gate, and the gate has an owner who signs off on evidence rather than on a feeling.
The owner column matters more than it looks. A RACI chart often spreads accountability across a committee, so decisions wait for a meeting. Here, instead, one role is accountable per phase, and everyone else contributes.
The gates are the point of the whole structure. A team that cannot produce the exit evidence for phase one is not ready to design phase two, however close the deadline feels.
Pre-Migration Assessment Checklist
Assessment is where you find out what you are really moving. It usually turns up more sources, older data and messier keys than the project charter assumed.
That is good news when it happens during assessment. The same discovery during cutover, by contrast, costs a weekend and a rollback. Work through these eight items of the data migration checklist before anyone opens a mapping spreadsheet.
Write the business outcome and the scope, including what stays behind or goes to archive.
Name a sponsor and one accountable data owner for each data domain.
Inventory every source system, feed, report and scheduled job that touches the data.
Capture the metadata: data catalog entries, business glossary terms and lineage.
Profile every source table and save a quality baseline.
Classify personal and regulated data, and record where each dataset may legally reside.
Agree who may access the data, and in which environments, while the migration runs.
Get the sponsor’s sign-off on the assessment before design starts.
Objectives, Scope and Accountable Owners
First, write down the outcome the business is paying for, in a sentence the sponsor would repeat. It might be retiring an end-of-support database, merging three CRM systems, or giving analysts one governed source for reporting. That sentence also anchors the wider program in the enterprise data migration guide , so later trade-offs can be tested against it.
Scope also needs the same precision. List what moves, what stays and what goes to archive. Historical data is the usual argument, because ten years of order lines may be needed for audit but not for daily reporting. Those older years can sit in cheaper archive storage instead of the new warehouse.
Naming the owners comes next. The sponsor owns the outcome. Each data domain, such as customers, products or finance, needs one person who can say whether a migrated record is correct.
Source Inventory, Dependencies and Metadata
An inventory lists every system that feeds, reads or transforms the data in scope. Include the easy-to-forget items too: spreadsheets on shared drives, nightly exports to partners, and reports that query the source directly.
Map the dependencies too. For example, a pricing job might read the product table at 2 a.m. Moving that table then breaks the job unless the job moves too or gets repointed.
Metadata also has to move. Catalog entries, glossary terms, classifications and lineage graphs are often rebuilt by hand after go-live, which is slow and invites mistakes. So treat them as migration objects with their own owner.
That is the core of a catalog migration checklist. Export the catalog, map its terms to the target platform, and then confirm that lineage still traces each report back to its source.
Data Profiling and Quality Baseline
Data profiling measures the data you have instead of the data you assume. Run it on every source table in scope. Look for nulls in required fields, duplicate keys, orphaned foreign keys, and formats that drift over time, such as dates stored three different ways.
Then save the results as a baseline. The reconciliation report will compare the target against this snapshot later, so you can tell which issues the migration created and which it inherited.
Decide early what happens to each problem, too. Some get fixed in the source, some get fixed in transformation, and some are accepted and documented with the data owner’s agreement.
Sensitive Data, Residency and Compliance
Classify personal, financial and health data before it moves. A migration copies data into new places, including staging areas, test environments and logs, and each copy needs the same protection as the original.
The stakes are real, especially in Europe. Under Article 83(5) of the GDPR , the most serious infringements can draw fines of up to EUR 20 million. For any company, the ceiling is 4% of total worldwide annual turnover for the preceding financial year, if that figure is higher.
Record where each dataset may legally reside, and mask personal fields in every non-production copy. Limit who can read staging tables while loads run, and log each access grant so you can revoke it at cutover.
Checklist
Data Migration Checklist
Download Kanerika’s data migration checklist to track every assessment, design, cutover and sign-off item with an owner and evidence.
Get the Checklist → Planning and Design Checklist
Design turns the assessment into decisions about three things: how each dataset moves, what happens to it, and how you will know it arrived. By the end of this phase, anyone on the team should be able to explain all three.
Programs that move a whole platform need more planning than one checklist holds, and the guide to data platform migration covers that level. For a single migration, though, these are the design items.
Choose a migration approach for each workload.
Design the target architecture, data layers and naming rules.
Write the source-to-target mapping, with every transformation rule.
Write the test cases, acceptance criteria and rollback plan.
Select the tooling and set cost controls for the migration period.
Agree the cutover window with the business, including a freeze on source schema changes.
Choose the Migration Approach
There are four common approaches. The right one depends on how much downtime the business can tolerate, and also on how much complexity your team can run.
You can also mix them. A small reference database might move in one big bang, while the order system moves through continuous replication.
Approach Downtime Risk profile Relative cost Fits when
Big bang One planned outage for the whole load Everything succeeds or fails together Lowest: one cutover The data can be loaded and validated inside the outage window Phased (waves) A short outage per wave Problems stay inside one wave Medium: repeated cutovers Data splits cleanly by domain, region or business unit Parallel run Little: old and new run side by side Lowest: results are compared before switching Highest: two systems plus syncing Errors would be very costly, as in billing or finance Trickle with CDC Near zero: changes replicate continuously Replication lag and conflict handling Medium to high: tooling and monitoring The source must stay online, as in order processing
Use the mock run to decide between them. If the full load and validation fit the outage window with room for one reload, big bang is viable. If they do not, move to waves or CDC.
Change Data Capture for Near-Zero Downtime
Trickle migration depends on change data capture (CDC). A tool first reads the source’s transaction log, then replays inserts, updates and deletes on the target. AWS also describes the pattern in its documentation for ongoing replication . A Database Migration Service task can capture changes while the full load runs, then keep applying them afterward.
The price, however, is complexity. Someone has to watch replication lag and decide what happens when the same record changes in both systems.
On a SQL Server source, log-based capture must be switched on before any tool can read changes. Microsoft’s change data capture documentation shows the two steps, first the database and then each table.
-- Enable change data capture on the source database, then on one table
USE SalesDB;
GO
EXEC sys.sp_cdc_enable_db;
GO
EXEC sys.sp_cdc_enable_table
@source_schema = N'dbo',
@source_name = N'Invoice',
@role_name = NULL,
@supports_net_changes = 1;
GOEnabling CDC needs sysadmin rights on SQL Server. Setting @supports_net_changes to 1 also needs a primary key or unique index on the table, so check keys during profiling.
Target Architecture and Data Layers
Decide the shape of the target before you map anything to it. A common pattern on Microsoft Fabric, Databricks and Snowflake is the medallion architecture . Microsoft’s Fabric documentation (updated February 2026) calls it the recommended design approach for Fabric. Bronze holds raw copies, silver holds cleaned and conformed data, and gold holds business-ready tables.
Landing raw data first has a practical benefit during a migration. When a transformation rule changes, you can rebuild silver and gold from bronze instead of extracting from the source again.
Settle partitioning, naming conventions and retention for each layer here as well, because changing them after go-live means rewriting pipelines.
Source-to-Target Mapping and Transformation Rules
The mapping document is the contract between the old system and the new one. Each row says where a field comes from, where it goes, what happens to it on the way, and how that will be tested. Here is a short sample.
Source field Target field Rule Test
CUST.CUST_NO (char 10) dim_customer.customer_id (string) Trim spaces, keep leading zeros Distinct count matches the source INV.AMT with INV.DOC_TYPE fact_invoice.net_amount (decimal 18,2) Credit notes (DOC_TYPE = ‘CN’) become negative amounts Monthly sum equals the general ledger ORD.ORD_DT (text, mixed formats) fact_order.order_date (date) Parse three known formats, send anything else to an error table Zero unparsed rows, or each one documented CUST.REGION_CD dim_customer.region_name Look up the code in the reference table No unmatched codes
The second row is the rule from the opening story. Writing it down, with a test tied to finance totals, is what would have caught the problem before Monday.
Talk to Kanerika
Want a Second Review of Your Migration Plan?
Kanerika can review your source-to-target mapping, tests and cutover plan, and show where automation shortens each phase.
Talk to a Migration Expert → Test, Rollback and Acceptance Criteria Written Before Data Moves
Acceptance criteria written after a load tend to describe whatever the load produced. So write them first. Agree on the reconciliation checks, the tolerance for each one, the business reports that must match, and the response times for key queries.
Write the rollback plan at the same time. It should name the point of no return and the steps to repoint users to the source. It should also say how changes made in the target after cutover get carried back.
Make every tolerance concrete and set it per table. For example, you might allow zero variance on financial totals and plus or minus 0.1% on non-financial row counts. For sampling methods, automated test suites and test case design, see the guide to data migration testing .
Tooling and Cost Controls
Tool choice follows the approach, not the other way round. Before you approve any of the data migration tools on your shortlist, check five things.
Connectors: native support for every source and target in scope, including their versions.CDC: log-based change capture if any workload needs near-zero downtime.Validation: built-in row and checksum comparison, or an easy way to run your own.Lineage: a record of where each target field came from.Cost: licensing, compute and data transfer charges for the whole migration period, including any parallel run.
Put a budget alert on the target platform before the first load. Mock migrations and full reloads burn compute quickly, and a forgotten test cluster can also run all weekend.
Migration ROI Calculator
Estimate Your Migration ROI
Put your own source count, data volume and parallel-run months into Kanerika’s migration ROI calculator before you finalize the budget.
Calculate Migration ROI → Execution and Cutover Checklist
Execution is where the plan meets real volumes, real network limits and real users. The aim is to have no surprises on cutover day, so rehearse everything that can be rehearsed.
Run at least one full mock migration in a production-like environment.
Take a baseline snapshot of the source, with counts and control totals.
Freeze schema changes on the source for the cutover period.
Load in waves, and capture the changes made while each load runs.
Log every rejected record with a reason code.
Hold the go/no-go review against the agreed thresholds.
Cut over, repoint users and integrations, and confirm access works.
Mock Migration and Source Baseline Snapshot
A mock migration runs the whole process end to end on a copy of production data. It shows how long each step really takes and exposes data that breaks the transformation rules. It also gives the support team a chance to practice.
Time the mock run and compare it with the outage window. If the load takes 30 hours and the window is 48, there is room for validation but not for a full reload. That tells you to split the load into waves or switch to CDC before the real date.
Right before the real load, snapshot the source. Capture row counts per table, sums of key amounts and the latest transaction timestamp, because every post-migration check compares against this baseline.
Wave Loads, Delta Capture and Failure Logging
Load the large, simple tables first to prove throughput, then the complex ones. Within each wave, run the full load, apply the changes captured while it ran, and validate the wave before starting the next.
Never let a load drop records silently. Instead, every rejected row should land in an error table with the source key, the rule that failed and a timestamp.
If AWS Database Migration Service runs the load, its built-in data validation can do part of this job. It compares each source row with its target row and writes mismatches to a failures table on the target.
{
"ValidationSettings": {
"EnableValidation": true,
"ThreadCount": 5,
"FailureMaxCount": 10000,
"TableFailureMaxCount": 1000,
"HandleCollationDiff": true
}
}Those counts are the defaults in the validation task settings reference . Validation pauses for the task after 10,000 failed records, or for one table after 1,000. Lower them to match the reject limit in your acceptance criteria.
A rising reject count is an early warning. So is a reject count of zero on messy source data, since it can mean the rules are not running at all.
Go/No-Go Review and Rollback Triggers
The go/no-go review is a short meeting with one question. Do the results meet the thresholds the team agreed during design? Each criterion also has an owner who reports green or red, with evidence.
Criterion Example threshold (set in your acceptance criteria) Owner Rollback trigger
Row counts per table Match the source baseline, or every difference explained Migration lead An unexplained difference in any in-scope table Financial control totals Equal to the source to the cent Finance data owner Any unexplained variance Rejected records Below the agreed limit, each with a reason code Data quality lead Rejects above the limit, or rejects with no reason Critical reports Key reports match their legacy versions Business owners A critical report that does not match Performance Key queries meet the agreed response times Platform lead Targets missed with no fix before the window closes Access Users and service accounts reach what they should, and nothing more Security lead Missing or over-broad access to sensitive data
These thresholds are examples, not industry standards. Your team sets the real numbers in the acceptance criteria before anyone is tired at 3 a.m. and tempted to accept a variance.
Agree on the decision rule in advance as well. One red on a critical criterion means rollback. A red on a minor criterion can allow go-live with a dated fix, but only if the business owner signs for it.
Post-Migration Checklist
The work continues after cutover. Users find the edge cases in the weeks after go-live, so this phase needs as much structure as the ones before it.
Reconcile counts, checksums and business totals against the baseline.
Run user acceptance testing on the critical reports.
Check query performance, cost and access in the new platform.
Staff a hypercare period with a clear route for reporting data issues.
Update the documentation, the data catalog and lineage.
Archive and retire the legacy system under your retention rules.
Reconcile Counts, Checksums and Business Totals
Reconciliation works at three levels. Row counts show the data arrived. Checksums or hashes on key columns show the values arrived unchanged. Business totals, such as revenue by month, show the data still means the same thing.
The query below, for example, shows the idea for one table. Run the same aggregate on the source and the target, then compare the two outputs in the reconciliation report.
-- Run on the source and on the target, then compare the results
SELECT
DATE_TRUNC('month', invoice_date) AS invoice_month,
COUNT(*) AS row_count,
SUM(net_amount) AS net_amount_total,
COUNT(DISTINCT customer_id) AS customers
FROM fact_invoice
GROUP BY DATE_TRUNC('month', invoice_date)
ORDER BY invoice_month;Add a column-level hash comparison as well for tables where totals mean little, such as customer master data. Store each comparison result with the other sign-off evidence.
Performance, Cost and Access in the New Platform
A migration that is correct but slow will still be judged a failure. Compare key queries and reports against the targets in the acceptance criteria, and tune partitioning or indexes where they fall short.
Watch cost closely until the first full billing cycle closes. Turn off migration-only resources, such as staging clusters and replication tasks, as soon as they are no longer needed. Review access again too, since temporary grants made during loads have a habit of staying. Fold the final grants into your data governance framework so ownership outlives the project.
Hypercare, Documentation and Lineage
Hypercare is a period after go-live with extra support on call and a fast path for data issues. Agree on its exit criteria in advance, such as one week with no new critical data issues, rather than ending it on a fixed date.
Use the same period to finish the documentation. Update the data catalog, record the final mappings, and confirm that data lineage traces each report back to its new sources.
Retire the Legacy System Safely
Running the old system forever costs money and keeps a second copy of sensitive data alive, so retire it in steps. Make it read-only, keep it for an agreed comparison period, archive what retention rules require, and then shut it down.
Disposing of the storage needs a standard. NIST SP 800-88 Rev. 2 , published in September 2025, is NIST’s guideline for media sanitization and replaces Rev. 1 from 2014. Then record which method was used on which devices, and keep that record with the decommission sign-off.
Validation Evidence to Collect Before Sign-Off
Sign-off is only as good as the evidence behind it. A useful test: an auditor should be able to open one folder a year after go-live and see why the business accepted the migration.
That evidence covers all three reconciliation levels, and also the human checks that numbers cannot capture. Keep it compact, and store it somewhere that will outlive the project’s chat channel.
Collect these items before the final sign-off meeting.
Evidence Produced by Signed by Stored where
Source baseline snapshot Migration lead Data owners Project evidence folder Reconciliation report (counts, checksums, totals) QA lead Data owners and finance Evidence folder, linked from the data catalog Rejected-record log with resolutions Data quality lead Data owners Evidence folder User acceptance results for critical reports Business testers Business sponsor Evidence folder Performance test results Platform lead Migration lead Evidence folder Access review Security lead Data protection or security owner Security records Decommission and sanitization record Infrastructure lead IT owner Asset register
If an item has no signer, it is not evidence yet. So chase the signature before the meeting, not after it.
Checklist Variants: Database, Data Center and Cloud Migrations
The four phases apply to every migration, but each of the types of data migration adds its own items. Start from the core checklist, then add the rows that match your project.
Variant Extra checklist items
Database migration Schema and data type conversion, collation and character sets, stored procedures and triggers, sequences and identity columns, CDC for the cutover Data center migration Network cutover and DNS changes, bandwidth or physical transfer for large volumes, disaster recovery tested at the new site, hardware decommission Cloud migration A 7 Rs disposition for each workload, a landing zone with identity and network controls, egress and bandwidth costs, region choice for data residency
What Each Variant Adds in Practice
For a database move, the type mapping is where problems hide, which is why legacy data migration from older sources needs extra tests. A text date in the source, a different default collation, or an identity column that restarts at 1 can each break joins downstream. The guide to SQL Server data migration works through these issues for one of the most common sources.
A data center migration checklist also adds the physical layer. It often sits inside a wider data center modernization program. Plan the network cutover, and test disaster recovery at the new site before you depend on it. Then track every server and disk through to sanitization.
Bandwidth decides the transfer method. Google Cloud’s guide to transferring large datasets , last reviewed in November 2024, puts 100 TB at over 10 days online over 1 Gbps. At 100 Mbps the same transfer takes over 100 days, and the guide then suggests considering an offline option such as Transfer Appliance. Time the transfer against your cutover date before you pick a method.
Cloud migrations add a decision for each workload, and they work best inside a clear cloud transformation strategy . The AWS migration strategies guidance lists seven options: retire, retain, rehost, relocate, repurchase, replatform and refactor. Data workloads often land on replatform, because moving a warehouse to a managed cloud service changes the engine but not the business logic.
Kanerika Service
Data Migration Services from Kanerika
Kanerika plans and runs database, data center and cloud migrations with automated discovery, conversion and validation, from assessment through legacy retirement.
Explore Migration Services Time and Effort: What Drives a Migration Schedule
Every sponsor asks how long the migration will take. The honest answer is that it depends on a handful of drivers. So the quickest route to an estimate you can defend is to measure a pilot wave.
Driver Why it changes the schedule
Data volume Sets load time, the transfer method and the length of each outage window Number of sources Each source adds connectors, mapping work and owner sign-offs Transformation complexity Business rules need design and tests, plus rework when they fail Data quality debt Profiling findings must be fixed, rejected or accepted before sign-off Downtime window A short window pushes you toward waves or CDC, which take longer to build Compliance review Security and privacy approvals run on their own lead times
Data quality drives duration more than size does, because two migrations of the same size can differ by months on data quality alone.
Run a pilot wave instead. Pick a representative slice, such as one business unit, and take it through all four phases with the real team and the real tools.
Then measure how long each phase took and how many records failed. Scale those numbers by the remaining waves, adjusting for any wave that is bigger or messier than the pilot. Finally, add contingency for the issues the pilot found, and re-estimate after the second wave.
The estimate that comes out is tied to your own data and your own team, so you can defend it against a vendor’s slide.
Checklist Mistakes That Cause Rework
The mistakes below are process failures, and each one traces back to a checklist item that was skipped or done out of order. For the full catalog of what can go wrong, see the guide to risks in data migration .
Treating row counts as proof. Counts match even when values or meaning change, as the opening story showed. So add checksums and business totals every time.Profiling after design. When quality problems surface during the load, every mapping rule built on assumptions needs rework.Writing acceptance criteria after the load. Criteria written afterward describe the result instead of testing it.Skipping the mock migration. The first full run then happens on cutover night, with no timing data and a team that has never practiced.No named owner for a data domain. Questions about whether a record is correct wait for a committee, so the schedule slips.Leaving the legacy system running just in case. It keeps costing money while users keep writing to it, so two versions of the truth drift apart.
The common thread is order. Each mistake moves a check later than it belongs, where fixing the problem costs more and involves more people.
How Kanerika Runs Migrations Against This Checklist
Kanerika’s migration practice follows the same four phases, with automation doing the repetitive parts. The aim is to spend people’s time on decisions about scope, rules and sign-off rather than on converting code by hand.
The automation comes from FLIP , Kanerika’s migration accelerator platform. When Kanerika launched its FLIP Migration Accelerators in November 2025, it said they automate up to 80% of the migration process . Here is where that automation sits in the checklist.
Assessment: automated discovery and analysis of the source estate, such as SSIS packages and their dependencies.Planning and design: generated mappings and conversion logic that engineers review and adjust.Execution: conversion of legacy pipelines into the target platform’s own format.Post-migration: automated validation that compares source and target results.
Automation has limits, and it helps to be clear about them. FLIP does not decide your scope, write your acceptance criteria or sign off your data. Business rules that live only in someone’s head still need workshops, and the go/no-go call stays with your owners.
Delivery runs through Kanerika’s data migration services , with paths such as SSIS to Microsoft Fabric migration for teams moving to Microsoft Fabric . The SSIS to Fabric migration guide covers that path step by step.
Case Study: SSIS Pipelines Moved to Microsoft Fabric
Challenge. A client ran large SSIS environments on premises. Maintenance, upgrades and troubleshooting took heavy manual effort, the infrastructure was expensive, and the pipelines struggled with growing data volumes.
Solution. Kanerika built an automated framework to extract, analyze and migrate the SSIS pipelines into Microsoft Fabric. PySpark notebooks and Power Query handled the transformations, while role-based access, encryption and monitoring covered security.
Results. Automated validation and testing gave 99.9% data integrity during the migration. Kanerika reports 30% faster data processing, 40% lower infrastructure and maintenance costs, and 25% less manual maintenance.
Read against this checklist, the project touched every phase. Automated extraction and analysis of the SSIS packages served as the assessment inventory, and the transformation rules were rebuilt as notebooks and Power Query steps. Security controls also went in before data moved, and automated validation then supplied the sign-off evidence. Read the full SSIS to Microsoft Fabric case study for details.
Case Study
40% Lower Costs: SSIS to Microsoft Fabric Migration
Kanerika moved large SSIS pipelines to Microsoft Fabric with automated validation, reaching 99.9% data integrity, 30% faster processing and 40% lower infrastructure and maintenance costs.
Read the Case Study → Download the Data Migration Checklist Template
A checklist works best as a shared tracker that the whole team updates at every gate. Whatever tool you use, a spreadsheet or a project board, give it these columns.
Column What it holds
Item The task, written as a check that is either true or false Phase Assessment, design, execution or post-migration Owner One accountable person, by name Due The date, tied to the phase gate Status Not started, in progress, done or blocked Evidence link Where the proof is stored Sign-off Who accepted the item, and when
Kanerika’s Data Migration Checklist is a ready-made version you can download and adapt. Add your own thresholds and owners, then review it at every phase gate.
Wrapping Up
A data migration succeeds when every step has an owner, an exit check and evidence, and when those checks go deeper than row counts.
First, give assessment the time it needs. Then write the mapping, the tests and the rollback triggers before data moves. Rehearse with a mock run, then hold a go/no-go review against numbers you agreed while nobody was under pressure.
So what belongs on a data migration checklist? Four phases with named owners, go/no-go checks set in advance, and sign-off evidence that proves the data still means what it meant before the move.
Frequently Asked Questions
What is an enterprise data migration checklist, and why is it critical?
An enterprise data migration checklist is an ordered list of tasks, owners and exit checks for moving data to a new system. It splits the work into assessment, design, execution and post-migration phases. It matters because each gate forces evidence before the next step, so mapping errors, missing sources and access gaps surface early, when fixing them is cheap.
What are the steps for data migration?
A data migration runs through four phases. First assess the sources, profile quality and classify sensitive data. Then design the approach, the source-to-target mapping, the tests and the rollback plan. Next run a mock migration, load in waves and hold a go/no-go review. Finally reconcile the results, run hypercare and retire the legacy system safely.
What are the 6 R's of data migration?
The 6 R’s are rehost, replatform, repurchase, refactor, retire and retain. AWS published this list in 2016, building on Gartner’s earlier 5 R’s. Each workload gets one of the six, so teams can retire what nobody uses, keep what must stay, move some systems as they are, and redesign the systems where the business gains most.
What are the 7 R's of migration?
The 7 R’s are retire, retain, rehost, relocate, repurchase, replatform and refactor, as listed in AWS prescriptive guidance. Relocate is the addition to the older six. It moves infrastructure to the cloud at the hypervisor level without rewriting applications. Data workloads often land on replatform, because a managed cloud warehouse changes the engine but keeps the business logic.
Which tool is used for data migration?
No single tool fits every project. Teams choose from cloud provider migration services, ETL and data integration platforms, change data capture tools for replication, and validation tools that compare source and target. Before choosing, check connectors for every source and target, log-based change capture, built-in validation, lineage tracking, and the full cost of the migration period.
Is ETL the same as data migration?
No. ETL, short for extract, transform and load, is a technique that moves and reshapes data, and it often runs on a schedule for years. Data migration is a one-time project that moves data from an old system to a new one and then retires the old one. Many migrations use ETL tools to do the moving.
What is a data migration cutover checklist?
A cutover checklist covers the final switch from the old system to the new one. It includes a source schema freeze, a baseline snapshot with counts and control totals, the final delta load, a go/no-go review against agreed thresholds, repointing users and integrations, an access check, and the rollback steps to follow if a critical check fails.
When should you roll back a data migration?
Roll back when a critical go/no-go criterion fails and cannot be fixed before the cutover window closes. Typical triggers include unexplained differences in row counts or financial control totals, critical reports that do not match their legacy versions, or missing access controls on sensitive data. Agree these triggers during design, before anyone faces the decision under pressure.
How long does an enterprise data migration take?
Duration depends on data volume, the number of sources, transformation complexity, data quality debt, the downtime window and compliance reviews. Two projects of the same size can differ by months on data quality alone. The most reliable estimate comes from a pilot wave, measured through all four phases and then scaled across the remaining waves.
Is there a data migration checklist template I can download?
Yes. Kanerika publishes a free Data Migration Checklist on its checklists page that you can download and adapt. Whatever template you use, give it columns for the item, phase, accountable owner, due date, status, evidence link and sign-off. Review it at every phase gate so it works as a live tracker rather than a static document.
What belongs on a data center migration checklist?
Start with the core data migration phases, then add the physical layer. Include network cutover and DNS changes, the transfer method for large volumes, disaster recovery tested at the new site, and server and storage decommissioning. Track every disk through sanitization under a standard such as NIST SP 800-88 Rev. 2, and keep the records.
What is the difference between big-bang and phased data migration?
Big-bang migration moves all data in one planned outage, so the project is shorter but everything succeeds or fails together. Phased migration moves data in waves, by domain, region or business unit. Each wave has a shorter outage and problems stay contained, but the project runs longer and needs the old and new systems to coexist.
What are the main data migration strategies?
There are four common strategies. Big bang moves everything in one planned outage. Phased migration moves data in waves by domain or region. A parallel run keeps old and new systems live side by side until results match. Trickle migration uses change data capture to replicate changes continuously, which keeps downtime near zero but adds operational complexity.
How do you prevent data loss during migration?
Take a baseline snapshot of the source before loading, with counts and control totals per table. Log every rejected record with its key and the failed rule instead of dropping it. Reconcile counts, checksums and business totals after each wave, and keep the legacy system read-only until sign-off so nothing changes in two places at once.
What systems should be included in an enterprise data migration plan?
Include every system that creates, reads or transforms the data in scope. That covers source databases and applications, integration feeds, scheduled jobs, reports and dashboards, partner exports, and spreadsheets that query the source directly. Add metadata systems too, such as the data catalog, business glossary and lineage tools, because they need to move with the data.
How should enterprises assess data readiness before migration?
Profile every source table in scope before design begins. Measure nulls in required fields, duplicate keys, orphaned records and inconsistent formats, then save the results as a quality baseline. Agree with each data owner which issues get fixed in the source, which get fixed in transformation, and which are accepted and documented before any data moves.
What role does security and compliance play in data migration?
A migration copies data into staging areas, test environments and logs, and each copy needs the same protection as the original. Classify personal and regulated data first, record residency rules, and mask sensitive fields outside production. Under GDPR Article 83(5), the most serious breaches can draw fines of up to EUR 20 million or 4% of turnover.
How can enterprises minimize downtime during data migration?
Choose an approach that fits the outage the business can accept. Change data capture keeps the source online and replicates changes until a short final switch. Phased waves limit each outage to one domain. A timed mock migration shows whether the load fits the window, and a frozen source schema prevents last-minute surprises during cutover.
What validation steps should be included after data migration?
Reconcile at three levels against the source baseline. Compare row counts per table, compare checksums or hashes on key columns, and compare business totals such as monthly revenue. Then run user acceptance tests on critical reports, check query performance and access, and collect signed evidence for each item. A migration is complete only when every item is signed.
What are the four types of data migration?
The four common types are storage, database, application and cloud migration. Storage migration moves data to new hardware or storage services. Database migration moves it to a new database engine or version. Application migration moves data when a business system is replaced. Cloud migration moves data and workloads from on-premises infrastructure to a cloud platform.
What are the 5 R's of migration?
The 5 R’s come from Gartner’s 2011 framework for moving applications to the cloud. They are commonly listed as rehost, refactor, revise, rebuild and replace. Each option describes how much an application changes during the move, from running it as it is on new infrastructure to replacing it entirely with a commercial or SaaS product.
