What I check before approving a platform rewrite

I have been on both sides of this conversation. I have asked for a rewrite and been told no, and I have had one asked of me and said yes — most recently to replace a monolithic licensing product with container-native microservices, a programme that took release cadence from twice a year to daily and cut infrastructure cost by 70%.

That one worked. Plenty do not, and the failures rarely come from the engineering. They come from approving a rewrite that was solving a problem nobody had named out loud. These are the five questions I ask before I sign, in the order I ask them.

1. What breaks in the business if we do nothing for eighteen months?

Not what annoys engineering — what breaks commercially. When we rewrote, the answer was concrete and awkward: the product could not go past a thousand users, so every enterprise conversation ended the same way. That is not a technical complaint, it is a ceiling on the addressable market, and it makes the rewrite a revenue argument rather than a hygiene one.

If the honest answer is “nothing much, it just stays unpleasant to work in”, you do not have a rewrite. You have a refactoring budget and a morale problem, and those are cheaper to fix separately.

2. Can you name the constraint, or only the symptom?

Slow releases, brittle deploys and long onboarding are symptoms. They can be caused by architecture, or by a test suite nobody trusts, or by one person being the only reviewer for a critical module. Two of those three are not fixed by a rewrite, and a rewrite will faithfully reproduce them in the new system.

The test I use: describe the constraint without naming a technology. If you cannot, the diagnosis is not finished.

3. What does the business get before the end?

A rewrite that delivers nothing until it delivers everything is a bet on an unbroken eighteen months of organisational patience. I have never seen that patience survive contact with a bad quarter.

Insist on a sequence where each stage is independently valuable — the streaming data path before the full platform, the new pricing model before the last service is migrated. This is not just risk management. It changes the conversation when a sponsor asks in month seven what they have bought, because you have an answer that is already in production.

4. Who owns the old system while the new one is built?

The most predictable failure in a rewrite is not technical, it is staffing. The strong engineers move to the new platform, the old one becomes a maintenance posting nobody wants, and its reliability quietly degrades over exactly the period you need it to be boring. Customers experience the rewrite as a decline in service, which is the opposite of the story you are trying to tell.

Name the owner of the old system, staff it properly, and make that role visibly a good one. If you cannot fill it, you have learned something about how long the migration will really take.

5. What number did Finance agree to, before we started?

I get the ROI model agreed with Finance and the business unit leads before a programme begins, and reported against quarterly afterwards. Not as governance theatre — because a number nobody signed up to in advance is a number nobody believes at the end. It also forces a useful argument early, while it is still cheap to have: if Finance will not agree the baseline, you and they have different beliefs about the problem, and better to find that out in week one.

The uncomfortable version

Most rewrite proposals I have seen were arguments about code that were really arguments about something else: an org design that put too much in one team’s hands, a commercial model the architecture could not express, or an engineering group that had lost confidence and wanted a fresh start. All three are real problems. None is best solved by rewriting the software, and a rewrite launched to solve them tends to end with the same problem in a newer codebase.

The five questions are really one question asked five ways: do we know what we are actually fixing? When the answer is yes, rewrites work — ours did. When it is no, no amount of architecture rescues it.