What this prompt does
This prompt frames the model as a senior engineer who has migrated production systems without an outage, producing a pragmatic phased plan from your [current_stack] to your [target_stack]. You provide both stacks plus [team_size] and [timeline], and it returns a strangler-fig versus big-bang recommendation, a phased rollout with measurable exit criteria, a data strategy, an observability and rollback plan, ranked risks, and a week-by-week schedule.
The structure works because it refuses generic advice and ties everything to your specifics. The [team_size] and [timeline] variables shape the recommendation — a small team on a tight timeline gets different guidance than a large one with runway — and the data section forces a real answer on dual-writes, backfill, and cutover rather than hand-waving. Crucially, it demands a rollback story for every phase, since cutover and rollback, not new code, are where migrations fail.
The strangler-fig bias runs through the whole plan: shipping in slices keeps the business running while you move, instead of betting everything on a single switch. Each phase carries measurable exit criteria so progress is verifiable rather than vibes-based, and the data section is forced to commit to dual-writes, backfill, and cutover specifics where most plans wave their hands. The request for organizational blockers alongside technical risks reflects a real pattern, that approvals and team capacity stall migrations as often as code does.
When to use it
- You are moving off a legacy
[current_stack]and want a low-risk path. - You need a phased plan with concrete exit criteria, not best-practice platitudes.
- The data migration is non-trivial and needs a dual-write and backfill strategy.
- You want a rollback plan defined before each phase, not improvised mid-cutover.
- You need to weigh strangler-fig against big-bang for a
[team_size]team. - You want a week-by-week schedule mapped to a real
[timeline].
Example output
Expect a labelled document: a strangler-fig vs big-bang tradeoff with a recommendation for your [team_size] and [timeline], a phased rollout where each phase has measurable exit criteria, a data-migration section covering dual-writes, backfill, and cutover, an observability and rollback plan per phase, a ranked risk list with mitigations including organizational blockers, and a week-by-week schedule rendered as a table tied to the phases.
Pro tips
- Describe
[current_stack]and[target_stack]precisely; the plan is only as specific as the stacks you name. - Set
[team_size]and[timeline]honestly, since they drive the strangler-fig vs big-bang call and the schedule's feasibility. - Define the rollback for each phase before starting it; a phase you cannot reverse is one you should not ship.
- Push the model on the data section if it hand-waves dual-writes or backfill, since that is where outages originate.
- Ask it to surface organizational blockers, not just technical ones; those stall migrations as often as code does.
- Use the week-by-week table as a living plan and revise exit criteria as phases complete.
