0
Plan a legacy framework migration with a reversible, staged rollout
I need to migrate codebase_description from old_framework to new_framework. Produce a migration plan, not code, structured as:
1. Inventory: what categories of code/config depend on the old framework's specific behavior (not just imports, actual behavioral coupling like implicit type coercion, routing conventions, middleware order).
2. Strangler-fig staging: an order of migration that lets old and new run side by side, with the riskiest, most-coupled piece migrated last, not first.
3. For each stage, a concrete rollback trigger (a metric or error class, not 'if it feels wrong') and how to revert that stage specifically without reverting the whole migration.
4. Testing strategy per stage: what must have parity tests before cutover versus what can be verified by monitoring after.
5. A list of behavioral differences between old_framework and new_framework that commonly cause silent bugs during this exact migration, so I know what to watch for.
Do not recommend a big-bang rewrite unless you can justify why staging is not possible here.