Engineering Playbook
Enterprise Architecture

Legacy Migration

Strategies for modernizing monoliths (Strangler Fig, ACL, Shadowing).

Legacy Migration Strategies

Modernizing legacy systems is 90% of real-world engineering. It is rarely a greenfield project. The goal is to move from State A (Monolith) to State B (Modern) while keeping the business running.

The 6 Rs of Migration

Standard terminology (often used by AWS) for cloud migration:

  1. Rehost (Lift & Shift): Move VMs to Cloud. No code changes. Fast, but no cloud-native benefits.
  2. Replatform (Lift, Tinker & Shift): Move to cloud, but swap components (e.g., self-hosted SQL -> RDS).
  3. Refactor (Re-architect): Rewrite code to be cloud-native (Serverless, Containers). High effort, high reward.
  4. Repurchase: Drop custom app, buy SaaS (e.g., Move HR system to Workday).
  5. Retire: Turn it off. (The best code is no code).
  6. Retain: Do nothing. The risk/cost of moving isn't worth it yet.

The Strangler Fig Pattern

Named after the fig tree that grows around a host tree and eventually replaces it.

Instead of a "Big Bang" rewrite (which usually fails), you incrementally replace pieces of the legacy system.

  1. Intercept: Put a proxy (Nginx, Kong, AWS ALB) in front of the Legacy Monolith.
  2. Isolate: Identify a "seam" in the application (e.g., the User Profile module).
  3. Rebuild: Build the new microservice for that specific seam.
  4. Route: Point the proxy for that specific path (e.g., /api/users) to the new service.
  5. Kill: Remove that code from the Monolith.

Verification: Shadowing & Parallel Runs

Before you flip the switch to "Route" traffic to the new service, you must ensure parity. This is where Shadow Traffic (or "Dark Launching") comes in.

Shadow Mode

The proxy sends the request to Legacy (returned to user) AND asynchronously to the New Service (fire-and-forget). The New Service's response is discarded, but errors/metrics are logged.

Diff Comparison

Advanced Shadowing. Capture the response from Legacy and New. Compare the JSON bodies. If they differ, alert the team. Do not cut over until Diff % is near zero.

The Rollout Strategy:

  1. Parallel Run (Dark): New service receives traffic, but affects nothing.
  2. Canary: 1% of users get the real response from the New Service.
  3. Ramp Up: Increase to 10%, 50%, 100%.
  4. Decommission: Turn off the Legacy path.

Anti-Corruption Layer (ACL)

When new systems need to talk to legacy systems, the legacy data models are often weird, outdated, or poorly named.

Do not let those bad models leak into your new code.

Build an ACL (Adapter/Facade):

  1. Legacy Side: Speaks the old language (SOAP, obscure XML, Mainframe).
  2. Translation: Maps old data to your clean Domain entities.
  3. Modern Side: Your app only sees the clean interface.

This protects your new architecture from the technical debt of the old one.

Data Synchronization Risk

While Strangling, you often need "Dual Write". If the New Service writes to a new DB, how does the Monolith know? You may need CDC (Change Data Capture) or Double-Writes to keep both DBs in sync during the transition.


Real-World Migration Timeline: E-Commerce Platform

Phase 1: Preparation (Months 1-2)

Key Activities:

  • Assessment: Identify legacy system dependencies and data flows
  • Infrastructure: Set up cloud environment, monitoring, and deployment pipelines
  • Team Training: Upskill team on new technologies and patterns
  • Risk Mitigation: Plan rollback strategies and communication

Phase 2: User Service Migration (Months 3-4)

Week 1-6: Build New Service

  • Create new User microservice with modern architecture
  • Implement authentication and authorization
  • Set up user data migration scripts
  • Build monitoring and logging

Week 7-8: Shadow Testing Route traffic to both systems silently:

Week 9-10: Canary Release

  • Route 1% of real users to new service
  • Monitor performance, errors, and user experience
  • Compare metrics between old and new systems

Week 11: Full Cutover

  • Gradually increase traffic to 100%
  • Monitor system stability
  • Decommission legacy user code

Phase 3: Order Service Migration (Months 5-7)

Data Migration Strategy:

  1. Initial Sync: Copy historical order data
  2. Change Data Capture: Keep data synchronized during migration
  3. Validation: Verify data integrity
  4. Cutover: Switch to new system

Risk Mitigation:

  • Automated rollback procedures
  • Real-time monitoring dashboards
  • Incident response team on standby
  • Customer communication plan

Phase 4: Payment Service (Months 8-9)

Special Considerations:

  • PCI Compliance: Ensure new system meets security requirements
  • Financial Accuracy: Zero tolerance for errors in payment processing
  • Third-party Integration: Maintain payment gateway compatibility
  • Regulatory Requirements: Compliance with financial regulations

Migration Success Metrics

Technical Metrics

  • System Uptime: Maintain 99.9% availability during migration
  • Response Time: New system must be equal or faster
  • Error Rate: Less than 0.1% errors for migrated services
  • Data Accuracy: 100% data integrity validation

Business Metrics

  • User Experience: No degradation in customer satisfaction
  • Transaction Volume: Maintain or increase processing capacity
  • Cost Reduction: Achieve 30% infrastructure cost reduction
  • Development Velocity: 50% faster feature delivery

Risk Indicators

  • Rollback Frequency: More than 1 per phase indicates issues
  • Data Inconsistency: Any drift between systems
  • Performance Regression: >10% degradation in key metrics
  • Team Burnout: Overtime hours indicating migration stress

Common Migration Pitfalls

1. Underestimating Data Complexity

Problem: Legacy data is messier than expected Solution:

  • Spend extra time on data analysis
  • Build robust data validation
  • Plan for manual data cleanup
  • Have data experts on the team

2. Ignoring Cultural Change

Problem: Team resists new technologies and processes Solution:

  • Involve team in planning decisions
  • Provide comprehensive training
  • Celebrate small wins during migration
  • Address concerns openly

3. Premature Cutover

Problem: Cutting over before adequate testing Solution:

  • Establish clear completion criteria
  • Require stakeholder sign-off
  • Plan rollback procedures
  • Use feature flags for safe deployment

4. Forgetting Decommissioning

Problem: Legacy systems continue running and costing money Solution:

  • Plan decommissioning from day one
  • Track migration progress against budget
  • Set hard deadlines for legacy shutdown
  • Celebrate when old systems are turned off

Post-Migration Activities

1. Performance Optimization

  • Monitor system performance in production
  • Identify bottlenecks and optimize
  • Right-size infrastructure
  • Implement advanced monitoring

2. Knowledge Transfer

  • Document new architecture thoroughly
  • Train operations teams on new systems
  • Create runbooks for common issues
  • Establish on-call procedures

3. Continuous Improvement

  • Gather feedback from users and team
  • Plan architectural improvements
  • Evaluate migration lessons learned
  • Plan next modernization phase

4. Cost Optimization

  • Review actual vs. projected costs
  • Optimize cloud resource usage
  • Implement auto-scaling policies
  • Plan for future growth