STAR: Modernizing a Legacy System
Senior signal: incremental strangler-fig migrations, business-value framing, and not pretending you can rewrite from scratch.
Deep dive
What works
- Strangler fig: route new functionality to new system; gradually migrate read paths, then write paths.
- Anti-corruption layer: protect the new model from legacy concepts.
- Business framing: every migration milestone tied to a customer or operational outcome — not "we're rewriting things".
- Make the legacy observable first. You can't migrate what you can't measure.
What doesn't
- Big-bang rewrites.
- Migrating for technology purity with no business need.
- Underestimating the long tail (the last 10% of features takes 50% of the time).
Real-world example
From production"We had a 12-year-old Java 8 monolith handling claims. Rather than rewrite, I proposed strangler-fig: extract one bounded context per quarter behind a routing layer. First extraction (notifications) shipped in 8 weeks with zero customer impact. Tied each extraction to a specific business outcome — notifications gave us per-channel A/B tests we couldn't do in the monolith. Two years in, ~60% of traffic on the new platform, monolith on maintenance-only mode, team velocity doubled."
Interview questions
1 senior-levelQ1How would you modernize a monolith?▾
Strangler fig with a routing layer; extract by bounded context starting with the one with highest pain and lowest coupling; tie each extraction to a business outcome; instrument the monolith before touching it so you can prove migrations are safe. Resist big-bang rewrites — they almost always fail.
Common mistakes
Proposing rewrites without a business case.
Picking the hardest context first to 'prove the architecture'.
Trade-offs
Strangler fig means living with two systems for a long time — invest in good observability across both.