# Assess Command

**Description**: Orchestrate a team of specialist agents to assess a project for modernization readiness and viability, evaluating technical debt, risks, and ROI to determine if modernization is recommended

---

# Project Modernization Assessment Protocol

**Version**: 1.0
**Purpose**: Systematically assess whether a project is a good candidate for modernization
**Output**: `ASSESSMENT.md` with comprehensive analysis and recommendation
**Duration**: 2-4 hours

**Note**: Time estimates are based on typical human execution times and may vary significantly based on project complexity, team experience, and AI assistance capabilities.

---

## Overview

This protocol evaluates a software project across **8 critical dimensions** to determine:
- ✅ Is modernization **technically feasible**?
- ✅ Is modernization **financially worthwhile**?
- ✅ What are the **major risks and blockers**?
- ✅ What is the **recommended approach**?
- ✅ Should we proceed, defer, or abandon the modernization?

**Core Principle**: **Assess before you commit - not all projects should be modernized.**

---

## Assessment Dimensions

### 1. Technical Viability (0-100 score)
### 2. Business Value (0-100 score)
### 3. Risk Profile (LOW/MEDIUM/HIGH/CRITICAL)
### 4. Resource Requirements (estimated effort)
### 5. Dependencies & Ecosystem Health
### 6. Code Quality & Architecture
### 7. Test Coverage & Stability
### 8. Security Posture

---

## Assessment Process

### Step 1: Project Discovery (30 minutes)

**Gather Basic Information**:
- [ ] Project name, version, and purpose
- [ ] Primary programming language(s) and framework(s)
- [ ] Current framework versions
- [ ] Target framework versions (if known)
- [ ] Age of project (initial commit date)
- [ ] Last significant update
- [ ] Active development status
- [ ] Number of contributors
- [ ] Lines of code
- [ ] Number of dependencies

**Commands**:
```bash
# Project stats
find . -name "*.cs" -o -name "*.js" -o -name "*.py" -o -name "*.java" | xargs wc -l
git log --reverse --format="%ai" | head -1  # First commit
git log --format="%ai" | head -1            # Last commit
git shortlog -sn                            # Contributors

# Dependency analysis
# .NET: dotnet list package --outdated
# Node: npm outdated
# Python: pip list --outdated
```

---

### Step 2: Technical Viability Assessment (45 minutes)

#### 2.1 Framework Analysis

**Current Framework Status**:
- [ ] Is current framework still supported?
- [ ] End-of-life date for current version
- [ ] Security patches still available?
- [ ] Community support level (active/declining/dead)

**Target Framework Status**:
- [ ] Latest stable version available?
- [ ] Migration path documented?
- [ ] Breaking changes documented?
- [ ] Tool support available?

**Scoring Criteria**:
- **80-100**: Clear migration path, well-documented, active community
- **60-79**: Migration path exists, some documentation gaps
- **40-59**: Difficult migration, limited documentation
- **0-39**: No clear path, framework deprecated, or major architectural change required

#### 2.2 Dependency Health

**Analyze All Dependencies**:
```bash
# Count total dependencies
# Check for:
- Deprecated packages (score -= 10 per deprecated)
- Unmaintained packages (no updates >2 years, score -= 5)
- Packages with security vulnerabilities (score -= 20 per CRITICAL)
- Compatible versions available (score += 10 if yes)
```

**Red Flags** (automatic FAIL):
- ❌ Critical dependency with no maintained alternative
- ❌ 50%+ of dependencies unmaintained
- ❌ Core framework dependency incompatible with target

**Scoring**:
- **80-100**: All dependencies maintained, clear upgrade path
- **60-79**: Most dependencies healthy, few alternatives needed
- **40-59**: Many dependencies need replacement
- **0-39**: Dependency hell, extensive rewrites required

#### 2.3 Code Compatibility

**Breaking Changes Analysis**:
- [ ] Enumerate breaking changes between current → target
- [ ] Estimate affected code percentage
- [ ] Identify obsolete APIs in use
- [ ] Check for deprecated patterns

