Migration Plan Template: 14-Week Plan, Cutover and Rollback

8 min read ยท 2026-10-25

A migration plan template gives you a fixed structure for moving a system, data set or application from an old platform to a new one. It lists what moves, in what order, who does each step, how you test it, how you switch over on cutover day, and how you go back if something fails. Filling in the same sections every time means nothing important gets left to memory.

The template below fits a mid-size migration over about fourteen weeks, such as a CRM, an ERP module, a file server or an application moving to the cloud. It has six phases with steps and a checkable milestone for each. You will also find the sections your plan document should contain, a filled-in example, a cutover runbook outline, the metrics to track and how to present the plan to a steering committee.

The roadmap at a glance

Goal: All in-scope data and users run on the new platform, data is reconciled and signed off by the business, the old system is read-only or retired, and support has taken over. Duration: 14 weeks

  1. Scope and governance (Weeks 1-2)

    Agree on what moves, why, and who decides.

    • Write the migration scope: systems, data objects, users, integrations and what stays behind.
    • Name the sponsor, migration lead, business data owners and technical leads.
    • Set success criteria, such as reconciled record counts, key reports matching and users able to log in on day one.
    • Agree on the decision rules for go or no-go and who makes the call.

    Milestone: Signed scope and success criteria, with a named owner for each data object and integration.

  2. Inventory and assess (Weeks 2-4)

    Know exactly what exists today and what condition it is in.

    • List every data object, record count, field, attachment and history you need to move.
    • Map every integration, scheduled job and report that reads from or writes to the old system.
    • Profile data quality: duplicates, empty required fields, bad formats and orphan records.
    • Decide what to archive instead of migrate, such as closed records older than your retention rule.

    Milestone: An inventory and data quality report, with a decision on every object: migrate, archive or drop.

  3. Design the move (Weeks 4-6)

    Define how data and processes will look in the new platform and how you will get there.

    • Build the field mapping: source field, target field, transformation rule and owner.
    • Choose the approach: one big cutover, phased by region or module, or a period of running both systems.
    • Plan the cleanup work and assign it to business data owners with dates.
    • Write the rollback plan: the trigger, the steps and the latest point you can still go back.

    Milestone: Approved field mapping, migration approach and rollback plan.

  4. Build and run mock migrations (Weeks 6-11)

    Prove the migration works and measure how long it takes before the real one.

    • Build the extract, transform and load scripts or configure the migration tool.
    • Run at least two full mock migrations into a test environment with a copy of production data.
    • Reconcile each run: record counts, totals on key fields and spot checks by business users.
    • Time every step to set the length of the cutover window.
    • Run user acceptance testing on the migrated data and log every defect with an owner.

    Milestone: A final mock migration that passes reconciliation, fits the cutover window and has no open critical defects.

  5. Prepare and run the cutover (Weeks 11-13)

    Switch to the new platform in a planned, rehearsed window.

    • Write the cutover runbook: every step with owner, start time, duration and check.
    • Communicate the freeze period and the go-live date to users and dependent teams.
    • Hold the go or no-go meeting against the agreed criteria.
    • Run the cutover, reconcile the data and have business owners sign off before users return.

    Milestone: Cutover completed within the window, data reconciled and business sign-off recorded.

  6. Hypercare and decommission (Weeks 13-14 and after)

    Stabilize the new platform and close down the old one safely.

    • Staff a hypercare team with a daily issue review for the first weeks.
    • Watch integrations, scheduled jobs and key reports for errors.
    • Set the old system to read-only, then archive and retire it on the agreed date.
    • Hand over to the support team and hold a lessons-learned session.

    Milestone: Hypercare exit criteria met, support handover signed and the old system read-only or retired.

What goes in the migration plan document

A migration plan is usually a short document plus a few working files. The document holds the decisions. The working files, often spreadsheets, hold the detail that changes every week. Use these headings in the document and keep each one brief.

Keep the inventory, field mapping, defect log and cutover runbook in spreadsheets or in your project tool, and link to them from the plan. Then the document stays stable while the working files change daily.

  • Purpose and scope: what moves, what does not, and why.
  • Roles and decision rights: sponsor, migration lead, data owners, technical leads and who makes the go or no-go call.
  • Inventory summary: data objects, volumes, integrations and reports.
  • Approach: big cutover, phased or parallel run, with the reason.
  • Data quality and cleanup: issues found, cleanup owners and dates.
  • Testing and reconciliation: mock runs, UAT, and how you will prove the data is correct.
  • Cutover and rollback: the window, the freeze, the runbook and the point of no return.
  • Hypercare and decommission: support model, exit criteria and retirement date for the old system.
  • Risks and dependencies: each with an owner and a fallback.

Example: a CRM migration filled in

Picture a company moving its sales and service teams from an old on-premises CRM to a cloud CRM. There are several hundred thousand contact and account records, open opportunities, support cases and an integration with the billing system.

