Replatforming without rewriting the business
The big-bang replatform is still the default proposal, and it is still the reason so many of them are remembered as a bad year.
Every replatform begins with the same accurate observation: the current system is holding the business back. It usually proceeds to the same inaccurate conclusion: therefore the current system should be replaced, in full, by a new one, on a date.
The reason this is attractive is that it is easy to explain, easy to budget and easy to approve. The reason it goes wrong is that a legacy platform is not only software. It is also fifteen years of accumulated business rules, most of which are undocumented and some of which are load-bearing.
What actually causes the overrun
Replatform overruns are rarely caused by the technology being difficult. They are caused by discovering, in month seven, a behaviour the old system had that nobody knew about and several parts of the business depend on. The discount that applies to one customer group because of an agreement made in 2013. The report that finance reconciles against. The overnight job that quietly fixes bad data before anyone sees it.
You cannot enumerate these in advance, because the people who know about them do not know that they are unusual. They will only surface when something stops happening.
Incremental replacement, in practice
The alternative is well established and consistently under-used: run the new platform alongside the old one, move capability across in slices, and keep both working until the last slice has moved. This is more expensive in aggregate and considerably cheaper in risk, and it converts a single large failure mode into a series of small recoverable ones.
The practical shape of it tends to be:
- Put a routing layer in front of both systems so traffic can be moved per route, per user group, or per percentage, and moved back.
- Choose the first slice for its low coupling and its high visibility, not for its business value. The first slice is proving the mechanism.
- Move read paths before write paths. Reading from the new system while writing to the old one is a safe way to discover data problems early.
- Keep a rollback rehearsed, not documented. An untested rollback is a paragraph, not a plan.
- Delete the old path as each slice completes. Otherwise you have two systems permanently, which is the failure mode of this approach.
The organisational cost
Incremental replacement asks more of the organisation than the big bang does. It requires sustained attention over a longer period, it does not produce a launch moment, and it is harder to report on to a board that wants a date. There is a real cost to that, and it is worth stating honestly rather than pretending the approach is free.
A big-bang cutover converts an engineering problem into a governance event. That is why it is popular, and it is why it fails badly rather than gradually.
When a big bang is right
It is not always wrong. If the system is small, if it is genuinely well understood, if the business rules are documented and current, or if a regulatory deadline makes a parallel period impossible, then a clean cutover is the sensible option. The mistake is choosing it by default, and then discovering the rules during the cutover weekend.
The question to settle before committing is not which approach is better in principle. It is how confident you are that you can list what the current system does. If the honest answer is that you cannot, incremental replacement is not a preference — it is the only approach that accounts for what you do not know.