**Complexity Factors**:
- Using reflection heavily (+complexity)
- Platform-specific code (+complexity)
- Custom serialization (+complexity)
- Heavy use of deprecated APIs (+complexity)

**Scoring**:
- **80-100**: <10% code affected, automated migration possible
- **60-79**: 10-30% affected, mostly straightforward changes
- **40-59**: 30-60% affected, significant manual work
- **0-39**: >60% affected, near-rewrite required

---

### Step 3: Business Value Assessment (30 minutes)

#### 3.1 Strategic Alignment

**Questions**:
- [ ] Is this project critical to business operations?
- [ ] Is this project actively developed/maintained?
- [ ] Are there plans for new features?
- [ ] Does current tech stack limit business capabilities?
- [ ] Is recruiting difficult for current tech stack?

**Scoring**:
- **80-100**: Critical system, active development, strategic importance
- **60-79**: Important system, moderate development
- **40-59**: Peripheral system, maintenance mode
- **0-39**: Legacy system, sunset planned

#### 3.2 Effort-Benefit Analysis

**Modernization Effort** (estimated timeline):
- Assessment & Planning: X days
- Security Remediation: Y days
- Framework Migration: Z days
- Testing & Validation: W days
- Documentation: V days
- **Total Effort**: XX days

**Benefits** (expected improvements):
- Security: Reduced vulnerability risk, compliance improvements
- Performance: Improved response times, reduced resource usage
- Developer productivity: Faster feature development, better tooling
- Maintenance: Reduced legacy issues, better long-term support
- Recruitment: Easier hiring with modern technology stack

**Value Assessment**:
- High value if effort investment provides substantial long-term benefits
- Consider strategic alignment and business criticality
- Factor in risk of continuing with outdated technology

**Scoring**:
- **80-100**: Significant benefits, manageable effort, clear value
- **60-79**: Good benefits justify moderate effort investment
- **40-59**: Limited benefits relative to effort required
- **0-39**: Benefits don't justify the effort investment

---

### Step 4: Risk Assessment (30 minutes)

#### 4.1 Technical Risks

**Identify and Rate Risks**:

| Risk | Likelihood | Impact | Severity | Mitigation |
|------|------------|--------|----------|------------|
| Breaking changes break critical features | High | High | CRITICAL | Comprehensive testing |
| Dependency conflicts unresolvable | Medium | High | HIGH | Dependency analysis upfront |
| Performance regression | Low | Medium | MEDIUM | Baseline + benchmark |
| Team lacks expertise | High | Medium | HIGH | Training + consultants |
| Timeline overruns | Medium | Medium | MEDIUM | Phased approach |

**Risk Levels**:
- **CRITICAL**: >3 CRITICAL risks → **DEFER** modernization
- **HIGH**: >5 HIGH risks → Requires mitigation plan
- **MEDIUM**: Manageable with standard practices
- **LOW**: Minimal risk

#### 4.2 Business Risks

- [ ] Business disruption during migration
- [ ] Data loss or corruption risk
- [ ] Customer impact (downtime, features unavailable)
- [ ] Competitive disadvantage if delayed
- [ ] Opportunity cost (alternatives)

**Overall Risk Profile**:
- **LOW**: <2 HIGH risks, 0 CRITICAL, clear mitigations
- **MEDIUM**: 2-5 HIGH risks, good mitigations
- **HIGH**: >5 HIGH risks or 1-2 CRITICAL risks
- **CRITICAL**: >2 CRITICAL risks → **DO NOT PROCEED**

---

### Step 5: Resource Assessment (20 minutes)

#### 5.1 Team Capacity

**Current Team**:
- Number of developers: X
- Framework expertise level: Beginner/Intermediate/Expert
- Availability: X% (accounting for ongoing work)
- Training needs: X days

**Required Skills**:
- [ ] Target framework expertise
- [ ] Migration tooling knowledge
- [ ] Testing framework familiarity
- [ ] DevOps/deployment skills