Closed cases older than the retention rule are archived instead of migrated. That cuts the data volume and the cutover window, and the archive stays searchable for audits.

  • Weeks 1-2 (owner: migration lead): scope signed: accounts, contacts, open opportunities, cases from the retention period, billing integration. Milestone: success criteria agreed with sales and service heads.
  • Weeks 2-4 (owner: data analyst): profiling finds many duplicate contacts and accounts with missing country codes. Milestone: migrate, archive or drop decided for every object.
  • Weeks 4-6 (owners: CRM architect, sales ops): field mapping complete, duplicates merged by sales ops before migration, single weekend cutover chosen. Milestone: mapping and rollback plan approved.
  • Weeks 6-11 (owner: integration developer): three mock runs, reconciliation on counts and open pipeline totals, UAT by ten sales and service users. Milestone: third run clean and inside the weekend window.
  • Weeks 11-13 (owner: migration lead): freeze from Friday evening, runbook run over the weekend, sign-off on Sunday. Milestone: users live on Monday morning.
  • Weeks 13-14 (owner: CRM support lead): daily issue review, billing sync monitored, old CRM set to read-only. Milestone: handover to support.

How to build the cutover runbook

The cutover runbook is the minute-by-minute script for go-live. Build it in a spreadsheet with these columns: step number, task, owner, backup owner, planned start, planned duration, actual start, actual end, status and check. The check column says how you know the step worked, such as a record count or a test login.

Group the rows into stages: pre-cutover checks, freeze and final backup, extract and load, reconciliation, integrations switched on, smoke tests, business sign-off and user communication. Mark the point of no return clearly. Before it, the rollback plan applies. After it, you fix forward. Run the runbook in your last mock migration so the timings are real.

Who owns what

Migrations go wrong when IT owns the data and the business only shows up at sign-off. Business data owners must decide what is correct, clean their own data and approve the result. IT owns the tools, scripts and environments.

List these roles in a RACI on the first page of the plan, with a backup for every person who has a step on cutover day.

  • Sponsor: approves scope, budget and the go or no-go decision.
  • Migration lead or project manager: owns the plan, the timeline, the runbook and status reporting.
  • Business data owners: decide mapping questions, own cleanup and sign off reconciled data.
  • Technical lead and developers: build and run migration scripts, environments and integrations.
  • Test lead: mock run reconciliation, UAT and the defect log.
  • Support lead: hypercare, user help and handover.

Metrics to track

Track readiness during the project and quality at cutover. Report them on a single status page every week, with a trend from one mock run to the next.

Agree in phase one on the thresholds that would stop a go-live, so the decision does not become a debate on the night.

  • Reconciliation results: record counts and totals on key fields, source against target, for each object.
  • Defects: open defects by severity after each mock run.
  • Data cleanup progress: issues fixed against issues found, by data owner.
  • Cutover duration: measured time of each mock run against the available window.
  • Post go-live issues: tickets per day during hypercare, and time to resolve them.

How to present the plan to a steering committee

Show one slide with the six phases on a timeline, today's position and the cutover date. Add a box with three numbers: last mock run reconciliation, open critical defects and cleanup progress. These tell leaders more about readiness than any task list.

On a second slide, show the top risks and the decisions you need, such as approval for a freeze period, business users released for UAT, or a firm retirement date for the old system. Before the go or no-go meeting, send the criteria and the current status in advance so the meeting is a decision, not a discussion.

Common mistakes to avoid

  • Migrating everything by default moves years of bad data, so decide for each object whether to migrate, archive or drop it.
  • Leaving cleanup to IT means nobody who knows the data fixes it, so give cleanup tasks to business data owners with dates.
  • Skipping mock migrations hides how long the cutover really takes, so run at least two full rehearsals with production-sized data.
  • Forgetting integrations and scheduled jobs breaks other systems on go-live, so map every inbound and outbound connection during the inventory.
  • Having no rollback plan forces a risky fix-forward at night, so write the rollback steps and the point of no return before cutover.
  • Shutting down the old system too soon removes your safety net, so keep it read-only until hypercare exit criteria are met.

Frequently asked questions

What should a migration plan template include?

It should include scope, roles, an inventory of data and integrations, the migration approach, data cleanup, testing and reconciliation, a cutover runbook, a rollback plan, hypercare and decommissioning. Add risks with owners and the success criteria for go-live.

What are the main phases of a migration?

Most migrations follow scope, inventory and assessment, design, build and mock runs, cutover, and hypercare with decommissioning. The names vary, but each phase should end with a milestone you can check, such as a reconciled mock run.

What is a cutover plan in a migration?

It is the detailed script for the switch from the old system to the new one. It lists each step with an owner, timing and a check, and marks the point after which you no longer roll back. Rehearse it in a mock migration first.

How do you verify that data migrated correctly?

Compare record counts and totals on key fields between source and target for each object. Have business users spot-check real records and run key reports in both systems. Record the results and get sign-off from the data owners.

Should you migrate all at once or in phases?

A single cutover is simpler when the system is tightly connected and the data fits in one window. A phased approach by region, module or user group lowers risk for large systems but means running two systems for a while. Choose based on dependencies and how long the old and new systems can run side by side.

Generate this roadmap with AI