Data Migration Gantt Chart Template

Migrations are judged entirely on the last week. Months of careful mapping count for nothing if users arrive on Monday to find their records missing, and the plan that prevents that is one where data readiness and people readiness are tracked as separate, equally serious workstreams, nested deep enough to show the real choreography. This template is arranged that way.

Who this migration roadmap template is for

This is for whoever owns a system replacement, an IT programme manager, a solution architect, an operations lead. It assumes you're moving off a system that holds real historical data, that users depend on it daily, and that the old system has to be switched off rather than left running.

That last assumption is what distinguishes a migration plan from an implementation plan. If nothing is being retired, you're implementing, and the executive roadmap template is a better fit.

What are the phases of a migration plan?

Five top-level lanes: one of them nested three deep, another split into two.

Discovery & Planning covers stakeholder workshops, a legacy system audit, and target architecture design.

Legacy Retirement covers the decommission plan, license and contract wind-down, and data archival & retention. The first two close out before cutover; archival runs for the length of the whole project, since retention obligations don't end just because the system has been switched off.

Data Migration splits into Mapping & Cleansing (data mapping, field-level validation, cleansing rules) and ETL & Validation. ETL & Validation itself splits into Batch Loads (historical, then incremental, then delta sync) and Reconciliation (automated checks, manual review, then financial close reconciliation).

User Cutover splits into Comms & Training and Go-Live: the go-live window itself and post-go-live smoke tests.

Hypercare covers hypercare support in the final weeks of the schedule.

Two milestones: data mapping complete, midway through the mapping and cleansing work, and comms sent, once user communications begin.

How long does each migration phase take?

A little over five months in total. Discovery & Planning runs about two weeks. Legacy Retirement is the longest single lane at twenty weeks, but that's because data archival & retention runs across nearly the whole project rather than as a discrete late-stage task; decommission planning and licence wind-down, the two tasks that actually gate cutover, close out in about six weeks. Data Migration spans roughly fifteen weeks across mapping, batch loads, and reconciliation together. User Cutover runs about thirteen weeks, and Hypercare closes the programme in the final three and a half weeks.

One figure deserves scrutiny when you adapt this. Reconciliation (automated checks, manual review, and financial close reconciliation) runs almost eight weeks, and it's sequenced so each stage only starts once the batch loads feeding it have landed. Compressing this into "a final check" is the single easiest way to understate a migration's real timeline, since matching data back to source is where discrepancies actually surface, not before.

Which dependencies matter in a migration?

Four links, and this template deliberately doesn't over-link. Most of the schedule's real sequencing comes from fixed dates set directly against the business calendar rather than from chained dependencies, a smaller, more honest set of drawn arrows than a fully-linked chain would suggest.

Three are finish-to-start: the decommission plan finishes before licence and contract wind-down starts, so retirement admin doesn't begin until there's an agreed plan to retire against. User communications finish before end-user training starts, so people hear about the migration before they're trained on the replacement. Post go-live smoke tests finish before hypercare support starts, so the team isn't running both at once.

One is start-to-start: target architecture design and the decommission plan begin together. Planning what the new system looks like and planning how the old one gets retired start from the same trigger, rather than queuing retirement planning behind the architecture work finishing.

Everything else (the batch-load sequence, reconciliation, comms timing relative to the first batch load, and data archival's long span across the whole project) is expressed through each task's own start and end dates rather than a drawn link. That's a legitimate way to model a schedule: a dependency arrow is for a relationship that should hold even if dates move, and not every real-world sequencing choice needs one drawn to be visible on the chart.

What to change for your own migration

Common mistakes on migration timelines

Cleansing treated as a preliminary. It's the longest and least predictable task in the project and it deserves its own bars, not a single placeholder.

Communications starting after the data work. By then people have heard rumours and formed opinions, and you're correcting rather than informing.

Archival shown as a short task at the end. Retention obligations don't end when the old system goes dark, and modelling archival as a brief closeout task understates how long the organisation is actually on the hook for the legacy data.

A one-day cutover. The go-live window and the smoke tests that follow it don't fit in a day, and compressing them on the chart doesn't compress them in reality.

Training scheduled too early. Training people weeks before go-live means retraining them. This template ends training just three days before the go-live window opens, which keeps what users learned fresh instead of stale.

Sharing the migration plan

Migration plans are read by more people than almost any other project chart: users, support teams, the vendor, the steering group. Export a PDF for the formal pack and a PNG for the weekly update, and re-export as the bars move. Nobody needs an account to open it, which matters when the audience includes an entire user base rather than a project team.