**Gap Analysis**:
- Skills we have: [list]
- Skills we need: [list]
- Training required: X days
- Contractor/consultant needs: Y days

#### 5.2 Timeline Estimation

**Conservative Estimate** (based on project size):

| Project Size | Discovery | Security | Framework | API/Code | Testing | Docs | Total |
|--------------|-----------|----------|-----------|----------|---------|------|-------|
| Small (<10k LOC) | 1-2d | 2-5d | 5-10d | 3-7d | 2-4d | 2-3d | 15-31d |
| Medium (10-50k) | 2-3d | 3-7d | 10-20d | 7-14d | 4-8d | 3-5d | 29-57d |
| Large (>50k) | 3-5d | 5-10d | 20-40d | 14-28d | 8-16d | 5-10d | 55-109d |

**Buffer**: Add 30% contingency for unknowns

---

### Step 6: Code Quality Analysis (30 minutes)

#### 6.1 Architecture Assessment

**Evaluate Architecture**:
- [ ] Architecture pattern (monolith, microservices, layered, etc.)
- [ ] Separation of concerns (good/fair/poor)
- [ ] Coupling level (loose/moderate/tight)
- [ ] Design pattern usage (appropriate/mixed/absent)
- [ ] Technical debt level (low/medium/high)

**Modernization Compatibility**:
- ✅ **Good**: Well-architected, loose coupling → Easy migration
- ⚠️ **Fair**: Some technical debt → Moderate difficulty
- ❌ **Poor**: High coupling, poor separation → Difficult migration

**Scoring**:
- **80-100**: Clean architecture, low debt
- **60-79**: Some debt, but manageable
- **40-59**: Significant debt, refactoring needed
- **0-39**: Architecture rewrite recommended

#### 6.2 Code Quality Metrics

**Measure**:
```bash
# Cyclomatic complexity
# Code duplication percentage
# Method/class size averages
# Code coverage percentage
```

**Quality Indicators**:
- [ ] Average cyclomatic complexity: X (target <10)
- [ ] Code duplication: X% (target <5%)
- [ ] Average method lines: X (target <50)
- [ ] Test coverage: X% (target >80%)

**Scoring**:
- **80-100**: High quality, minimal refactoring needed
- **60-79**: Decent quality, some improvements needed
- **40-59**: Poor quality, significant refactoring required
- **0-39**: Very poor quality, rewrite consideration

---

### Step 7: Test Coverage & Stability (20 minutes)

#### 7.1 Existing Test Suite

**Analyze Tests**:
- [ ] Unit test count: X
- [ ] Integration test count: Y
- [ ] E2E test count: Z
- [ ] Test coverage: X%
- [ ] Test pass rate: Y%
- [ ] Test execution time: Z minutes

**Test Quality**:
- [ ] Tests are maintained and passing
- [ ] Tests cover critical paths
- [ ] Tests are not brittle/flaky
- [ ] Test infrastructure is documented

**Scoring**:
- **80-100**: >80% coverage, 100% pass rate, comprehensive suite
- **60-79**: 60-80% coverage, 100% pass rate (but limited coverage)
- **40-59**: 40-60% coverage, 100% pass rate (but limited coverage)
- **0-39**: <40% coverage or <100% pass rate

#### 7.2 Production Stability

**Metrics** (last 6 months):
- [ ] Production incidents: X
- [ ] Critical bugs: Y
- [ ] Uptime percentage: Z%
- [ ] Performance issues: W

**Scoring**:
- **80-100**: Stable system, rare incidents
- **60-79**: Generally stable, occasional issues
- **40-59**: Frequent issues, stability concerns
- **0-39**: Unstable, modernization may be too risky

---

### Step 8: Security Assessment (30 minutes)

#### 8.1 Vulnerability Scan

**Run Security Scan**:
```bash
# .NET: dotnet list package --vulnerable
# Node: npm audit
# Python: pip-audit
# Or use: Snyk, OWASP Dependency Check
```

