Plan a safe migration or upgrade

Plan a database, framework or infrastructure migration with phases, rollback points and verification at each step.

LLazyPrompt(@lazyprompt)CodingPlanWorks with any model
No ratings yetSign in to rate
Save 0 Fork Report
Prompt template
Plan a migration for me.

From: {{from}}
To: {{to}}
Size and complexity: {{scale}}
Hard constraints (downtime allowed, deadlines, team size, compliance): {{constraints}}
Anything fragile or poorly understood: {{risks}}

Create a plan that includes:
1. Strategy choice: compare the realistic approaches (for example big bang, phased, strangler, dual-write, parallel run) in a short table and recommend one with reasons that tie to my constraints.
2. Preparation: inventory of what has to move or change, compatibility problems to expect, and the checks to run before starting.
3. Phased steps: for each phase give the actions, the exit criteria that prove it worked, and how long it should roughly take for my scale.
4. Rollback: the point of no return, what rollback looks like in each phase, and what data could be lost or diverge.
5. Verification: how to confirm correctness (row counts, checksums, shadow traffic, canary metrics), and what to monitor.
6. Cutover runbook: an ordered checklist for the day, with owners as roles.
7. Top risks with mitigation, and the questions you need answered before committing to this plan.

Be specific to the technologies named. Flag any step where you are unsure and I should consult the official migration guide.
Example output
**Recommendation:** phased migration with continuous replication, then a short write freeze for cutover. | Approach | Downtime | Risk | Fit | |---|---|---|---| | Dump and restore | Hours | Low | Fails the 10-minute limit | | Replication then cutover | Minutes | Medium | Fits | | Dual-write in the app | None | High | Too much code for 2 engineers | **Phases** 1. Prep (week 1-2): inventory types and procedures; port the 14 stored procedures; run a schema conversion tool. Exit: the schema loads in a staging Postgres. 2. Replicate (week 3-4): set up change data capture into the target. Exit: lag under 5 s for a week. 3. Verify (week 5-6): row counts and checksums per table; run the reporting job against the replica. Exit: zero diffs. 4. Rehearse (week 7): full cutover on staging, timed. 5. Cutover: freeze writes, wait for zero lag, verify, flip connection strings. **Rollback:** until step 5 the old database is authoritative. After cutover, keep reverse replication for 7 days. **Questions:** are there MySQL-specific behaviors, such as zero dates, case-insensitive collations, that code relies on?

Why it works

Choosing the strategy against your stated constraints, and defining a rollback for every phase, avoids the usual one-way-door plans. Answer its closing questions and rerun for a tighter plan.

Licensed CC0 (public domain) Version 1 · history