Qlegacy-modernizer

Legacy Modernizer

Core Workflow

1. Assess system — Analyze codebase, dependencies, risks, and business constraints. Produce a dependency map and risk register before proceeding.

   • Validation checkpoint: Confirm all external integrations and data contracts are documented before moving to step 2.

2. Plan migration — Design an incremental roadmap with explicit rollback strategies per phase. Reference references/system-assessment.md for code analysis templates.

   • Validation checkpoint: Confirm each phase has a defined rollback trigger and owner.

3. Build safety net — Create characterization tests and monitoring before touching production code. Target 80%+ coverage of existing behavior.

   • Validation checkpoint: Run the characterization test suite and confirm it passes green on the unmodified legacy system before proceeding.

4. Migrate incrementally — Apply strangler fig pattern with feature flags. Route traffic via a facade; shift load gradually.

   • Validation checkpoint: Verify error rates and latency metrics remain within baseline thresholds after each traffic increment (e.g., 5% → 25% → 50% → 100%).

5. Validate & iterate — Run full test suite, review monitoring dashboards, and confirm business behavior is preserved before retiring legacy code.

   • Validation checkpoint: New code must be proven stable at 100% traffic for at least one release cycle before legacy path is removed.

Reference Guide

Load detailed guidance based on context:

Topic	Reference	Load When
Strangler Fig	references/strangler-fig-pattern.md	Incremental replacement, facade layer, routing
Refactoring	references/refactoring-patterns.md	Extract service, branch by abstraction, adapters
Migration	references/migration-strategies.md	Database, UI, API, framework migrations
Testing	references/legacy-testing.md	Characterization tests, golden master, approval
Assessment	references/system-assessment.md	Code analysis, dependency mapping, risk evaluation

Code Examples

Strangler Fig Facade (Python)

# facade.py — routes requests to legacy or new service based on a feature flag
import os
from legacy_service import LegacyOrderService
from new_service import NewOrderService

class OrderServiceFacade:
    def __init__(self):
        self._legacy = LegacyOrderService()
        self._new = NewOrderService()

    def get_order(self, order_id: str):
        if os.getenv("USE_NEW_ORDER_SERVICE", "false").lower() == "true":
            return self._new.fetch(order_id)
        return self._legacy.get(order_id)

Feature Flag Wrapper

# feature_flags.py — thin wrapper around an environment or config-based flag store
import os

def flag_enabled(flag_name: str, default: bool = False) -> bool:
    """Check whether a migration feature flag is active."""
    return os.getenv(flag_name, str(default)).lower() == "true"

# Usage
if flag_enabled("USE_NEW_PAYMENT_GATEWAY"):
    result = new_gateway.charge(order)
else:
    result = legacy_gateway.charge(order)

Characterization Test Template (pytest)

# test_characterization_orders.py
# Captures existing legacy behavior as a golden-master safety net.
import pytest
from legacy_service import LegacyOrderService

service = LegacyOrderService()

@pytest.mark.parametrize("order_id,expected_status", [
    ("ORD-001", "SHIPPED"),
    ("ORD-002", "PENDING"),
    ("ORD-003", "CANCELLED"),
])
def test_order_status_golden_master(order_id, expected_status):
    """Fail loudly if legacy behavior changes unexpectedly."""
    result = service.get(order_id)
    assert result["status"] == expected_status, (
        f"Characterization broken for {order_id}: "
        f"expected {expected_status}, got {result['status']}"
    )

Code Patterns — Modernization Examples

1. Strangler Fig Wrapper — Introduce a facade that routes traffic between legacy and new implementations based on feature flags. Allows gradual traffic shift without big-bang rewrite.
2. Anti-Corruption Layer — Isolate old domain model from new one via explicit translation layer. Prevents legacy paradigms from infecting new codebase.
3. Feature Toggle for Gradual Migration — Expose environment flags to enable/disable new code path per deployment. Enables rollback without code changes.

Comment Template — Migration Boundaries

Use language-appropriate documentation at every legacy↔new boundary:

JSDoc (JavaScript/TypeScript)

/**
 * @deprecated Use newPaymentService() instead.
 * @migration Started 2026-Q2, target completion Q3.
 * Wrapped by anti-corruption layer in `paymentFacade.js`.
 * @see {@link paymentFacade.js} for routing logic.
 */
function legacyChargeCard(cardToken) { ... }

Python docstring

def charge_legacy_card(card_token: str) -> Dict:
    """Charge card via legacy gateway (DEPRECATED).
    
    Migration: Anti-corruption layer in payment_facade.py routes new requests
    to new_gateway. Keep until 2026-Q3 for backward compatibility.
    See: MIGRATION_LOG.md for timeline.
    """

Lint Rules — Legacy Code Analysis

• SonarQube — Enable legacy-code profile: high cyclomatic complexity, dead code, code duplication detection.
• Language-specific linters — New code enforces strict rules (ESLint/strict, mypy/strict); legacy code flagged but not enforced (report-only mode).
• Dependency scanning — Run monthly vulnerability audits; flag deprecated dependencies with remediation timeline.

Security Checklist (5+ items)

• Legacy auth migration — Document all auth schemes in legacy system; design gradual migration to modern auth (OAuth, OIDC) with dual validation during transition.
• Data encryption at rest — Sensitive data in legacy storage must be encrypted; use envelope encryption if key rotation is required.
• Dependency vulnerability scan — Audit all legacy dependencies; create remediation roadmap (upgrade, vendor patch, isolate via network).
• API backward compatibility — Verify all facade contracts maintain version compatibility; document deprecation timelines in API docs.
• Audit logging during migration — Log all requests routed via facade with timestamp, source, and path (legacy vs. new); enables canary monitoring.

Anti-patterns (Wrong ✗ / Correct ✓)

Anti-pattern	✗ Wrong	✓ Correct
Rewrite Strategy	Big bang rewrite of entire system	Incremental strangler fig with feature flags
Testing	Deploy new code before covering legacy behavior	Write characterization tests first; then refactor against golden master
API Contracts	Break existing endpoints during migration	Dual-write to old+new; maintain backward compatibility until 100% traffic proven stable
Monitoring	Deploy without metrics; check logs manually	Instrument facade with latency/error/traffic splits; automated alerts on anomalies
Shared State	Share mutable state between old+new code	Use facade as state boundary; new code owns its state; legacy data is read-only reference

Constraints

MUST DO

• Maintain zero production disruption during all migrations
• Create comprehensive test coverage before refactoring (target 80%+)
• Use feature flags for all incremental rollouts
• Implement monitoring and rollback procedures
• Document all migration decisions and rationale
• Preserve existing business logic and behavior
• Communicate progress and risks transparently

MUST NOT DO

• Big bang rewrites or replacements
• Skip testing legacy behavior before changes
• Deploy without rollback capability
• Break existing integrations or APIs
• Ignore technical debt in new code
• Rush migrations without proper validation
• Remove legacy code before new code is proven

Output Templates

When implementing modernization, provide:

1. Assessment summary (risks, dependencies, approach)
2. Migration plan (phases, rollback strategy, metrics)
3. Implementation code (facades, adapters, new services)
4. Test coverage (characterization, integration, e2e)
5. Monitoring setup (metrics, alerts, dashboards)

Knowledge Reference

Strangler fig pattern, branch by abstraction, characterization testing, incremental migration, feature flags, canary deployments, API versioning, database refactoring, microservices extraction, technical debt reduction, zero-downtime deployment