Somewhere in the second or third meeting with a new client, a particular slide tends to appear. It shows the current platform on the left, drawn in a slightly apologetic grey, and the target state on the right in confident colour, with an arrow between them. The arrow is where the money goes, and the plan for the arrow is usually some version of the same idea: we will build the new thing alongside the old thing, and when the new thing is ready, we will switch.
I have sat through a good many of these meetings over the years, across retail, financial services and defence, and lately the slide has acquired a new line. The estimate for the arrow has been cut, sometimes in half, and the reason given is AI-assisted development. Everything else about the plan is unchanged.
That worries me more than the original slide ever did, and this post is an attempt to explain why, and to set out what I think a technology leader should ask before agreeing to any of it.
I should declare an interest before going further. I work for a services company, and services companies have, historically, done rather well out of rewrites. That is precisely why my advice is to be suspicious of anyone, me included, who turns up with a target-state diagram before they have asked what the current system actually does.
Why rewrites fail, and why they always have
There is nothing new about the rewrite fantasy. Joel Spolsky wrote about it in 2000, using Netscape’s decision to throw away its browser code and start again as the cautionary tale, and the argument he made then has held up for a quarter of a century: old code is not worse than new code simply because it is old. It has been used, and using it is how the bugs were found and fixed. Every odd-looking conditional and every comment that says “do not remove this” is a lesson the organisation paid for once and will pay for again if it discards the code that holds it.
What that argument does not fully capture, because it was written about a single product rather than an enterprise platform, is that the code is the least of it. A platform that has been running for ten or fifteen years has grown a set of behaviours that nobody wrote down. It has integrations with systems that were themselves replaced twice. It has a reporting job that runs at three in the morning and that a team in finance depends on without knowing where it comes from. It has data with fifteen years of exceptions in it, and a set of people who know how to nurse it through month end.
Not one of those things is code, and not one of them is made cheaper to replace by a tool that writes code faster.
The rewrites I have seen go wrong did not fail because the engineers could not build the new system. Mostly they built it, or a decent chunk of it. They failed at the point of switching over, when the parallel run exposed a thousand small differences between what the old system did and what everybody believed it did, and the organisation’s patience ran out before the differences did. The new system then either limped into service with the old one kept alive “temporarily” beside it, or it was quietly shelved, with the business having spent two years and a great deal of money to learn what it already had.
What AI changes, and what it does not
I use AI-assisted development daily, and I have written before about what it takes to make that trustworthy. It is a real capability, and it does make some parts of a modernisation programme cheaper. It is worth being precise about which parts.
Generating new code is cheaper. A team with a clear specification can produce a working service in a fraction of the time it took five years ago, and if the specification is good, the service will be reasonable.
Understanding old code is also cheaper, and this is the part that gets overlooked. Pointing a capable model at a codebase and asking it to explain what a module does, to trace how a particular field flows from input to report, or to draft characterisation tests that pin down current behaviour, is a genuinely new kind of help. The archaeology that used to take a senior engineer weeks can now be done in days, with the engineer checking the model’s account rather than building it from nothing. It is not a substitute for the engineer, for reasons I have covered before, but it changes the economics of finding out what you have.
What has not changed is everything in the list above. The model cannot tell you about the reporting job that finance depends on, because it is not in the code. It cannot tell you which of the fifteen years of data exceptions still matter. It cannot run the parallel run for you, or reconcile the differences, or explain to the operations team how they will support a system that arrived from a sequence of prompts nobody kept. The cost of a rewrite lives in those places, and it always did. The halved estimate on the slide has taken the discount from the one part of the job that was never the expensive part.
There is a second effect that I think is more dangerous. When building is cheap, the pressure to think before building goes down. It was always tempting to skip the question of what the current system does and jump straight to the target state, and the tools now make that skip feel free. It is not free. It simply moves the cost to the switchover, where it is far harder to see coming and far more expensive to pay.
Old is not a reason
The reasons given for a rewrite are usually some mixture of the following: the technology is old, it is hard to find people who will work on it, and it takes too long to change anything.
The first is not a reason at all. Age tells you nothing about whether a system is fit for purpose. There are Java platforms from 2008 running businesses perfectly well, and there are eighteen-month-old microservice estates that nobody can change safely. The question is whether the system can support the rate of change the business needs from it, and that has to be asked about the business, not the calendar.
The second is sometimes true. If the platform runs on something for which there is genuinely no market of engineers, and your own people are approaching retirement, that is a real constraint with a real deadline. It is also, in my experience, invoked far more often than it applies. “Hard to hire for” frequently means “our engineers would rather work on something newer”, which is a legitimate retention concern but a different problem with different answers.
The third is the one worth taking seriously, and it is almost never what it appears to be. When a team tells me that a change which should take a week takes three months, the language the system is written in is rarely the cause. What I usually find instead is a system with few or no automated tests, so every change needs a lengthy manual regression cycle; a deployment process that involves a change board, a maintenance window and a person with a checklist; and an architecture where three unrelated things share a database so that nothing can be altered in isolation. Those are all fixable without a rewrite, and fixing them is the modernisation. Rewriting the system into a new language while keeping the same testing, release and coupling problems produces a new system that is slow to change.
When to leave well alone
Some systems should simply be left as they are. A platform that does its job, changes two or three times a year, and is understood by the people who run it is not a candidate for modernisation, however old it looks on the diagram. The right investment in that system is observability, so that when it does fail you know why; documentation, so that the knowledge of how to run it is held somewhere other than in two people’s heads; and a supported path for the underlying platform, so that you are not caught out by an operating system or a database version reaching end of life.
That last point is the one legitimate hard deadline I encounter regularly, and it is worth distinguishing from the others. If the thing your platform runs on is going out of support, you have a date, and the work has to be done by then. Even so, the work is usually a migration rather than a rewrite: moving what exists onto something supported, with as few changes to behaviour as possible, and leaving any redesign for afterwards, when you can do it from a stable base. Combining a platform migration with a functional rewrite is one of the most reliable ways I know to make a programme fail, because when something breaks, nobody can say which of the two changes caused it.
When a rewrite is right, and how to do it anyway
There are cases where starting again is the correct answer. The clearest is when the business has changed and the system embodies the old business: a platform built for a wholesale model in a company that now sells directly, or one designed around a single country that is now trading in twelve. In that situation the system is not merely old, it is wrong, and no amount of tidying will make it right.
Even then, the way to do it is not to build the whole replacement and switch. It is to identify a seam, usually a single capability with a clear boundary, route that capability to a new component, prove it in production, and then take the next one. Martin Fowler described this pattern in 2004, and the name it has since acquired, the strangler fig, has stuck because the pattern works. The old system shrinks gradually, each step is reversible, and the organisation learns what the old system actually did one piece at a time rather than all at once on switchover night.
AI-assisted development is well suited to this approach, and this is where the tools earn their keep: bounded pieces of work, with a specification derived from the observed behaviour of the piece being replaced, and characterisation tests that make the old behaviour explicit before the new code has to match it. That is a very different proposition from generating a new platform and hoping it agrees with the old one.
Who runs it on day 366
The question I ask most often in these meetings, and the one that produces the longest silence, is who will operate the new platform a year after it goes live.
The consultants will have gone. The engineers who built it will, some of them, have moved on. The operations team who kept the old system running will have been told the new one is self-service and does not need them. If the answer to the question is a shrug, then what you have is a picture rather than a plan.
An architecture the organisation cannot operate is not a modernisation, whatever it cost. Kubernetes is a fine platform for a team that has the skills and the appetite to run it, and a slow-motion outage for one that does not. Serverless removes a class of operational work and adds a class of architectural constraint that some teams will find harder to live with than the servers were. Neither is the right answer in general. The right answer is the one that matches the people who will be there on day 366, and that has to be decided before the arrow on the slide, not after.
What this means in practice
Write down what the system does before deciding what to do with it. Not the architecture, the behaviour: what goes in, what comes out, who depends on it, what runs at three in the morning. Use AI to speed this up, and use your engineers to check it. If you cannot produce this document, you are not ready to replace the system, because you do not know what you would be replacing.
Separate the reasons. “Old” is not one. “Hard to hire” needs evidence. “Slow to change” needs a diagnosis, and the diagnosis is usually testing, release and coupling rather than language.
Fix delivery before fixing architecture. Tests, a deployment pipeline and some decoupling will get most systems to an acceptable rate of change at a fraction of the cost of replacement, and they are prerequisites for a safe replacement in any case.
Treat a platform end of life as a migration, not an opportunity. Move what exists, change as little as possible, and redesign afterwards from a stable base.
Modernise at the seams. Replace one bounded capability at a time, in production, with the old behaviour pinned down in tests before the new code has to match it.
Halve the estimate only where the work has actually got cheaper. Generating and understanding code are cheaper. Reconciliation, data, integration, switchover and operations are not, and they are where the money goes.
Decide who runs it, and design for them. The people who will operate the platform a year after go-live are a constraint on the architecture, not an afterthought to it.
The question worth asking
The question is not whether to rewrite. It is what you would need to understand about the current system before you could safely change any part of it. If you can answer that, you will usually find you do not need the rewrite. If you cannot, you are not ready for one, and no amount of generated code will change that.
Working through a modernisation decision? If you are weighing up whether to replace, migrate or leave well alone, and want a view from someone who has seen both the successes and the ones that never made it to switchover, get in touch . I work through exactly these questions with technology leadership teams regularly.