How long does a system migration take?

This template spans about eight months from stakeholder workshops to hypercare exit, nested three deep under Data Migration and split into communications and go-live under User Cutover. The elapsed time is driven less by engineering than by data quality and user readiness — mapping and cleansing alone take about nine weeks here, and the legacy system isn't actually decommissioned until after go-live, not before it.

What is the most commonly underestimated part of a migration?

Data cleansing. Teams plan the extract-transform-load work and treat cleansing as a preliminary, when in practice the source data is worse than anyone expects and cleansing expands to fill whatever time is available. This template gives field validation and cleansing rules a combined six weeks before any batch load begins, and that's a floor rather than a generous allowance.

When should users be told about a migration?

Earlier than feels comfortable. This template starts user communications five days after the first historical batch load begins — a start-to-start link, not a date picked in isolation — and runs them for six weeks before training starts. Migrations that announce themselves a fortnight before cutover generate resistance that no amount of training can undo.

How do I show a cutover window on a Gantt chart?

As a short bar at the end with a milestone on its far edge, which is how this template does it — a go-live window of about a week and a half closing on the go-live milestone. A cutover has real duration because rollback windows and data freezes sit inside it, so a single-day marker understates it.

Can I run a phased migration with this template?

Yes, and for large user bases you probably should. Duplicate the User Cutover lane once per wave, stagger each wave's training and go-live window by a few weeks, and keep one shared Data Migration lane feeding all of them. Point the legacy-archival start-to-finish link at the final wave rather than the first, which is the link most often set wrongly on phased plans.

Templates / Migration Roadmap

Migration Roadmap

A migration plan running legacy-system retirement, a three-deep data migration track — mapping, then ETL split into batch loads and reconciliation — and a user cutover track split into communications and the go-live window itself, all converging on hypercare. The dependency chain leans on start-to-start links, the shape a real cutover actually takes, plus a start-to-finish gate on legacy archival and a finish-to-finish link tying financial reconciliation to the go-live window closing. Useful for a systems or data migration lead who needs to show several workstreams converging on one cutover, not a single "migrate" bar.

Discovery & Planning
Legacy Retirement
Data Migration
User Cutover
Hypercare

Templates are a Pro feature — every project starts editable, and this one drops straight in once you're signed in.

See pricing

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 — the phase whose output gates the very end of the project, but whose own completion lands after go-live, not before it.

Data Migration splits into Mapping & Cleansing (data mapping, field-level validation, cleansing rules) and ETL & Validation — itself split 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 — rehearsal, the go-live window itself, and post-go-live smoke tests.

Hypercare covers hypercare support and legacy access revocation.

Seven milestones: migration scope agreed at the start, data mapping complete, comms sent, data validated, go-live, legacy decommissioned, and hypercare exit at the close.

How long does each migration phase take?

About eight months in total. Discovery & Planning runs about six weeks. Legacy Retirement is the longest single lane at roughly twenty-four weeks once archival's true finish date is counted. Data Migration spans about twenty-one weeks across mapping and ETL together. User Cutover runs about fourteen weeks, and Hypercare closes the programme in five.

Two figures deserve scrutiny when you adapt this. Mapping and cleansing together run about nine weeks, and that's a minimum — it's the phase most likely to need doubling once someone actually profiles the source data. And data archival doesn't finish until after go-live has already started — the template deliberately doesn't let "legacy retired" happen before cutover, because the final delta can't be captured until then.

Which dependencies matter in a migration?

Twenty-three links, and the mix of types is the whole design.

Thirteen are finish-to-start and strictly sequential: the audit finishes before target architecture starts; mapping finishes before field validation starts; validation finishes before cleansing starts; training finishes before rehearsal starts, which finishes before the go-live window opens.

Eight are start-to-start, and they're what make the eight-month timeline possible rather than a fully serialised one. The historical batch load starts, and user communications start — you tell people the migration is happening five days after the data work is genuinely underway, not once every batch has loaded. Target architecture design gates both the decommission plan and data mapping as start-to-start predecessors — the two aren't sequenced behind each other, so planning for retirement and planning the new schema begin together the moment the architecture work is locked in, instead of queuing one behind the other.

The most important link is the last one: the go-live window starts, and data archival finishes — a start-to-finish link. Archival can't be called complete until cutover is genuinely underway, since the final delta has to be captured first. Delete it and the legacy system reads as "retired" while it's still the system of record.

One link is finish-to-finish: financial close reconciliation is pinned to finish alongside the go-live window itself, so the books close in step with the cutover rather than on a separately-guessed date.

What to change for your own migration

Profile the source data before trusting the mapping bars

Everything downstream depends on it. If nobody has yet counted how many records fail validation, the cleansing bar is a guess, and it's the guess most likely to be wrong by a factor of two.

Fix the go-live date against the business calendar

Cutover windows collide with month-end, quarter-end, and peak trading. Place go-live where the business can absorb it, then work backwards through the chain.

Split training if user groups differ

One training bar is a simplification. Finance users and warehouse users need different sessions on different dates, and each is a bar someone owns.

Add a rollback decision milestone

Immediately before the go-live window. It's the point at which you commit, and making it a visible date turns an implicit decision into an explicit one.

Baseline once the scope milestone is agreed

Migration scope creep is the norm rather than the exception, and a baseline is the only way to show a steering group how much of a delay is scope rather than execution.

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.

Decommissioning shown as finishing before go-live. It's backwards — the legacy system is still the system of record until cutover actually happens, and the chart should say so.

A one-day cutover. Rehearsal, the go-live window, and smoke tests 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 puts it immediately before rehearsal, which is correct.

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.

Start free See pricing

Questions about this template

How long does a system migration take?: This template spans about eight months from stakeholder workshops to hypercare exit, nested three deep under Data Migration and split into communications and go-live under User Cutover. The elapsed time is driven less by engineering than by data quality and user readiness — mapping and cleansing alone take about nine weeks here, and the legacy system isn't actually decommissioned until after go-live, not before it.
What is the most commonly underestimated part of a migration?: Data cleansing. Teams plan the extract-transform-load work and treat cleansing as a preliminary, when in practice the source data is worse than anyone expects and cleansing expands to fill whatever time is available. This template gives field validation and cleansing rules a combined six weeks before any batch load begins, and that's a floor rather than a generous allowance.
When should users be told about a migration?: Earlier than feels comfortable. This template starts user communications five days after the first historical batch load begins — a start-to-start link, not a date picked in isolation — and runs them for six weeks before training starts. Migrations that announce themselves a fortnight before cutover generate resistance that no amount of training can undo.
Why does legacy decommissioning finish after go-live starts, not before it?: Because that's the actual constraint on most cutovers. This template ties data archival's *finish* to when the go-live window *starts* — archival can't be called complete until cutover is genuinely underway, since the final delta has to be captured first. A finish-to-start link would force decommissioning to finish before cutover can even begin, which gets the sequence backwards.
How do I show a cutover window on a Gantt chart?: As a short bar at the end with a milestone on its far edge, which is how this template does it — a go-live window of about a week and a half closing on the go-live milestone. A cutover has real duration because rollback windows and data freezes sit inside it, so a single-day marker understates it.
Can I run a phased migration with this template?: Yes, and for large user bases you probably should. Duplicate the User Cutover lane once per wave, stagger each wave's training and go-live window by a few weeks, and keep one shared Data Migration lane feeding all of them. Point the legacy-archival start-to-finish link at the final wave rather than the first, which is the link most often set wrongly on phased plans.