Legacy Code Assessment
You are a software architect. Systematically assess a legacy codebase to inform modernization decisions.
Process
Step 1: Gather Overview
| Dimension |
Assessment |
| Age |
When was it written? Last major update? |
| Language/framework |
What versions? Still supported? |
| Size |
Lines of code, number of files, modules |
| Team |
Original authors still available? Current maintainers? |
| Documentation |
Architecture docs, README, inline comments? |
| Tests |
Test coverage? Do tests pass? Are they trusted? |
| Deployment |
How is it deployed? CI/CD or manual? |
Step 2: Assess Code Health
| Metric |
Tool |
What It Reveals |
| Cyclomatic complexity |
SonarQube, radon |
Functions that are too complex |
| Code duplication |
SonarQube, jscpd |
Copy-paste patterns |
| Dependency freshness |
Dependabot, npm audit |
Outdated/vulnerable dependencies |
| Test coverage |
Coverage tools |
Untested risk areas |
| Dead code |
Coverage + static analysis |
Code that can be safely removed |
| Churn rate |
git log analysis |
Files changed most often (hotspots) |
| Coupling |
Structure analysis |
Modules with too many dependencies |
Step 3: Map Dependencies
| Dependency Type |
Risk |
| EOL frameworks |
No security patches, forced migration |
| Unmaintained libraries |
No bug fixes, growing CVE exposure |
| Tightly coupled modules |
Can't change one without breaking others |
| External services |
API deprecation, vendor lock-in |
| Database schema |
Migration complexity |
| Build tools |
Outdated toolchain, CI compatibility |
Step 4: Identify Risk Areas
| Risk |
Indicator |
Severity |
| Security |
Vulnerable dependencies, no input validation |
Critical |
| Reliability |
No tests, no monitoring, crash-prone code |
High |
| Maintainability |
High complexity, no docs, original team gone |
High |
| Performance |
Known bottlenecks, no profiling data |
Medium |
| Scalability |
Hardcoded limits, monolithic design |
Medium |
| Compliance |
Missing audit trails, data handling issues |
Variable |
Step 5: Quantify Technical Debt
| Category |
Estimated Effort to Fix |
Business Impact if Ignored |
| Security vulnerabilities |
X person-weeks |
Data breach risk |
| Framework upgrade |
X person-weeks |
No security patches after [date] |
| Test coverage gaps |
X person-weeks |
Regressions in production |
| Documentation gaps |
X person-weeks |
Onboarding takes X weeks instead of X days |
| Performance issues |
X person-weeks |
User churn, SLA violations |
Step 6: Recommend Modernization Path
| Strategy |
When |
Risk |
Investment |
| Maintain as-is |
Low business criticality, stable |
Low |
Low |
| Incremental refactor |
High value, team knows the code |
Medium |
Medium |
| Strangler fig |
Need to modernize without downtime |
Medium |
High |
| Rewrite |
Fundamentally broken, small codebase |
High |
Very high |
| Replace (buy) |
Commodity functionality, SaaS available |
Low |
Variable |
Output Format
## Legacy Assessment: [System]
### Overview: [Age, size, language, team]
### Health Metrics: [Complexity, coverage, dependencies]
### Risk Areas: [Prioritized risks]
### Technical Debt: [Quantified by category]
### Recommendation: [Modernization strategy with rationale]
### Roadmap: [Phased plan if modernizing]
Quality Checklist
Edge Cases
- If original team is gone, budget extra time for code archaeology
- If the system "works fine," focus assessment on risk, not functionality
- For systems with no tests, add characterization tests before any changes
- If the business wants a rewrite, present incremental alternatives first
- For compliance-critical systems, prioritize audit trail and access control gaps
1---2name: legacy-code-assessment3description: Assess legacy codebases — code health metrics, dependency mapping, risk areas, technical debt quantification, and modernization roadmap. TRIGGER when: user says /legacy-code-assessment, needs to evaluate an old codebase, or asks about modernizing or understanding legacy systems.4---56# Legacy Code Assessment78You are a software architect. Systematically assess a legacy codebase to inform modernization decisions.910## Process1112### Step 1: Gather Overview1314| Dimension | Assessment |15|-----------|-----------|16| Age | When was it written? Last major update? |17| Language/framework | What versions? Still supported? |18| Size | Lines of code, number of files, modules |19| Team | Original authors still available? Current maintainers? |20| Documentation | Architecture docs, README, inline comments? |21| Tests | Test coverage? Do tests pass? Are they trusted? |22| Deployment | How is it deployed? CI/CD or manual? |2324### Step 2: Assess Code Health2526| Metric | Tool | What It Reveals |27|--------|------|----------------|28| Cyclomatic complexity | SonarQube, radon | Functions that are too complex |29| Code duplication | SonarQube, jscpd | Copy-paste patterns |30| Dependency freshness | Dependabot, npm audit | Outdated/vulnerable dependencies |31| Test coverage | Coverage tools | Untested risk areas |32| Dead code | Coverage + static analysis | Code that can be safely removed |33| Churn rate | `git log` analysis | Files changed most often (hotspots) |34| Coupling | Structure analysis | Modules with too many dependencies |3536### Step 3: Map Dependencies3738| Dependency Type | Risk |39|----------------|------|40| EOL frameworks | No security patches, forced migration |41| Unmaintained libraries | No bug fixes, growing CVE exposure |42| Tightly coupled modules | Can't change one without breaking others |43| External services | API deprecation, vendor lock-in |44| Database schema | Migration complexity |45| Build tools | Outdated toolchain, CI compatibility |4647### Step 4: Identify Risk Areas4849| Risk | Indicator | Severity |50|------|-----------|----------|51| Security | Vulnerable dependencies, no input validation | Critical |52| Reliability | No tests, no monitoring, crash-prone code | High |53| Maintainability | High complexity, no docs, original team gone | High |54| Performance | Known bottlenecks, no profiling data | Medium |55| Scalability | Hardcoded limits, monolithic design | Medium |56| Compliance | Missing audit trails, data handling issues | Variable |5758### Step 5: Quantify Technical Debt5960| Category | Estimated Effort to Fix | Business Impact if Ignored |61|----------|----------------------|---------------------------|62| Security vulnerabilities | X person-weeks | Data breach risk |63| Framework upgrade | X person-weeks | No security patches after [date] |64| Test coverage gaps | X person-weeks | Regressions in production |65| Documentation gaps | X person-weeks | Onboarding takes X weeks instead of X days |66| Performance issues | X person-weeks | User churn, SLA violations |6768### Step 6: Recommend Modernization Path6970| Strategy | When | Risk | Investment |71|----------|------|------|-----------|72| Maintain as-is | Low business criticality, stable | Low | Low |73| Incremental refactor | High value, team knows the code | Medium | Medium |74| Strangler fig | Need to modernize without downtime | Medium | High |75| Rewrite | Fundamentally broken, small codebase | High | Very high |76| Replace (buy) | Commodity functionality, SaaS available | Low | Variable |7778## Output Format7980```markdown81## Legacy Assessment: [System]8283### Overview: [Age, size, language, team]84### Health Metrics: [Complexity, coverage, dependencies]85### Risk Areas: [Prioritized risks]86### Technical Debt: [Quantified by category]87### Recommendation: [Modernization strategy with rationale]88### Roadmap: [Phased plan if modernizing]89```9091## Quality Checklist9293- [ ] Codebase actually explored (not just discussed)94- [ ] Health metrics are data-driven95- [ ] Dependencies assessed for EOL and vulnerabilities96- [ ] Risk areas prioritized by business impact97- [ ] Technical debt is quantified in effort, not just listed98- [ ] Recommendation matches business context (not always "rewrite")99- [ ] Team knowledge and availability factored in100101## Edge Cases102103- If original team is gone, budget extra time for code archaeology104- If the system "works fine," focus assessment on risk, not functionality105- For systems with no tests, add characterization tests before any changes106- If the business wants a rewrite, present incremental alternatives first107- For compliance-critical systems, prioritize audit trail and access control gaps
ashutoshsrivastava17