What this prompt does
This prompt plans a framework or version migration that you cannot afford to break. You set the [source_stack], [target_stack], [component_count], and [file_count], and the AI builds a priority matrix ordering files by dependency and risk, before-and-after templates for each of your [file_types], a list of breaking changes split into automated find-and-replace versus manual intervention, a compatibility shim for migrating incrementally, a tracked markdown checklist linked to specific files, a validation script for [critical_paths], and an effort estimate with a timeline for a [team_size]-person team.
The structure works because big-bang migrations are how live products go offline. The incremental, adapter-first approach lets the running application keep working while you migrate one piece at a time, in dependency order. The compatibility shim bridges [source_stack] and [target_stack] so both can coexist mid-migration rather than forcing a single cutover. Splitting breaking changes into mechanical versus judgment-required work prevents the subtle regressions that come from automating a change that actually needed a human decision. And the validation script comparing old and new behavior on [critical_paths] is the safeguard that confirms functional equivalence before you delete any old code — it is the part you never skip, because it catches behavior drift the diffs alone would hide.
When to use it
- You are migrating between framework versions and the product must stay live throughout the change
- The migration spans many files and components and needs deliberate dependency-ordered sequencing
- You want an adapter layer so the old and new code can coexist during the migration
- Some breaking changes are mechanical and some require judgment, and you need them clearly sorted
- You must prove functional equivalence on
[critical_paths]before deleting any old code - You need a realistic effort estimate and timeline for a
[team_size]-person team to plan around
Example output
You get a migration plan: a priority matrix ranking files by dependency and risk, before-and-after transformation templates for each of your [file_types], a breaking-changes list separated into find-and-replace versus manual work, a compatibility shim design, a trackable markdown checklist linked to specific files, a validation script for [critical_paths], and a per-file-type effort estimate with an overall timeline.
Pro tips
- Give honest
[component_count]and[file_count]numbers; the timeline and batch sizing depend directly on them - Lean on the compatibility shim so you never have the app fully broken between batches
- Treat the validation script for
[critical_paths]as non-optional; it is what proves equivalence before any cleanup - Migrate strictly in the priority matrix's dependency order to avoid cascading breakage across components
- Sort breaking changes carefully — automating a change that needed judgment is a common source of subtle regressions
- Keep the checklist linked to specific files so progress is visible and nothing gets silently skipped
