The single most reliable way to burn $10M and 2 years is to rewrite a legacy enterprise system 'from scratch on modern infrastructure'. It never works. The rewrite starves the current system of maintenance while never quite catching up on feature parity, and the org either abandons the project or ships a version 2 that's worse than the original.
Modernization is a series of small, boring migrations that compound. Here's how it actually works.
The strangler-fig pattern in one paragraph
Named after a real botanical species. You plant the new system alongside the old, route a slice of traffic to it, gradually widen the slice as confidence grows, and eventually the new has 'strangled' the old — which can be deprecated without downtime. First described by Martin Fowler in 2004, still the correct pattern in 2026.
Step 1: Anticorruption layer
Wrap the legacy system in a facade — a thin API layer that exposes its data + operations in a clean, modern shape. Every new consumer talks to the facade, not the legacy system directly. This lets you evolve the underneath without touching every consumer.
The facade is boring code. That's a feature. It's the piece the modernization hinges on for the next 24 months.
Step 2: Instrument everything
You cannot migrate what you cannot measure. Before touching business logic, add tracing (OpenTelemetry), metrics (Prometheus), logs (Vector, Loki) and error tracking (Sentry). Understand exactly what traffic each legacy endpoint receives, from whom, and how often. Half the endpoints you thought were critical will turn out to be called by nothing. Half the endpoints you thought were vestigial will be someone's monthly report generator.
Step 3: Pick the first slice
Rules for the first slice: (a) high value to the org, (b) contained blast radius, (c) clear data ownership. A great first slice is often something like 'user management' or 'notifications' — coherent, well-understood, and touches every part of the system so you learn the org's real interfaces.
Bad first slices: the heart of the transaction engine, anything with unclear ownership, anything already mid-refactor by another team.
Step 4: Dual-write, dual-read, verify
For the slice you picked: write to both systems, read from the old, verify the new produces the same answer. Do this for 4-8 weeks. Almost every big rewrite failure is because this step was skipped.
Step 5: Cut over
Once dual-write has been clean for weeks: flip the read to the new. Keep dual-write for another 4 weeks as insurance. Then deprecate the old code path for that slice. Congratulations — you've modernized 5% of the system.
Step 6: Repeat
You're going to do this 15-25 times over 18-24 months. The rhythm is: each slice is 4-8 weeks, each slice is celebrated internally, each slice provides a demo that funds the next slice. The org sees continuous progress, not a black-box rewrite.
The three traps that kill modernization
**1. Trying to modernize the schema before the code.** You cannot easily migrate a database while a live production system depends on its exact shape. Modernize the code first, isolate the schema behind repositories, then and only then migrate the storage.
**2. Letting the new team ignore the old.** The engineers on the modernization team have to be as fluent in the legacy as they are in the new. Sending 'the new team' to reinvent while 'the old team' keeps the lights on is the recipe for a doomed rewrite.
**3. Not deprecating aggressively.** Every slice you strangler-fig must be followed by ripping the old code out. Otherwise you end up with two systems forever.
The 24-month roadmap
Month 1-3: Anticorruption layer + instrumentation. Month 4-6: First slice (usually auth / users / notifications). Month 7-12: Second and third slices, growing team confidence. Month 13-18: Core business logic — the transaction engine, the pricing engine, whatever the heart is. Month 19-24: Data platform, background jobs, reporting. End state: legacy is a museum, running on 1 VM, ready to shut down.
How Origami does it
We run legacy modernizations as embedded senior teams — usually 3-5 engineers plus a lead — working alongside the client's existing team, not replacing them. Weekly slice demos, monthly steering, quarterly board updates. Typical program: 18-24 months, $2-4M loaded, tangible slice-by-slice ROI from month 6 onwards. Book a scoping call if this maps to your situation.