**Categorize Vulnerabilities**:
- CRITICAL: X vulnerabilities
- HIGH: Y vulnerabilities
- MEDIUM: Z vulnerabilities
- LOW: W vulnerabilities

**Security Score**: (100 - (CRITICAL*20 + HIGH*10 + MEDIUM*5 + LOW*1))

**Scoring**:
- **80-100**: Minimal vulnerabilities, easy fixes
- **60-79**: Some vulnerabilities, manageable
- **40-59**: Many vulnerabilities, significant work
- **0-39**: Critical security issues, URGENT modernization

#### 8.2 Security Posture

**Evaluate**:
- [ ] Authentication/authorization modern?
- [ ] Encryption standards current?
- [ ] Secrets management proper?
- [ ] Security headers implemented?
- [ ] Input validation comprehensive?

---

## Assessment Report Generation

### ASSESSMENT.md Template

```markdown
# Project Modernization Assessment

**Project**: [Name]
**Current Version**: [Version]
**Target Version**: [Version]
**Assessment Date**: [Date]
**Assessor**: [Name/Team]

---

## Executive Summary

**Recommendation**: ✅ PROCEED / ⚠️ PROCEED WITH CAUTION / ❌ DEFER / 🛑 DO NOT PROCEED

**Overall Score**: XX/100 (Excellent/Good/Fair/Poor)

**Key Findings**:
- [Finding 1]
- [Finding 2]
- [Finding 3]

**Estimated Effort**: XX-YY days (ZZ-WW calendar weeks)

---

## 1. Technical Viability: XX/100

### Framework Analysis
- **Current**: [Framework] [Version] (EOL: [Date])
- **Target**: [Framework] [Version]
- **Migration Path**: Clear/Documented/Unclear
- **Breaking Changes**: XX identified
- **Score**: XX/100

**Assessment**: [Detailed explanation]

### Dependency Health
- **Total Dependencies**: XX
- **Deprecated**: X (XX%)
- **Unmaintained**: Y (YY%)
- **Security Issues**: Z (CRITICAL: A, HIGH: B)
- **Score**: XX/100

**Red Flags**:
- [Flag 1 if any]
- [Flag 2 if any]

### Code Compatibility
- **Affected Code**: ~XX% (estimated)
- **Obsolete APIs**: X usages found
- **Platform-Specific Code**: Y instances
- **Score**: XX/100

**Major Challenges**:
1. [Challenge 1]
2. [Challenge 2]

---

## 2. Business Value: XX/100

### Strategic Alignment
- **Business Criticality**: Critical/Important/Peripheral
- **Development Status**: Active/Maintenance/Sunset
- **Strategic Value**: High/Medium/Low
- **Score**: XX/100

### Effort-Benefit Analysis

**Effort Estimate**:
- Assessment & Planning: X days
- Security Remediation: Y days
- Framework Migration: Z days
- Testing & Validation: W days
- Documentation: V days
- Contingency (30%): Z days
- **Total Effort**: **XX days**

**Expected Benefits**:
- Security: Reduced vulnerability risk, improved compliance
- Performance: Better response times, optimized resource usage
- Developer Productivity: Faster feature development, modern tooling
- Maintenance: Reduced legacy issues, improved long-term support
- Recruitment/Retention: Easier hiring with modern stack

**Value Assessment**:
- Significant benefits justify the effort investment
- Strategic importance aligns with business goals
- Long-term value outweighs short-term effort
- **Score**: XX/100

---

## 3. Risk Assessment: LOW/MEDIUM/HIGH/CRITICAL

### Technical Risks

| Risk | Likelihood | Impact | Severity | Mitigation |
|------|------------|--------|----------|------------|
| [Risk 1] | High/Med/Low | High/Med/Low | CRITICAL/HIGH/MEDIUM/LOW | [Strategy] |
| [Risk 2] | ... | ... | ... | [...] |

**Critical Risks** (0):
- [None] OR [List critical risks]

**High Risks** (X):
1. [Risk 1]
2. [Risk 2]

**Risk Mitigation Plan**:
- [Strategy 1]
- [Strategy 2]

### Business Risks
- [Risk 1]: [Assessment and mitigation]
- [Risk 2]: [Assessment and mitigation]

**Overall Risk Profile**: **LOW/MEDIUM/HIGH/CRITICAL**

---

## 4. Resource Requirements

### Team Capacity
- **Current Team Size**: X developers
- **Target Framework Expertise**: Expert/Intermediate/Beginner
- **Availability**: XX% (after ongoing work)
- **Skills Gap**: [List gaps]

### Training Needs
- [Skill 1]: X days
- [Skill 2]: Y days
- **Total Training**: Z days

### External Resources
- **Consultants Needed**: Yes/No
- **Specialized Skills**: [List if any]
- **Additional Effort**: X days (if consultants needed)

### Timeline
**Estimated Duration**: XX-YY weeks (ZZ-WW calendar months)

**Breakdown**:
- Phase 0 (Discovery): X-Y days
- Phase 1 (Security): X-Y days
- Phase 2 (Architecture): X-Y days
- Phase 3 (Framework): X-Y days
- Phase 4 (API Modernization): X-Y days
- Phase 5 (Performance): X-Y days
- Phase 6 (Documentation): X-Y days
- Phase 7 (Validation): X-Y days
- Contingency (30%): X-Y days

---

## 5. Code Quality: XX/100

### Architecture
- **Pattern**: [Monolith/Microservices/Layered/etc.]
- **Separation of Concerns**: Good/Fair/Poor
- **Coupling**: Loose/Moderate/Tight
- **Technical Debt**: Low/Medium/High
- **Score**: XX/100

**Analysis**: [Detailed assessment]

### Code Metrics
- **Cyclomatic Complexity**: X (target <10)
- **Code Duplication**: XX% (target <5%)
- **Average Method Size**: XX lines (target <50)
- **Score**: XX/100

---

## 6. Test Coverage: XX/100

### Test Suite Analysis
- **Unit Tests**: X tests
- **Integration Tests**: Y tests
- **E2E Tests**: Z tests
- **Coverage**: XX%
- **Pass Rate**: YY%
- **Execution Time**: Z minutes

**Assessment**: [Quality evaluation]

### Production Stability
- **Uptime**: XX.X%
- **Incidents (6mo)**: X
- **Critical Bugs**: Y
- **Performance Issues**: Z

**Score**: XX/100

---

## 7. Security Posture: XX/100

### Vulnerability Scan
- **CRITICAL**: X vulnerabilities
- **HIGH**: Y vulnerabilities
- **MEDIUM**: Z vulnerabilities
- **LOW**: W vulnerabilities
- **Security Score**: XX/100

**Critical Issues**:
1. [CVE-XXXX-XXXX]: [Description]
2. [CVE-YYYY-YYYY]: [Description]

### Security Practices
- Authentication: Modern/Dated/Poor
- Encryption: Current/Dated/None
- Secrets Management: Good/Fair/Poor
- Input Validation: Comprehensive/Partial/Minimal

---

## 8. Dependencies & Ecosystem

### Framework Ecosystem
- **Community Health**: Active/Declining/Stagnant
- **LTS Support**: Available/Limited/None
- **Tool Support**: Excellent/Good/Fair/Poor
- **Documentation**: Comprehensive/Good/Limited/Poor

### Dependency Analysis
- **Total**: XX packages
- **Up-to-date**: X (XX%)
- **Outdated**: Y (YY%)
- **Deprecated**: Z (ZZ%)
- **Unmaintained**: W (WW%)

**Major Dependencies**:
| Package | Current | Latest | Status | Migration Path |
|---------|---------|--------|--------|----------------|
| [Name] | vX.X | vY.Y | OK/Deprecated/EOL | Easy/Moderate/Hard |

---

## Overall Assessment

### Scoring Summary

| Dimension | Score | Weight | Weighted |
|-----------|-------|--------|----------|
| Technical Viability | XX/100 | 25% | XX.X |
| Business Value | XX/100 | 20% | XX.X |
| Risk Profile | XX/100 | 15% | XX.X |
| Resources | XX/100 | 10% | XX.X |
| Code Quality | XX/100 | 10% | XX.X |
| Test Coverage | XX/100 | 10% | XX.X |
| Security | XX/100 | 10% | XX.X |
| **TOTAL** | **XX/100** | **100%** | **XX.X** |

### Recommendation Matrix

**Score Interpretation**:
- **80-100**: ✅ **PROCEED** - Strong candidate, low risk
- **60-79**: ⚠️ **PROCEED WITH CAUTION** - Good candidate, manageable risks
- **40-59**: ❌ **DEFER** - Weak candidate, high risk, reconsider after improvements
- **0-39**: 🛑 **DO NOT PROCEED** - Poor candidate, critical risks, not viable

**This Project**: **XX/100** → **[RECOMMENDATION]**

---

## Recommendation

### ✅ PROCEED (if 80-100)

**Rationale**: [Explanation of why this is a good candidate]

**Strengths**:
- [Strength 1]
- [Strength 2]
- [Strength 3]

**Recommended Approach**: [Suggested strategy]

**Next Steps**:
1. Run `/modernize-plan` to create detailed migration plan
2. Secure resource approval (X developers, Y weeks)
3. Allocate team resources and timeline
4. Begin Phase 0 on [Date]

---

### ⚠️ PROCEED WITH CAUTION (if 60-79)

**Rationale**: [Explanation of viable but challenging project]

**Strengths**:
- [Strength 1]
- [Strength 2]

**Concerns**:
- [Concern 1]
- [Concern 2]

**Conditional Approval**: Proceed if:
1. [Condition 1]
2. [Condition 2]
3. [Condition 3]

**Risk Mitigation Required**:
- [Mitigation 1]
- [Mitigation 2]

**Next Steps**:
1. Address critical concerns listed above
2. Develop detailed risk mitigation plan
3. Run `/modernize-plan` with extra contingency
4. Executive sign-off required

---

### ❌ DEFER (if 40-59)

**Rationale**: [Explanation of why deferral is recommended]

**Critical Issues**:
1. [Issue 1]
2. [Issue 2]
3. [Issue 3]

**Recommended Actions Before Reconsidering**:
1. [Action 1]
2. [Action 2]
3. [Action 3]

**Re-Assessment Date**: [X months from now]

**Alternatives to Consider**:
- Maintain current version with security patches only
- Incremental improvements without full modernization
- Gradual replacement with new system
- [Other alternatives]

---

### 🛑 DO NOT PROCEED (if 0-39)

**Rationale**: [Explanation of why modernization is not viable]

**Blocking Issues**:
1. [Critical blocker 1]
2. [Critical blocker 2]
3. [Critical blocker 3]

**Recommended Alternatives**:
- **Rewrite from scratch**: [Justification]
- **Replace with COTS**: [Alternative solutions]
- **Sunset the system**: [Migration plan to replacement]
- **Maintain as-is**: [Minimal maintenance strategy]

**Decision**: Modernization is **NOT RECOMMENDED** for this project.

---

## Appendices

### A. Detailed Dependency List
[Full list of dependencies with versions and status]

### B. Breaking Changes Enumeration
[List of all breaking changes from current → target]

### C. Risk Register
[Complete risk register with all identified risks]

### D. Cost Breakdown
[Detailed cost estimation by phase and resource]

---

**Assessment Completed**: [Date]
**Valid Until**: [Date + 6 months]
**Next Review**: [Date + 3 months]
```

