A 14-week plan for moving a legacy system or on-prem database to a new cloud platform or CRM, sequencing mapping, ETL, cleansing, staging tests, cutover and hypercare.
Data migration projects fail less often from bad code than from bad assumptions: a field nobody mapped, a validation rule nobody wrote down, a stakeholder who assumed the old reports would still work. This template lays out a 14-week plan for moving a legacy system or on-prem database to a new cloud platform or CRM: discovery and a full data audit, field-by-field mapping, a built and tested ETL pipeline, cleansing before anything moves, a staging dry run, formal validation and reconciliation, user acceptance testing, and a cutover with a rollback plan you actually intend to use. Hypercare and legacy decommissioning close it out. Open it, adjust the dates, and you have a working plan.
How a 14-week data migration plan breaks down
01
Weeks 1–2: Discover, audit, and define scope
Weeks 1–2
Before anything gets mapped or moved, you need a precise inventory of what exists: every legacy table, field, integration, and report that depends on the current system, plus who owns each one. Discovery workshops surface the undocumented dependencies. The spreadsheet macro nobody remembers, the nightly export three other teams rely on. Scope and success criteria get locked at the end of this phase, in writing, so "done" means something specific later.
Every legacy field gets matched to a target field (or explicitly marked as not migrating), including type conversions, default values, and the handful of fields that mean something different in the new system. In parallel, the target environment (cloud instance, CRM org, database schema) gets provisioned and locked down: roles, permissions, encryption, and network access configured before a single record lands in it.
Match every legacy field to a target field
Document type conversions and default values
Provision the target environment (cloud, CRM, or schema)
Lock down roles, permissions, and encryption
03
Weeks 6–9: Build, cleanse, and test in staging
Weeks 6–9
The ETL scripts get built against the mapping doc, and legacy data gets cleansed in parallel: duplicates merged, orphaned records resolved, formats standardized, so garbage doesn't just move to a nicer database. The first full dry run happens in a staging environment that mirrors production, followed by formal validation and reconciliation: row counts, checksums, and spot-checks against the source, run until the numbers match.
Build ETL/migration scripts against the mapping doc
Cleanse source data (dedupe, standardize, resolve orphans)
Run a full dry run in staging
Validate and reconcile record counts and checksums
04
Weeks 10–11: UAT, training, and cutover planning
Weeks 10–11
Business users test the migrated data in staging against real workflows, not just sample records. The goal is to catch the mapping error that only shows up on a weird edge-case account. End users get trained on the new system while the cutover plan and rollback plan get written side by side: what happens on go-live day, and exactly how to reverse it if reconciliation fails after the fact.
Run UAT against real business workflows, not just samples
Train end users and update documentation
Write the cutover plan (step-by-step, timed)
Write the rollback plan and define its triggers
05
Weeks 12–14: Go-live, hypercare, and decommission
Weeks 12–14
A go/no-go review checks every exit criterion before the legacy system freezes and the final cutover runs. Hypercare follows immediately. The team watches error rates, data-quality checks, and user-reported issues closely for about two weeks, fixing anything that surfaces fast rather than letting it compound. Only once hypercare confirms the new system is stable does the legacy system get decommissioned.
Run a go/no-go review against exit criteria
Freeze the legacy system and run final cutover
Monitor closely during hypercare (about 2 weeks)
Decommission the legacy system once stable
Tips from real data migration projects
01Cleanse before you migrate, not after. Moving bad data into a new system just gives you the same problems with a shinier interface.
02Run at least two full dry runs in staging before the real cutover. The first one always finds a mapping error nobody predicted.
03Write the rollback plan before the cutover plan, not after. If you can't describe how to reverse it, you're not ready to run it.
04Keep the legacy system in read-only mode during hypercare instead of shutting it down immediately: it's the cheapest insurance policy you'll buy.
05Reconcile on record counts AND checksums. Counts can match while individual fields are silently wrong.
06Budget hypercare as its own phase, not a buffer. Two weeks of close monitoring catches the issues that only show up under real usage.
Frequently asked questions
How long does a typical data migration take?
For a mid-size system of a few hundred thousand records and one or two integrations, 14 weeks is realistic from discovery to decommissioning. Larger migrations with many source systems or heavy compliance requirements often run 6–12 months.
What's the most common reason data migrations fail?
Skipping or rushing the data audit. Teams that jump straight into building ETL scripts without a full inventory of legacy fields and dependencies keep discovering new edge cases mid-migration, and each one costs more to fix the later it's found.
Can I open this template and customize it?
Yes. Click "Open this template in the app". It loads instantly, and you can drag, rename, and re-color every task. The app runs entirely in your browser. Your data never leaves the device.
Open the data migration template, line up the dates against your go-live target, and you have a working 14-week plan with cutover and rollback both covered.
Gantt Chart Maker