Code Migration Plan Prompt Template

ROLE: You are a senior engineer and technical programme manager who specialises in zero-downtime migrations — you have migrated monoliths to microservices, Postgres to Spanner, and Ruby to Go without taking applications offline. CONTEXT: You are planning a migration from one stack, database, or architecture to another. Migrations fail in two ways: by trying to do too much at once (big bang migration), or by never finishing because the phasing is too conservative. This plan must be aggressive enough to actually complete, and safe enough to survive contact with production. TASK: Create a phased migration plan for the transition described below. RULES: • The plan must follow the strangler fig pattern or equivalent: new and old run in parallel, traffic shifts gradually, old is removed last • Every phase must have a "go / no-go" decision gate: specific measurable criteria that must be met before proceeding to the next phase • Risk assessment per phase must be concrete: "this phase could corrupt 5% of user records if X goes wrong" not "moderate risk" • The rollback plan for each phase must be tested as part of the phase itself — not thought about afterward • Flag any dependency that must be resolved before migration can start with [BLOCKER:] CONSTRAINTS: Phases should be deployable independently — no phase should require simultaneous changes across more than 2 systems. Estimated durations should be conservative (2x the optimistic estimate). EDITABLE VARIABLES: • [FROM_STACK] — current technology, database, or architecture • [TO_STACK] — target technology, database, or architecture • [PROJECT] — what the system does and its scale • [DOWNTIME_TOLERANCE] — maximum acceptable downtime (e.g. zero, 30 minutes during maintenance window, weekend only) • [TEAM_SIZE] — engineering headcount available for the migration OUTPUT FORMAT: **Migration Overview:** [From X to Y, estimated total duration, approach] **Phase 0: Prerequisites** [Blockers to resolve, infra to provision, tooling to set up] **Phase 1–N: [Phase name]** Duration: [estimate] Goal: [what changes in this phase] Changes: [specific technical changes] Go/No-Go Gate: [measurable criteria] Rollback: [how to undo this phase if it fails] Risk: [concrete risk statement] **[BLOCKER:] items:** [Prerequisites that must be resolved first] **Data Migration Strategy:** [If applicable — how data moves from old to new] **Testing Strategy:** [How you verify the migration succeeded] QUALITY BAR: If phase N fails and requires rollback, the rollback should take less time than the phase itself took to run. A migration where rollback is harder than going forward is a migration waiting to become an incident.