---

## Usage Examples

### Example 1: .NET 6 → .NET 9 Assessment

```
User: /modernize-assess
User: Assess my .NET 6 e-commerce platform for upgrading to .NET 9

Claude: I'll conduct a comprehensive modernization assessment...

[Step 1: Discovery]
- Project: E-Commerce Platform
- Current: .NET 6.0
- Target: .NET 9.0
- LOC: 47,500
- Dependencies: 83 packages
- Age: 4 years
- Active: Yes

[Step 2: Technical Viability]
Framework Analysis:
- .NET 6 EOL: Nov 2024 (6 months!)
- .NET 9 LTS: Current, well-supported
- Breaking changes: 23 identified
- Migration path: Clear ✅
Score: 85/100

Dependency Health:
- 83 packages analyzed
- 5 deprecated (6%)
- 2 unmaintained (2%)
- 3 security issues (1 HIGH)
Score: 78/100

Code Compatibility:
- ~15% code affected
- 12 obsolete API usages
- Mostly straightforward changes
Score: 82/100

**Technical Viability: 82/100** ✅

[Continues through all 8 dimensions...]

[Final Assessment]
**Overall Score: 78/100**
**Recommendation: ⚠️ PROCEED WITH CAUTION**

Writing ASSESSMENT.md...
✅ Assessment complete: ASSESSMENT.md created
```

