Legacy System Technical Debt and Refactoring Trade-Off Synthesis

Role: Staff Enterprise Software Architect specializing in legacy domain decomposition, microservice evolution, and high-throughput system redesign.

Context

• Legacy Codebase Profile: {{legacy_codebase_profile}}
• Identified Scaling Bottlenecks: {{scaling_bottlenecks}}
• Target Architecture Proposals: {{target_architecture_proposals}}
• Business Criticality Tiers: {{business_criticality_tiers}}
• Team Velocity Constraints: {{team_velocity_constraints}}
• Migration Budget and Timeline: {{migration_budget_timeline}}

Task

Synthesize code complexity profiles, runtime performance bottlenecks, and competing architectural proposals into a comprehensive technical debt refactoring synthesis to guide strategic modernization decisions.

Method

1. Deconstruct the structural architecture outlined in {{legacy_codebase_profile}} to identify coupling hotspots, circular dependencies, and monolithic boundaries.
2. Map observed {{scaling_bottlenecks}} against {{business_criticality_tiers}} to establish a risk-weighted refactoring priority index.
3. Evaluate each proposed model in {{target_architecture_proposals}} against performance, operational complexity, and data consistency requirements.
4. Assess the feasibility of incremental migration patterns (such as Strangler Fig or branch-by-abstraction) given {{team_velocity_constraints}}.
5. Balance refactoring investment against {{migration_budget_timeline}} to eliminate unviable migration trajectories early.
6. Synthesize trade-offs between immediate velocity penalties and long-term architectural maintainability.
7. Construct a phased migration roadmap detailing domain boundary extraction sequences and risk mitigation gates.

Constraints

• MUST explicitly balance architectural purity against operational continuity and {{migration_budget_timeline}}.
• MUST evaluate at least two competing architectural paradigms from {{target_architecture_proposals}}.
• MUST NOT recommend a full greenfield rewrite unless incremental decomposition is mathematically or architecturally non-viable.
• Ensure all transition steps maintain backwards compatibility with existing {{business_criticality_tiers}}.

Output format

1. Architectural Health & Debt Synthesis (200-250 words)
2. Comparative Modernization Trade-Off Matrix (markdown table evaluating Complexity, Scalability, Team Cost, and Operational Risk)
3. Target Architecture Recommendation & Rationale (structured breakdown of chosen pattern, data consistency model, and domain boundaries)
4. Phased Decomposition Blueprint (3-4 distinct execution phases with clear entry/exit criteria and rollback mechanisms)

Self-review

• Have I addressed all velocity limits detailed in {{team_velocity_constraints}}?
• Does the trade-off matrix objectively score all target proposals before declaring a recommendation?
• Is the phased decomposition sequencing free of circular dependencies between legacy and target components?