Somewhere in your company there is a system nobody wants to open.
It runs payroll, or invoicing, or the thing that moves orders to the warehouse. Nobody currently employed wrote it. One person understands the scheduler, and everybody has quietly learned to route questions to them. When a change is needed the estimate doubles, then doubles again, and eventually somebody in a meeting says the word.
Rewrite.
Here is the strange part about that word inside a big company.
The budget usually gets approved.
Everyone agrees the platform is a risk. Procurement finds the money, budget approval sails through the boardroom, a team is assembled, a target date is drawn on a slide, and the room empties feeling relieved. Two years later both systems are running, the date has moved three times, and the person who championed it has left for another company.
Sitting inside corporate programmes like this, watching them from the client side, one thing became clear. The engineers were never the problem. The shape of the ask was.
Why a funded rewrite still fails
The failure is structural, and it arrives in the same four shapes every time.
Parity is a moving target. You are building toward what the old platform does. That platform keeps changing while you build, because the business does not stop for you. Your finish line walks away at the speed of one maintenance team.
Nobody knows what it does. Not the docs, not the tests, not the person who owns the scheduler. What it does is defined by twelve years of production behaviour, including the behaviours that are technically wrong and that three downstream teams now depend on. You find these one at a time, in the order of how angry the person is who found them first.
Nothing ships until everything ships. Two years of work with no delivery becomes a political problem long before it becomes an engineering one. Every quarter you ask for trust and hand back a status update. The first time the company has a bad quarter, guess which line item is easiest to cut.
One team, two systems. Funding a replacement never pauses maintenance on the original. The same people keep a platform alive while replacing it, and the replacement loses that argument every single time, because production pages at three in the morning and a migration does not.
None of those four are fixed by better engineers, a better framework, or a bigger budget. More money makes each of them worse, because it buys more time before anybody has to say out loud what is happening.
Starve it instead
Put a boundary in front of the old platform, then take capabilities away from it one at a time until nothing is left.
Nothing gets replaced. It gets starved.
The sequence matters far more than the tooling.
Find the seam first. Every old platform has a place where requests arrive, and that place is where you get to lie about who is answering. A route, a queue, a scheduled job, one entry function. You want the narrowest point where something can sit in front of it without changing what sits behind it.
Then route everything through the seam and change nothing else. This step delivers no features and feels like waste. It is also the only step that makes every later step reversible. Teams skip it to look productive, then spend a year unable to roll anything back.
Then move exactly one capability. Not the interesting one. Not the hardest one. Not the one everybody argues about in the rollout meeting. Take the capability with the fewest callers and the clearest edges, and move it behind the seam. Now the new thing is in production carrying real traffic, in week three rather than year two.
Then delete the old path.
This is where teams quietly stop, and it is the entire point.
Measure deletions, not features
Here is the opinion that starts arguments in enterprise rooms, and I will stand on it.
Progress on a migration is measured in deletions.
Anybody can stand up a new service. The evidence that a capability truly moved is that the old one is gone, no caller broke, and nobody had to be told. Until the old path is deleted you have migrated nothing. You have written the same thing twice, and taken on the cost of keeping both of them correct forever.
So when a team reports that eight of twelve capabilities are migrated, ask one question.
How many paths did you delete last month.
If the answer is zero, the migration sits at zero, whatever the slide says. And now you know why year two looks exactly like year one.
What to ask for on Monday
Do not ask for a rewrite budget. You will probably get it, and that is the trap.
Ask for one quarter to put a boundary in front of the platform, move the smallest capability behind it, and delete the old path.
That is an ask a business person can say yes to. It returns something real in twelve weeks. It can be stopped at any point without loss. And it never asks anybody to believe a two-year forecast written by people who have not yet opened the scheduler.
The fear underneath all of this, the one that keeps large companies circling the same platform for years, is that nobody left understands it and therefore nobody can safely touch it.
That fear is correct. It is also the argument for shrinking what you must understand, one capability at a time, until what remains is small enough to hold in a single head.
The old platform stops getting worse the moment it stops being the only way in.
Your turn
What is the oldest system still running at your company, and has anybody there ever managed to delete a piece of it?
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.
Top comments (0)