### Example 2: Node.js 14 → 22 Assessment

```
User: /modernize-assess
User: We have a Node.js 14 API that needs evaluation for upgrading to Node.js 22

Claude: [Full assessment process]

[Final Result]
**Overall Score: 62/100**
**Recommendation: ⚠️ PROCEED WITH CAUTION**

Key Findings:
- Node 14 is EOL (critical security risk)
- 47 npm packages have vulnerabilities
- Test coverage only 34% (major concern)
- BUT: Clean architecture, good ROI

Conditional Approval:
1. Increase test coverage to >60% first
2. Address CRITICAL CVEs immediately
3. Allocate 2 months for migration

✅ ASSESSMENT.md created
```

### Example 3: Legacy System - Not Recommended

```
User: /modernize-assess
User: Evaluate our 15-year-old Java 6 monolith for modernization

Claude: [Assessment process]

[Final Result]
**Overall Score: 34/100**
**Recommendation: 🛑 DO NOT PROCEED**

Critical Blockers:
1. Java 6 → 17/21: Too many breaking changes (>80% code affected)
2. 67% of dependencies unmaintained with no alternatives
3. No test coverage (0%)
4. Tight coupling throughout
5. ROI negative for modernization

Recommended Alternative:
**Strangler Fig Pattern** - Gradually replace with microservices
- Build new features in modern stack
- Migrate high-value modules incrementally
- Retire monolith over 3 years

❌ Modernization not recommended
✅ ASSESSMENT.md created with alternatives
```

