Database Migration Plan: 12-Week Template, Cutover Runbook and Example

10 min read · 2026-10-25

A database migration plan is the document that says what data moves, from which system to which target, with which method, in what order, who does each step, how you will prove the data is right and how you will roll back if it is not. It turns a risky technical change into a schedule with owners, test gates and a go/no-go decision.

The template below covers a typical 12-week migration of one production database, for example from on-premises SQL Server to a managed cloud service, or from Oracle to PostgreSQL. It is written for the engineering manager, DBA or project manager who has to run the project and explain it to stakeholders. It includes a filled-in example, a cutover runbook outline, validation checks and the traps that make migrations slip.

The roadmap at a glance

Goal: The production database runs on the target platform, every dependent application is pointed at it, data is validated against the source and the old system is retired after an agreed safety period. Duration: 12 weeks

1. Inventory and requirements (Weeks 1-2)

   Know exactly what you are moving and what the business can tolerate.

   • List every schema, table, view, stored procedure, trigger, job and user account, with sizes and row counts.
   • Find every application, report, ETL job and integration that reads or writes the database, and name an owner for each.
   • Agree on the allowed downtime window and the acceptable data loss (RPO) and recovery time (RTO) with the business owner.
   • Note security and compliance needs, such as encryption, data residency and audit logging, and confirm them with your security team.

   Milestone: A signed-off inventory and a requirements page with downtime window, RPO, RTO and the list of dependent systems with owners.

2. Strategy and target design (Weeks 2-4)

   Choose how the data will move and design the target environment.

   • Choose the migration method: offline dump and restore, native replication, or a full load followed by change data capture (CDC).
   • Decide whether this is a lift and shift on the same engine or a change of engine that needs schema and code conversion.
   • Size the target for storage, compute, connections and backup retention, using current usage plus planned growth.
   • Write the rollback approach: how long the source stays live and whether changes on the target are synced back.

   Milestone: A short design document with method, target sizing, network and security setup, and a rollback approach, approved by the tech lead and the business owner.

3. Build target and convert schema (Weeks 4-6)

   Have a target environment ready with the full schema and supporting code.

   • Provision the target with infrastructure as code where possible so environments match.
   • Convert the schema, data types, procedures and functions, and log every manual change in a conversion register.
   • Set up users, roles, backups, monitoring and alerts on the target before any data arrives.
   • Set up the migration tool (for example AWS Database Migration Service, Azure Database Migration Service or native replication) in a test environment.

   Milestone: Target environment built, schema deployed, monitoring live and a first trial load completed in test.

4. Data migration and validation in test (Weeks 6-8)

   Prove the data arrives complete and correct.

   • Run a full trial load from a recent production copy and time each step.
   • Compare row counts per table and checksums or sampled record comparisons on key tables.
   • Check data types, character encoding, time zones and null handling on fields that often break, such as dates and accented text.
   • Fix issues in the conversion scripts, then rerun the load until two runs in a row pass.

   Milestone: Two consecutive trial loads pass all validation checks, with measured load time that fits inside the downtime window.

5. Application testing and rehearsal (Weeks 8-11)

   Make sure every application works on the new database and the cutover can be run on time.

   • Point test copies of each dependent application at the target and run their regression suites.
   • Run performance tests on the busiest queries and batch jobs and compare with the source.
   • Have business users run key reports and transactions and sign off on results (user acceptance testing).
   • Rehearse the full cutover runbook end to end, including rollback, with the real team and a timer.

   Milestone: UAT sign-off from each application owner and a timed rehearsal, including rollback, that fits inside the window.

6. Cutover and hypercare (Weeks 11-12)

   Switch production to the new database and stabilize it.

   • Freeze schema changes and non-urgent releases from one week before cutover.
   • Hold the go/no-go meeting with the agreed criteria, then run the runbook step by step with a named owner per step.
   • Validate data and run smoke tests before reopening to users, and keep the rollback trigger clear.
   • Watch performance, errors and job runs closely for one to two weeks, then retire the source after the agreed safety period.

   Milestone: Production running on the target, all dependent applications switched, validation report signed and a decommission date set for the source.

Common mistakes to avoid

• Skipping a full inventory leaves forgotten jobs and reports to fail after cutover, so trace every client connection to the source before you set a date.
• Validating only row counts misses corrupted values, so add checksums or sampled record comparisons on key tables.
• Testing the load but not the applications leads to broken features on day one, so have each application owner run their regression suite and UAT on the target.
• Running cutover without a rehearsal turns the night into improvisation, so rehearse the full runbook with a timer and the real team at least once.
• Leaving the rollback decision vague causes delays when things go wrong, so write a clear trigger and name who can call it before the night.
• Deleting the source right after go-live removes your safety net, so keep it read-only for an agreed period before you decommission it.

Frequently asked questions

What should a database migration plan include?

It should include the inventory of objects and dependent systems, the migration method, the target design, the validation approach, the testing plan, the cutover runbook with rollback, and owners and dates for each step. Add the downtime window, RPO and RTO agreed with the business owner.

How long does a database migration take?

It depends on data size, the number of dependent applications and whether the engine changes. A same-engine move of one database can fit in a few weeks to a few months, while a change of engine with heavy stored procedure logic often takes longer. Plan around test gates rather than a fixed date.

How do you validate data after a migration?

Compare row counts per table, then run checksums or field-by-field comparisons on samples from key tables. Check tricky fields like dates, decimals and special characters. Finally, have business users run known reports and transactions and compare the results with the source.

How do you migrate a database with minimal downtime?

Use a full load followed by continuous replication or change data capture, so the target stays nearly in sync with the source. At cutover, you only stop writes long enough to apply the last changes, validate and switch connections. Rehearse it first so you know how long that takes.

What is the difference between a database migration and a data migration?

A database migration moves a whole database, including schema, code and data, to a new platform or engine. A data migration moves data between systems, often with transformation, such as moving customer records from an old CRM to a new one. Both need validation and a cutover plan.

Generate this roadmap with AI