Legacy Codebase Modernization Roadmap
Plan a realistic modernization path for a legacy application without breaking production or stalling feature delivery.
Prompt Template
You are a principal engineer designing a modernization plan for a legacy codebase. Build a phased roadmap that improves maintainability and delivery speed without causing a risky rewrite. **System type:** [monolith / desktop app / SaaS platform / internal tool] **Tech stack:** [languages, frameworks, database, infrastructure] **Age of codebase:** [years] **Current pain points:** [slow releases, flaky tests, outdated dependencies, poor DX, fragile architecture] **Business constraints:** [must keep shipping features, small team, limited budget, uptime requirements] **Known risks:** [tribal knowledge, no tests, unsupported libraries, compliance constraints] Please provide: 1. **Assessment** — top modernization risks and bottlenecks 2. **Modernization strategy** — rewrite vs strangler pattern vs targeted refactors, with reasoning 3. **90-day roadmap** — specific milestones, owners, and deliverables 4. **Dependency upgrade plan** — how to safely handle framework/runtime/library upgrades 5. **Testing strategy** — where to add characterization, integration, and regression tests first 6. **Architecture evolution** — what to modularize or isolate first 7. **Success metrics** — deployment frequency, defect rate, lead time, build times, etc. 8. **Executive summary** — how to explain the plan to non-technical leadership Be pragmatic. Prefer iterative modernization over a big-bang rewrite unless the evidence clearly supports a rewrite.
Example Output
Modernization Recommendation
Assessment
The biggest risks are framework end-of-life, zero automated regression coverage around billing, and a release process that depends on two senior engineers.
Recommended strategy
Use a **strangler-style modernization** rather than a full rewrite. The product is still actively changing, so a rewrite would create long parallel workstreams and high delivery risk.
First 90 Days
- **Weeks 1-2:** Map critical user flows, document deployment steps, identify highest-risk dependencies
- **Weeks 3-6:** Add characterization tests around authentication, checkout, and invoicing
- **Weeks 7-10:** Upgrade runtime and CI pipeline, fix breaking changes in one branch
- **Weeks 11-12:** Extract billing integrations behind a stable service boundary
Success metrics
- Lead time for change: 9 days → 4 days
- Production incidents from deploys: 3/month → <1/month
- Test coverage on critical flows: 8% → 45%
Executive summary
We are not rewriting the product. We are reducing release risk in stages so the team can keep shipping while retiring the most dangerous technical debt first.
Tips for Best Results
- 💡Include both technical pain and business pressure, a good roadmap balances engineering health with delivery reality
- 💡Ask for a 30-60-90 day version if you need something leadership can immediately review
- 💡List the scariest modules by revenue or customer impact so modernization starts where failure is most expensive
- 💡Request a stakeholder communication plan if this work will compete with roadmap features
Related Prompts
Code Review Assistant
Get a thorough, senior-level code review with actionable feedback on quality, security, performance, and best practices.
Debugging Detective
Systematically debug errors and unexpected behavior with root cause analysis and fix suggestions.
Code Refactoring Advisor
Transform messy, complex code into clean, maintainable, well-structured code with clear explanations.