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.
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.
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.
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.
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.
| Group | Weeks | What happens | Owners |
|---|---|---|---|
| Scope and inventory | 1 to 2 | Agree 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 build | 2 to 4 | The vendor's test environment, the field mapping, the reconciliation checks and the extract, transform and load scripts. | Analyst, finance lead, IT, vendor |
| Cleansing | 3 to 6 | Duplicates and incomplete records fixed in the old system, then the quality profile run again. | Data owners, analyst |
| Trial migration 1 | 5 to 6 | A 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 2 | 7 to 8 | A 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 weekend | 8 | Users told, changes frozen on Friday, the final load on Saturday and its reconciliation on Sunday. | Lead, data owners, IT, finance lead |
| Hypercare and switch-off | 9 to 10 | Two 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.
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.
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.
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.
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.
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.
Replace the sample durations and role labels, then agree the trial runs and cutover window with the people doing the work.
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.
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.
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.
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.