Arehsoft
There’s a legacy system somewhere in your company that everyone agrees needs to go and nobody wants to touch. It’s undocumented, it’s load-bearing, and the person who understood it left in 2019. Every proposal to replace it turns into a plan to rewrite the whole thing at once, flip a switch one weekend, and pray.
That plan — the big-bang rewrite — is the project that kills companies. Here’s the pattern we use instead, and why it works on exactly the systems that scare people.
Why the big bang fails
A full rewrite-and-cutover asks you to reproduce years of accumulated behavior — including the undocumented edge cases, the bug that became a feature, and the workaround three teams quietly depend on — and get it all right on the first try, live, with no fallback. Nobody knows the full spec, because the spec is the running system. So the rewrite ships, something breaks that no one anticipated, and there’s no way back except a weekend of panic.
The failure isn’t technical. It’s that you removed your safety net and bet everything on one moment.
The alternative: strangle it, don’t storm it
The incremental pattern — sometimes called the strangler approach — replaces the old system piece by piece while it keeps running the whole time. New and old coexist. You cut over one slice at a time, verify it, and keep the old path as a fallback until you trust the new one. No single moment where everything has to work.
Here’s how it goes in practice.
1. Put a seam in front of the old system
Before you change anything, route access to the legacy system through a layer you control — an API, a proxy, a service boundary. Right now this layer does nothing but pass traffic through. That’s the point. It’s the switch you’ll use later to send specific slices of work to new code instead of old, one at a time, without callers noticing.
If a system is so tangled you can’t even get a seam in front of it, that’s your real first project — and it’s a far smaller, safer one than a rewrite.
2. Map what it actually does — from the traffic
Don’t trust the documentation; there isn’t any, or it’s wrong. Instrument the seam and watch what actually flows through it: which operations, how often, with what data, producing what results. Real traffic tells you what the system genuinely does, including the edge cases no one remembers. This map is what a big-bang rewrite never has and always needs.
3. Carve off the smallest independent slice
Find the piece with the fewest tangled dependencies — one operation, one workflow, one data domain. Build its replacement behind the seam. Small enough that you can understand it fully and get it right.
4. Run both, compare, then cut over
This is the step that removes the risk. Before the new slice takes over, run it alongside the old one on real traffic and compare outputs. Where they agree, you have proof. Where they differ, you’ve found either a bug in the new code or an undocumented behavior in the old one — and either way you learned it safely, in the dark, with no customer affected.
Only once the new slice matches on real traffic do you flip that slice at the seam. And because the old path is still there, if anything surprises you, flipping back is instant.
5. Repeat until the old system is empty
Slice by slice, traffic moves from old to new. The legacy system gets quieter. Eventually it’s handling nothing, and you can retire it — not with a held breath, but as a formality, because nothing depends on it anymore.
What this buys you
No single point of catastrophe. Every cutover is small, verified, and reversible. The worst case is one slice, rolled back in seconds — not a company-wide outage.
Value along the way. You don’t wait two years for a payoff. Each migrated slice can be faster, cleaner, and more maintainable the moment it ships.
The knowledge you were missing. By the end, you’ve documented the old system by rebuilding it — the edge cases are now in code you understand, not in a binary nobody dares recompile.
A schedule you can steer. Because slices are independent, you can pause, reprioritize, or ship in whatever order the business needs. No death march to an immovable cutover date.
The honest tradeoff
Incremental isn’t free. Running old and new in parallel means maintaining the seam and, for a while, two systems. It asks for discipline over drama. But the cost is spread out, visible, and reversible — the opposite of a big-bang budget, which is a single enormous bet you can’t unwind once it’s placed.
Integration, legacy, the systems no one wants to touch — that’s the stuff that kills software projects, and it’s the stuff we specialize in. We modernize what’s holding you back without the risky rip-and-replace, in short cycles you can see and steer.
If you’ve got a system everyone’s afraid to modernize, tell us about it. The first thing you’ll get is a straight read on how to get a seam in front of it — the safe first step, whether or not you hire us.