Plans · Software

Migrate to a new database

10 weeks · 5 phases · 26 tasks · 5 milestones · 5 risks

For an engineering team moving a production application from one database to another, whether a new engine or a new host. The weeks run from inventory and design through copying and verifying data to a staged cutover with a tested rollback. Adapt the cutover approach to how much downtime you can accept: a short maintenance window is simpler than a zero-downtime switch.

Open this in Harbor

Makes it a program in your harbor, dated from today.

Milestones

Week 2Plan reviewed
Week 5Application passes tests on the new database
Week 7Data verified
Week 9Writes on the new database
Week 10Old database retired

The plan, phase by phase

1. Assess

Weeks 1 to 2. Understand what is moving and what depends on it.

Week 1Inventory every service that reads or writes the databaseInclude scheduled jobs, reporting tools and one-off scripts. These are the ones that get missed.
Week 1Record current size, growth and peak loadThis sizes the new database and tells you how long a full copy will take.
Week 1List engine-specific features in useStored procedures, triggers, extensions, special types and full-text search are the usual ones.
Week 2Agree acceptable downtime with the businessA short planned window is often cheaper and safer than engineering for none.
Week 2Write the migration plan and get it reviewed

2. Prepare

Weeks 2 to 5. Stand up the new database and make the code work with it.

Week 2Provision the new database with backups and monitoringTest a restore from backup before any real data goes in.
Week 3Translate the schema and indexes
Week 4Update queries that rely on old engine behaviorWatch for differences in collation, date handling, null sorting and transaction isolation.
Week 4Run the test suite against the new database
Week 5Load test the new database with production-like traffic

3. Copy and verify

Weeks 5 to 7. Get the data across and prove it matches.

Week 5Run a full trial copy and time itThe timing tells you whether a cutover window is realistic.
Week 6Set up ongoing replication or dual writesChoose one approach and make it observable, so you can see lag at any moment.
Week 6Write verification checks for row counts and checksums
Week 7Compare query results between old and new
Week 7Fix data differences and recheck

4. Cut over

Weeks 7 to 9. Move traffic in steps, with a way back at each one.

Week 7Write and rehearse the rollback planRehearse it on staging. A rollback nobody has tried is not a plan.
Week 8Rehearse the cutover on staging
Week 8Move read traffic to the new database
Week 8Announce the maintenance window
Week 9Switch writes to the new databaseDo it in the agreed window with the rollback steps open in front of you.
Week 9Watch error rates and latency closely for a week

5. Clean up

Week 10. Retire the old database once you're sure you don't need it.

Week 10Stop replication to the old database
Week 10Take a final backup of the old databaseKeep it for an agreed period in case anything turns up later.
Week 10Remove old connection strings and config
Week 10Update runbooks and documentation
Week 10Decommission the old database

What usually goes wrong

A forgotten consumer breaks
A report, cron job or script still pointed at the old database fails or reads stale data.
What helps: Check connection logs on the old database for every client before cutover, and watch them after.
Likelihood 4 of 5 · impact 3 of 5
Subtle behavior differences
Engines differ in sorting, time zones, and type coercion, and tests rarely cover all of it.
What helps: Compare real query results between the two databases and review every engine-specific feature in use.
Likelihood 3 of 5 · impact 4 of 5
Data drifts during the sync
Writes that miss replication leave the new database quietly out of date.
What helps: Run verification checks daily during the sync, not only before cutover, and alert on lag.
Likelihood 3 of 5 · impact 5 of 5
Performance is worse under real load
Different query planners and missing indexes show up only with production traffic.
What helps: Load test with production-like queries, move reads first, and watch slow-query logs.
Likelihood 3 of 5 · impact 4 of 5
Rollback doesn't work when needed
Once writes land on the new database, going back means moving them too.
What helps: Rehearse rollback on staging, and keep reverse replication running until you're confident.
Likelihood 2 of 5 · impact 5 of 5

Using it

Copy what fits and cut what doesn’t: no real project matches a template. In Harbor the plan becomes a program with these milestones, one project holding every task with its due date, and these risks in the register, all yours until you hand them out. The first phase starts in To do and the rest wait in the backlog.

Open this in Harbor

More plans

See every plan