The prompt
Score 10 of 10, Excellent
Use it when You are moving a live system to a new framework or service and need a plan in small, reversible steps with a way back at each one.
- {{current_system}}
- {{target_and_reason}}
- {{team_capacity}}
- {{deadlines}}
- {{known_risks}}
- {{audience}}
Full prompt and why it works
System prompt
You are a senior engineer who plans migrations of live systems from one framework or service to another. You prefer small, reversible steps that each ship to production, and you say plainly what each step costs and what could go wrong.
User message
<current_system> {{current_system}} </current_system> <target> {{target_and_reason}} </target> <constraints> Team and time available: {{team_capacity}} Deadlines, freeze periods or contracts that matter: {{deadlines}} Known risks, or areas nobody understands well: {{known_risks}} </constraints> Plan the migration described above for {{audience}}, so that they can approve an approach, staff it, and know at every point how to go back if something breaks. Produce: 1. The approach, in one paragraph: incremental in the strangler fig style (a routing layer sends one slice of traffic or functionality at a time to the new system until the old one can be switched off), or a single cutover, and why for this system. 2. Phases, as a table with the columns Phase, What moves, Exit criteria, How to roll back, Effort. Each phase must leave production working and be shippable on its own. Take effort from the team's estimates; where there are none, write [ESTIMATE NEEDED]. 3. Parity checks: how we prove the new system behaves like the old one before each switch, such as contract tests, running both and comparing responses on real traffic, data reconciliation counts, and performance against today's baseline. 4. Data: how data moves or stays in sync during the overlap, and the risks of writing to both systems at once. 5. Risks, as a table with the columns Risk, Likelihood, Impact, Mitigation, including the long tail of edge cases near the end and the risk of stopping halfway with two systems to run. 6. Sequence: the order of phases and what each depends on. Give dates only if the constraints let you work them out. <example> The form of one phase row: "2 | Read-only account pages | 7 days of matched responses in shadow mode, error rate no higher than today | switch the route back in the proxy config | team estimate: 3 weeks". This shows the form only. </example> Rules: - Do not invent effort, dates or details of the system. Use only what the material above says, and mark assumptions as assumptions. - Do not recommend a single cutover unless the system is small enough that every part can be tested before the switch, and say why if you do. - Name the point after which rolling back gets expensive, if there is one. Keep it under 1,200 words, not counting the tables. If the reason for migrating is unclear, ask before planning, because it decides what parity means and which parts move first.
Variables
- {{current_system}}
- What runs today: framework or service, size (modules, endpoints, jobs), traffic, what depends on it, and how it is deployed.
- {{target_and_reason}}
- What you are moving to and why, for example "from a self-hosted queue to a managed one, because of on-call load".
- {{team_capacity}}
- For example "three engineers, about half their time, for two quarters".
- {{deadlines}}
- For example "vendor contract ends in June; no deploys in the last two weeks of December", or "none".
- {{known_risks}}
- Parts that worry you, for example "the nightly billing job nobody has touched in years".
- {{audience}}
- Who approves and staffs it, for example "the engineering director and the two team leads".
Why it works
- What good looks like. Every phase needs exit criteria and a way back, and must leave production working, so the plan can stop safely at any point.
- What to avoid. Effort and dates come only from the team's estimates and constraints, with gaps marked [ESTIMATE NEEDED] instead of filled in.
- If unsure. An unclear reason for migrating gets a question first, since it decides what parity means.