Data Migration Roadmap Template: Plan, Test, and Cut Over Safely
6 min read ยท 2026-10-08
A data migration roadmap template is a phased plan for moving data from one or more source systems into a new target system with its quality, history, and business meaning intact. It covers discovery, mapping, cleansing, repeated test loads, reconciliation, cutover, and decommissioning, with owners and sign-off points at each step.
This six-month template is built for migrations like legacy ERP to a cloud ERP, on-premise databases to a cloud warehouse, or an old CRM to a new one. It assumes data will be dirty, stakeholders will disagree about definitions, and you will need several rehearsals before the real cutover.
The roadmap at a glance
Goal: Migrate all in-scope data to the target system with reconciled counts, signed-off quality, and the legacy system ready to retire. Duration: 6 months
Scope and Discovery (Weeks 1-4)
Define exactly what data moves and understand its real condition.
- Inventory source systems, tables, files, and integrations that feed or consume the data.
- Agree with business owners which entities and how many years of history are in scope.
- Profile source data for nulls, duplicates, invalid formats, and orphaned records.
- Identify regulatory retention and privacy requirements that affect what moves or gets archived.
- Choose a migration approach: big bang cutover, phased by entity, or parallel running.
Milestone: Signed scope document with data profiling results and a chosen migration approach.
Mapping and Design (Weeks 5-9)
Define how every source field transforms into the target model.
- Build a field-level mapping document from source to target with transformation rules.
- Resolve conflicting definitions, such as what counts as an active customer, with data owners.
- Design key strategy for IDs, cross-references, and relationships between migrated entities.
- Select tooling such as an ETL platform, database replication service, or custom scripts.
- Define reconciliation checks for row counts, financial totals, and key field samples.
Milestone: Approved mapping specification and reconciliation rules for every in-scope entity.
Cleansing and Build (Weeks 10-14)
Fix data quality issues and build repeatable migration pipelines.
- Assign data owners to fix duplicates and invalid records in the source where possible.
- Write transformation logic for issues that cannot be fixed at the source.
- Build extraction, transformation, and load jobs that can rerun from scratch reliably.
- Automate reconciliation reports so every load produces a comparable quality summary.
- Log rejected records with reasons so owners can correct them before the next run.
Milestone: End-to-end migration pipeline runs unattended and produces a reconciliation report.
Test Loads (Weeks 15-20)
Rehearse the migration until results are predictable and accepted.
- Run at least three full trial migrations into a production-like target environment.
- Have business users validate migrated records through real workflows, not just spot checks.
- Measure load duration to confirm the cutover fits inside the planned downtime window.
- Test downstream integrations and reports against migrated data.
- Track defects by entity and rerun loads until acceptance criteria are met.
Milestone: A final rehearsal passes all reconciliation checks and business sign-off within the time window.
Cutover and Retire (Weeks 21-26)
Execute the production migration and safely decommission the legacy source.
- Publish an hour-by-hour cutover runbook with owners, checkpoints, and rollback criteria.
- Freeze source system changes and communicate the downtime window to all users.
- Run the production migration, reconcile results, and get formal go-live sign-off.
- Provide hypercare support for several weeks to handle data issues users report.
- Archive legacy data per retention rules and decommission the old system.
Milestone: Target system live with signed reconciliation and the legacy system archived or retired.
Who This Template Is For
This template fits data engineers, migration leads, IT project managers, and system implementation partners who own moving data into a new platform. It is equally useful for business owners who need to understand when they will be asked for decisions, cleanup effort, and testing time, which are the parts most often underestimated.
Small migrations, like moving one database to a managed cloud equivalent with the same schema, may only need the build, test, and cutover phases. The full template matters when schemas change, multiple sources merge, or business definitions differ between systems, because that is where mapping and cleansing consume most of the effort.
Workstreams to Run Side by Side
Technical migration work is only one lane. Data ownership, testing, and communication need their own owners, or they quietly become the migration team's problem. The most common delay is waiting on business decisions about definitions and scope, so make those decisions visible as milestones with dates.
Keep the target system build in its own lane if it is still being configured. Mapping against a moving target model is a frequent cause of rework, so freeze target design for each entity before building its transformation logic.
- Data governance: ownership, definitions, retention, and privacy decisions.
- Mapping and transformation: field mappings, rules, and key management.
- Data quality: profiling, cleansing, rejected record handling.
- Testing and reconciliation: trial loads, business validation, sign-off.
- Cutover and change: runbook, communication, training, hypercare.
Example: Migrating a Legacy CRM to a New Platform
Suppose a company moves from a self-hosted CRM to Salesforce. Discovery finds duplicate accounts created by different regions and contacts linked to deleted accounts. Business owners agree to migrate five years of opportunity history and archive the rest to a warehouse.
Mapping surfaces a conflict: one region tracks deal stages differently. The team defines a unified stage model and a transformation rule. Cleansing merges duplicate accounts using a match on domain and company name, reviewed by sales operations. Three trial loads reveal that attachments take far longer than expected, so the team migrates them in a separate wave after go-live. Cutover happens over a weekend with a tested runbook and two weeks of hypercare.
How to Keep the Roadmap Current
Update the roadmap after every trial load. Each run produces new facts: load durations, defect counts by entity, and rejected record volumes. Use them to adjust dates honestly. If the third rehearsal still fails reconciliation, add another rehearsal rather than compressing the cutover plan.
Hold a weekly steering check with business owners focused on open decisions and cleanup progress. Keep a decision log for mapping rules and scope changes, because months later someone will ask why a field was transformed a certain way, and the log is the only reliable answer.
Measuring Migration Readiness
Define go-live criteria before the first trial load: row count matches per entity, financial totals reconciled to the cent, zero critical defects open, and business sign-off from each data owner. Readiness is then a checklist rather than a debate in the final week.
Track trends across rehearsals: rejected record counts, defects found by business testers, and load duration. Those numbers should fall with each run. If they plateau, look for an unresolved root cause such as missing source cleanup or an ambiguous mapping rule.
Common mistakes to avoid
- Skipping data profiling hides quality problems until test loads fail, so profile every source in the discovery phase.
- Migrating everything by default bloats effort and risk, so agree on scope and history limits with business owners early.
- Running only one trial load leaves cutover timing unproven, so plan at least three full rehearsals.
- Relying on row counts alone misses broken relationships, so add financial totals, sample checks, and workflow testing.
- Leaving business owners out until testing delays decisions, so assign data owners and decision deadlines from the start.
- Decommissioning the legacy system immediately removes your fallback, so keep it read-only until hypercare ends.
Frequently asked questions
What are the main phases of a data migration?
The usual phases are scope and discovery, mapping and design, cleansing and pipeline build, test loads with reconciliation, and cutover followed by legacy retirement. Each phase ends with a sign-off, such as approved mappings or a passed rehearsal, so problems are caught before they reach production.
How long does a data migration take?
Medium-complexity migrations involving schema changes and data cleanup commonly fit in around six months, as in this template. Simple like-for-like database moves can be much shorter, while multi-source ERP consolidations often run longer. The biggest variables are data quality, number of sources, and how quickly business owners make decisions.
What should a data migration plan include?
It should include scope, source inventory, profiling results, field mappings, transformation rules, data quality ownership, tooling, a test load schedule, reconciliation criteria, a cutover runbook with rollback criteria, communication plans, and decommissioning steps. Each item needs an owner and a date.
Big bang or phased data migration: which is better?
Big bang moves everything in one cutover, which is simpler to coordinate but riskier if something fails. Phased migration moves entities or regions in waves, reducing risk but requiring temporary integrations between old and new systems. Choose based on downtime tolerance, data interdependencies, and how long you can support both systems.
How do you validate migrated data?
Combine automated reconciliation, such as row counts and financial totals per entity, with sampled field comparisons and business users running real workflows on migrated records. Automate the checks so every trial load produces the same report, and require sign-off from data owners before go-live.