The twelve-year-old app that runs the company
Everyone wanted to replace it. Nobody dared. A CIO's quiet rebellion against the rewrite — and the case for modernizing the thing you're most afraid to touch, one layer at a time.
We spoke with Priya, CIO of an enterprise that ran on a system everyone wanted gone and nobody dared touch — about her quiet rebellion against the rewrite.
Everyone called it the Monolith, and not kindly. Twelve years old, written in a language new hires had to be taught. The three people who truly understood it had a combined retirement date that kept me awake more nights than I'd admit in a board meeting. And it ran the company — not metaphorically. Billing, fulfillment, the thing that turns an order into money. If the Monolith stopped, the company stopped.
So every year someone proposed killing it. A rewrite. Greenfield, microservices, modern stack, the works. And every year the proposal died the same death: someone senior did the math on what happens if the rewrite slips — and rewrites always slip — the room went quiet, and the Monolith lived another year. A little older, a little more load-bearing, a little more feared.
No — they were doing the statistically correct thing. The big-bang rewrite is one of the most reliably disastrous moves in all of software. You spend two years and a fortune rebuilding something to do exactly what it already did, you discover halfway through that the old system encoded a thousand business rules nobody wrote down, and you arrive late and over budget at a new system that's just the old one with newer bugs.
A rewrite asks you to reproduce, perfectly, a system nobody fully understands — and pays you nothing for the effort until the day you flip the switch and pray.
And here's the thing: the Monolith's real problem wasn't that it was old. Plenty of old code runs the world happily. Its problem was that it had become a single, undividable thing — change one part, risk all of it; couldn't deploy on Tuesday without holding your breath; couldn't hire anyone who wanted to work on it. The fear wasn't about the technology. It was that every change was an all-or-nothing bet, and the stakes were the whole company.
Worship or demolish
- Leave it alone & let the fear compound
- Or bet the company on a two-year rewrite
- Both options were bad
Make it divisible
- Wrap the core, don't replace it
- Carve out one capability at a time
- Shrink it until it stops being scary
The pattern has an unfortunate name — the strangler fig, the vine that grows around a tree until one day the tree is gone and the fig stands in its exact shape. You don't cut the tree down. You grow the new thing around the old one, piece by piece, until the old one quietly retires, having never once stopped working. That's where Red Hat came in, and what matters is the goal was never "move to the cloud" or "adopt containers" as ends in themselves. The goal was to make the Monolith divisible — to turn one terrifying thing into many small, ordinary, replaceable things.
They didn't rewrite it. They wrapped it — containerized the Monolith as-is on a standard platform, put an API in front of it, then carved out one capability at a time into new services running alongside it. No flag day, no big bang. The twelve-year-old core kept running payroll the entire time, shrinking quietly until what remained was small enough to stop fearing.
We started by doing nothing to the code at all — containerized it exactly as it was, same thousand undocumented rules, on a standard platform. That alone changed the emotional temperature. Then an API in front, the clean seam. And only then the patient part: one capability at a time — a notification service here, a pricing rule there — carved out and rebuilt alongside. The API decided who answered each request, old core or new service. When a piece proved itself, traffic shifted. When it didn't, we flipped one route back and nobody outside the team ever knew. No flag day. No night-of-the-cutover with me pacing over a rollback plan nobody trusted. The Monolith just got smaller, quarter by quarter, the way a glacier retreats — too slow to watch, undeniable over time.
Two years on, the thing we used to call the Monolith is a modest little service handling the few truly gnarly rules that weren't worth rebuilding. Those three engineers' retirement dates don't keep me awake anymore, because the knowledge that lived only in their heads now lives in a dozen small services with tests and owners. The company never stopped billing for a single day.
Stop letting people frame modernization as a choice between worship and demolition. The system you're most afraid to touch is precisely the one you must learn to touch — not by betting the company on a rewrite, but by making it small enough, one careful layer at a time, that it stops being something you fear and becomes something you simply maintain. You don't slay the dragon. You domesticate it.