Database Migration
Moving engines, versions and schemas without losing data or uptime.
6 to work through
-
beginner Multiple choice
A team plans to move 2.5 TB to a new database by taking the application offline at 22:00 on Saturday, restoring a backup into the new store, and switching over by 08:00 Sunday. The data copies fine in a test at one tenth the volume. Why does this plan usually fail before it is executed?
3 min answer -
advanced
A billing platform is extracting services from a shared database. Should the code be split first or the data?
2 min answer -
advanced
A product must move its primary data store while remaining live, with no acceptable data loss. What is the migration sequence, and where do these go wrong?
2 min answer -
advanced
An online schema change is needed on a billion-row MySQL table with zero downtime. Compare trigger-based, binlog-based and native approaches, and describe how the change is gated and reverted.
3 min answer -
advanced
Notion sharded its Postgres data into 480 logical shards across 32 physical databases in 2021 and then in 2023 spread the same 480 logical shards across 96 databases, with no change to the routing logic. What did the 2021 decision buy, what did the 2023 move still cost, and where would copying the number be a mistake?
3 min answer -
advanced
Walk through migrating a live database to a different engine with no downtime. Where does reversibility end?
2 min answer
3 terms in this topic
Database Migration
Moving data from one store to another while the system keeps running — where verification and reversibility matter more than the copy itself.
practiceDatabase Migration Strategy
The approach for moving data to a new store, which is usually the longest pole and the highest risk in any modernisation.
practiceOwnership-First Decomposition
Assigning each table a single owning team before splitting any code or data, because the ownership step costs nothing, removes the worst of the coupl…
Neighbouring topics
Legacy Modernization
General material on modernising existing systems.
Legacy Assessment
Understanding what a system does before deciding what to do with it.
The Six Rs
Rehost, replatform, refactor, repurchase, retire, retain — per application.
Rehosting
Lift and shift: fastest, cheapest, and capturing none of the benefits.
Replatforming
Targeted changes that capture operational wins without a rewrite.
Refactoring & Re-architecting
Changing structure incrementally while the system keeps running.
Rebuild vs Re-architect
Why greenfield replacement fails, and the narrow cases where it does not.
Strangler Fig
Routing capabilities to new implementations behind a facade, one at a time.
Application Decomposition
Finding seams in a monolith, starting from the data.
Data Migration Strategies
Backfill, dual-write, reconciliation and verification.
Zero-Downtime Migration
Expand, migrate, contract — and the contract phase that never happens.
Parallel Run
Shadowing the old system to discover the rules nobody documented.
Cutover Planning
Rehearsals, go/no-go criteria and a rollback that has been executed.
Legacy Integration Patterns
Anti-corruption layers, adapters and CDC against systems that cannot change.
Mainframe Modernization
Batch windows, COBOL, and the risk profile of core banking systems.
Migration Risk
Bounding blast radius, staging by cohort, and honest readiness reporting.
Modernisation Business Case
Pricing tail risk so deferred maintenance becomes fundable.
Coexistence Patterns
Running old and new together for years without corrupting either.
Decommissioning
Actually switching the old system off, and proving nothing depended on it.