Database Migration Playbook (Cross-Engine)

Tell us what you're building

We use these answers to surface the prompts, skills, and MCP configs that fit your stack — and to substitute stack values like {{database}} into the prompts you copy. Content (PRDs, code, etc.) stays in your repo. Everything you enter here is stored in your browser — nothing is sent to a server.

Steps you'll go through

1. 01

   Schema Audit

   1-2 weeks

   Inventory every object in the source database — tables, procs, functions, triggers, jobs — plus app code that references the schema.

2. 02

   Translate the Schema

   2-3 weeks

   Map every source object to a target equivalent — types, constraints, indexes, identity columns, computed columns.

3. 03

   Migrate Stored Procedures and Functions

   4-8 weeks (depends on volume + complexity)

   Decide what to do with each proc — translate, rewrite in app code, downgrade to a view, or decommission. This is usually the longest phase.

4. 04

   Set Up Dual-Write or CDC

   2-4 weeks

   Keep the target DB in sync with source as the migration progresses. Choose dual-write, CDC (Debezium / DMS), or trickle-batch based on downtime tolerance and tooling.

5. 05

   Backfill Historical Data

   Hours to days (volume-dependent)

   Bulk-copy all historical data into target. The sync from Phase 4 keeps it current after this point.

6. 06

   Validate Parity

   1-2 weeks

   Verify the target has the same data as the source — beyond just counts. Investigate any drift before cutover.

7. 07

   Cutover with Feature Flag

   Maintenance window (minutes to hours)

   Switch apps from source to target. Feature-flag the connection per workload for zero-downtime ramp; or use a brief maintenance window.

8. 08

   Decommission the Source

   30-90 days post-cutover

   After 30+ days of zero source traffic, take the final backup, shut it down, decommission the infrastructure, write the retro.