---

## Decision Criteria

### Proceed (80-100)
- Strong technical path
- Good ROI
- Low-medium risk
- Team capable
- Business value clear

### Proceed with Caution (60-79)
- Viable technical path
- Acceptable ROI
- Medium risk with mitigations
- Team can learn/adapt
- Business value justified

### Defer (40-59)
- Challenging technical path
- Marginal ROI
- High risk
- Team capacity concerns
- Unclear business value

### Do Not Proceed (0-39)
- No clear technical path
- Negative or very poor ROI
- Critical risks
- Team lacking capabilities
- No business justification

---

## Best Practices

1. **Be Objective** - Don't let sunk costs bias the assessment
2. **Be Conservative** - Underestimate benefits, overestimate costs
3. **Be Thorough** - Don't skip dimensions
4. **Be Honest** - Better to defer now than fail midway
5. **Document Everything** - The ASSESSMENT.md is your evidence

---

## Anti-Patterns

❌ **Rubber-stamp approval** - "We already decided, just assess"
❌ **Ignoring red flags** - "We'll figure it out during migration"
❌ **Skipping ROI** - "We just need to modernize"
❌ **Unrealistic estimates** - "It'll only take 2 weeks"
❌ **Ignoring team capacity** - "We'll find time somehow"

---

**Document Owner**: Migration Coordinator
**Protocol Version**: 1.0
**Last Updated**: 2025-10-25
**Required Before**: Running `/modernize-plan` or `/modernize-project`

**Remember**: **Not all projects should be modernized. Assessment prevents costly mistakes.** ✅