About this template
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
Weeks 1–2 — Discover, audit, and define scope
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.
- Run discovery workshops with every system owner
- Inventory legacy tables, fields, and integrations
- Identify undocumented dependencies (reports, exports, macros)
- Define scope and written success criteria
Weeks 3–5 — Map the data and stand up the target
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
Weeks 6–9 — Build, cleanse, and test in staging
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
Weeks 10–11 — UAT, training, and cutover planning
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
Weeks 12–14 — Go-live, hypercare, and decommission
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
- Cleanse before you migrate, not after. Moving bad data into a new system just gives you the same problems with a shinier interface.
- Run at least two full dry runs in staging before the real cutover. The first one always finds a mapping error nobody predicted.
- Write 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.
- Keep the legacy system in read-only mode during hypercare instead of shutting it down immediately — it's the cheapest insurance policy you'll buy.
- Reconcile on record counts AND checksums. Counts can match while individual fields are silently wrong.
- Budget 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 — a few hundred thousand records, 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.