Modernize Legacy Code with Strangler Fig Pattern

A 5-phase orchestration skill implementing the strangler fig pattern to modernize legacy systems gradually while keeping both systems running during transition. Phase 1 (Assessment and Risk Analysis) calls a legacy-modernizer agent to inventory technical debt and score component complexity 1-10, an architect-review agent to map dependencies and integration points needing facade or adapter layers, and a business-analyst to weight-score components by business value, technical risk, and quick-win potential and define rollback strategies. Phase 2 (Test Coverage Establishment) calls a test-automator to generate characterization tests for components under 40% coverage and implement consumer-driven contract tests with performance baselines, plus a data-engineer to build a test-data pipeline with masking and consistency monitoring between legacy and modernized components. Phase 3 (Incremental Migration) calls a backend-architect to set up strangler fig infrastructure - an API gateway for traffic routing, feature flags, circuit breakers, and dual-system observability - a language-specific developer (python-pro or golang-pro) to modernize first-wave quick-win components using dependency injection and adapter patterns while keeping data consistent via event sourcing or dual writes, and a security-auditor to harden the new components against the OWASP Top 10 (OAuth2/JWT, RBAC, input validation, secrets management). Phase 4 (Performance Validation) calls a performance-engineer to load-test legacy versus modernized components and optimize queries, caching, and pooling, then a deployment-engineer to progressively roll out traffic (5% to 25% to 50% to 100% with 24-hour observation windows) with automatic rollback triggers on error rate above 1% or latency above 2x baseline. Phase 5 (Completion) calls the legacy-modernizer again to decommission replaced components only after 30 days at 0% traffic, and a docs-architect to produce before/after architecture diagrams, migration guides, runbooks, and a lessons-learned report.

Use for a comprehensive, risk-managed legacy system modernization where both old and new components must coexist during a gradual cutover, not a rewrite-and-swap. Choose from five configurable strategies: --parallel-systems (indefinite coexistence), --big-bang (full cutover after validation, higher risk), --by-feature, --database-first, or --api-first. Not for a small, isolated refactor or a greenfield project - the strangler fig machinery (proxy routing, feature flags, dual-write consistency, phased rollback triggers) is overhead unless there's a live legacy system that can't tolerate downtime.

Input is the target legacy codebase plus a chosen migration configuration. Output across the five phases is a modernization readiness report with a risk matrix, a dependency map and integration catalog, a prioritized migration roadmap, a characterization and contract test suite, strangler fig infrastructure (gateway, feature flags, monitoring), modernized and security-hardened components, performance test results, a progressive rollout plan with automated rollback triggers, and complete migration documentation. Success criteria include over 80% test coverage on high-priority components, zero unplanned downtime, P95 latency within 110% of baseline, a greater than 90% security vulnerability reduction, and 30 days of stable post-migration operation.

Delegates to named sub-agents via the Task tool: legacy-modernizer, architect-review, business-analyst, test-automator, data-engineer, backend-architect, python-pro or golang-pro, security-auditor, performance-engineer, deployment-engineer, and docs-architect.

Engineering teams modernizing a live legacy system under real business-continuity constraints who need a phased, agent-coordinated plan with explicit rollback and observability, rather than an ad-hoc big-bang rewrite.