IT modernisation: why big-bang replacement rarely works
Large projects to replace IT systems often fail or exceed their budgets by multiples. I explain why an incremental approach works better and how to apply it.
One of the most persistent patterns in enterprise IT is the large project to replace an old system with a new one. Three years, two contractors, and a budget that grows in the process. The result is either something working but not what was planned, or a project frozen halfway through.
I call this approach the "big bang". And I see its consequences regularly.
Why the big bang is attractive
From a management perspective the approach is logical. There is an old system with accumulated problems. There is a new system with appealing capabilities. Why not replace one with the other entirely?
The arguments for this approach are real: the integration complexity of running two systems in parallel is unpleasant, working with two systems puts extra load on the team, a phased transition drags on.
But these arguments do not outweigh the risks.
Why the big bang rarely works
The first problem is incomplete understanding of requirements at the start. A complex system accumulates unwritten rules, exceptions, and workarounds. It is impossible to discover them all upfront. They surface during the project and change the scope.
The second problem is that feedback comes late. With a phased rollout, problems are visible early and cheap to fix. With a big bang, problems appear just before launch, when rolling back is difficult and expensive.
The third problem is context drift. A project that takes two or three years ends in a different reality from the one in which it started. The business has changed, priorities have changed, sometimes the team has changed.
What an incremental approach means
An incremental approach does not mean doing everything slowly. It means breaking the change into parts, each of which creates value on its own and can be deployed to production independently.
In practice this looks like: instead of "replace the entire CRM" - "move the inbound request process to the new system, leaving everything else in the old one". This requires a temporary integration between two systems, but delivers a result in a month rather than a year, and allows testing real system behaviour under load.
The key principle: each step should be reversible or have an explicit rollback plan.
Where this applies
The incremental approach does not apply everywhere. There are systems where running two versions in parallel is technically impossible or creates unacceptable risks. In those cases, thorough preparation is essential - not abandonment of planning.
But in most typical enterprise situations - replacing an ERP module, moving to a new CRM, migrating from one cloud to another - breaking the project into phases is possible. It requires more architectural thinking at the start, but significantly reduces risk throughout the project.
Questions to check
Before approving a plan for a large IT project, it is worth asking:
- Is there a version of this project that delivers the first result in 2-3 months?
- How will we roll back if the first phase reveals unexpected problems?
- What is the minimum viable version of the new solution?
- Who from the business will test and accept the system at each phase, not just at the end?
If these questions have no answers, the plan needs more work before it is approved.