Data migration plan template

This data migration plan template schedules about ten weeks from the first record count to switching off the old system. The editable chart covers mapping, cleansing, two trial migrations, a cutover weekend and hypercare, with roles written into task names.

The first three weeks of a data migration plan in Ganttile, by day: scope, the inventory of source tables, the data quality profile and the retention decision, then field mapping, reconciliation checks and cleansing starting side by side
  • 7 groups
  • 27 tasks
  • 3 milestones
  • 33 dependencies
  • About 10 weeks
  • Updated October 26, 2026

We make Ganttile. The systems, record types and durations in this template are sample data for a made-up migration, so replace them with your own.

When should you use this migration plan?

Choose this migration plan when you need to move records from one system to another: an old CRM into a new one, a finance package into its replacement, or years of spreadsheets into a database. The sample runs for about ten weeks, from counting the source records to switching off the old system.

The plan is for an IT lead, project lead or analyst coordinating the move with the business. Finance, data owners and key users have rows showing when they need to check and approve the data.

If the migration is one part of bringing in new software, use the software rollout schedule and keep this chart for the data. That template fits the data into a six-month rollout; this one gives it ten weeks of its own.

Does Ganttile move the data?

No. Ganttile schedules the migration. It does not connect to either system, run extract scripts or compare records, and it will not tell you whether a reconciliation passed. Those jobs belong to your scripts, an ETL tool or the new system's own import tools.

Use the chart to show IT and the business the task order, waiting periods and dependencies. With Auto schedule on, a late trial moves the linked cutover tasks.

What happens in each stage?

Seven groups cover scope and inventory through to hypercare and switch-off. Mapping, cleansing and the first trial overlap: data owners clean the old system while IT builds and tests the migration scripts.

GroupWeeksWhat happensOwners
Scope and inventory1 to 2Agree the scope and the cutover window, list every table and file with its record count, profile the data quality and decide what moves, what is archived and what is dropped.Lead, IT, analyst, data owner
Mapping and build2 to 4The vendor's test environment, the field mapping, the reconciliation checks and the extract, transform and load scripts.Analyst, finance lead, IT, vendor
Cleansing3 to 6Duplicates and incomplete records fixed in the old system, then the quality profile run again.Data owners, analyst
Trial migration 15 to 6A first load into the test environment, reconciled against the old system, checked by key users, then the fixes.IT, finance lead, key users
Trial migration 27 to 8A second load run and timed like the real cutover, reconciled again, the runbook and rollback plan, then the go / no-go decision.IT, finance lead, lead
Cutover weekend8Users told, changes frozen on Friday, the final load on Saturday and its reconciliation on Sunday.Lead, data owners, IT, finance lead
Hypercare and switch-off9 to 10Two weeks of daily data fixes, an archive extract for retention, the data owner's sign-off and the old system switched off.IT, data owner

Ganttile has no assignment field. Roles such as IT, Analyst and Finance lead appear at the front of task names instead. A copied template has no people in it, so replace those role labels with names.

Why run two trial migrations?

The first trial finds mapping and script errors; the second checks the fixes and rehearses the cutover. A first load usually turns up something the mapping missed, such as a status that means something else in the new system or notes cut short. If the first load is also the real one, those problems surface on Monday morning in front of every user.

Trial 1 is checked two ways. The finance lead reconciles it against the old system, and key users open real records in the new one to look for what counts cannot show. IT has a week to fix their findings before trial 2.

Trial 2 is run exactly as the cutover will be, in the same order, with every step timed. Use those timings to write the cutover runbook, the step-by-step weekend plan. If trial 2 still fails its checks, add a third trial and move the go / no-go milestone. That is cheaper than a weekend that has to be rolled back.

What should the reconciliation check?

Reconciliation checks whether the migrated records match the source data. Agree record counts, totals, sample checks and pass criteria before the first load. In the sample, the finance lead writes these checks in week three, alongside the field mapping.

  • Record counts: the number of customers, open orders, invoices or whatever you move, per type, in both systems.
  • Totals: sums that would change if a record went missing or doubled, such as open balances or the value of open orders.
  • Sample records: a few dozen records compared field by field, picked to include the awkward ones.
  • Pass criteria: what difference is acceptable, and who decides when a check is passed.

Where can the plan absorb a delay?

The vendor's test environment, reconciliation checks and archive extract have room for a delay. Cleansing does not.

Critical path is off by default and highlights correctly only with Hide weekends on. Turn both on under Settings and most of the plan is highlighted: the inventory, the profile, the mapping, the scripts, the cleansing, both trials, their reconciliations and the fixes in between. A slip in any of those moves the go-live date.

Cleansing runs in the old system from week three, so every trial picks up the fixes, and trial 2 waits for the re-run profile. If the data is dirtier than the profile suggested, go-live moves.

Auto schedule is also off by default. Turn it on and stretch the cleansing bar by a week. The trial, the go / no-go decision and the cutover all move with it, which is worth seeing before anyone books the weekend.

What happens on the cutover weekend?

Changes stop in the old system on Friday, IT runs the final extract and load on Saturday, and the finance lead reconciles it on Sunday. On Monday the users start in the new system and hypercare, the period of extra support and daily data checks, begins. Hide weekends squeezes the Saturday and Sunday rows out of view, so turn it off again when you work on the cutover.

The runbook written after trial 2 lists each step, its owner and its timing. It also sets the rollback trigger: which failure, found by what time, sends everyone back to the old system on Monday. Agree that decision before the cutover weekend.

When can the old system be switched off?

In this sample, switching off the old system requires three things: ten days of hypercare without new data problems, an archive extract of the old system kept for retention, and the data owner's sign-off. The last milestone is Old system switched off, and it waits for all three. Leaving it on for a year means people can keep using it.

What should you change for your own migration?

Replace the sample durations and role labels, then agree the trial runs and cutover window with the people doing the work.

  1. Replace sample durations. Use the record counts and problems found during inventory and profiling.
  2. Size the cleansing. Nineteen days is a placeholder. Large volumes with many duplicates need longer, and the cleansing has to finish before trial 2.
  3. Choose the trial count. Two is the minimum worth having. Copy the trial group for a third if the data is messy or the stakes are high.
  4. Agree the cutover window. Month-end, payroll runs and busy seasons are bad weekends for a cutover. Fix the date in week one.
  5. Include the task owners. Invite the data owners, the finance lead and the vendor through the linked Breeze account, free, and they can view and edit the chart. For anyone outside the team, export a PDF or an image.

Click Use template and the plan is copied into your account starting on the coming Monday, with the links, estimates and checklists in place. The preview opens at Month zoom, with the ten weeks as week columns. You can export the finished plan to Excel or Microsoft Project XML for anyone who works in those tools.

Common questions

Is a data migration plan the same as an implementation plan?

No. An implementation plan covers the whole rollout of new software: configuration, integrations, testing, training and launch. A data migration plan covers only moving the records, and it often sits inside the implementation plan as one stream.

How long does a data migration take?

A data migration has no standard duration. This template's ten weeks assume one source system and a moderate amount of cleansing. The data quality profile in week two is what tells you whether yours needs more time.

Can I use this data migration plan for a server or cloud migration?

The data migration plan can partly support a server or cloud migration. The trial runs, go / no-go decision, cutover weekend and rollback plan carry over. You would replace the mapping and cleansing groups with infrastructure and application testing tasks.