When to Modernise Legacy Systems vs Build New Platforms

The "Rewrite" Trap

Developers love to say, "This code is a mess, let's rewrite it from scratch!" This is often a trap. Rewriting a working system resets your accumulated knowledge to zero and introduces new, unknown bugs. But keeping a dinosaur on life support is also fatal.

The Strangler Fig Pattern

Named after the fig tree that grows around a host tree and eventually replaces it, this pattern is the gold standard for modernization.

Instead of a Big Bang rewrite, you build new features in a modern stack (e.g., Next.js/Node.js) and put them alongside the legacy system (e.g., a .NET monolith). You use APIs and Microservices to route traffic.

Slowly, you chip away at the monolith, moving one domain at a time (e.g., "Auth", then "Billing") to the new microservices. Ideally, the user never notices anything changed.

Decision Framework: The 6 R's

Amazon's migration framework is a useful mental model:

1. Rehost (Lift & Shift): Move VMs to Cloud. Minimal benefit, but quick.
2. Replatform: Move to Managed Services (e.g., RDS instead of SQL Server on VM).
3. Refactor: Rewrite code to be Cloud-Native. High effort, high reward.
4. Repurchase: Switch to SaaS (e.g., move customized CRM to Salesforce).
5. Retire: Turn off features no one uses (often surprisingly many!).
6. Retain: Do nothing. Sometimes, the legacy system is fine.

The Human Factor

Modernization is also about teams. If your team knows Java 8 but hates it, letting them build the new components in Go or Rust (if viable) can be a massive morale booster and retention tool. Custom Software Development is cultural transformation.