Why the new system can’t do what the old one did
Change in organisations moves from the top down.
Not because that’s a management principle worth repeating, but because it is simply how it works. When leaders see the new world clearly — understand what the organisation needs to become, not just what it needs to replace — that clarity travels. When they don’t, that travels too. The rest of the organisation takes its cues from what leadership is actually holding, not what it says in the project charter.
Most enterprise system replacements begin without that clarity. They begin with a problem that is real and urgent: the current system is ageing, unsupported, technically fragile. The decision to replace it is reasonable. The budget gets approved. The project kicks off.
On the surface, things look like they’re moving. Then they get stuck. Then complex. Then the organisation is in a deadlock it cannot fully explain — and the people inside it are genuinely struggling to name what went wrong.
That deadlock has a shape. It is not random. It is the convergence of several things happening at once.
We start with silos, not a map.
The change journey rarely begins with a holistic picture of the enterprise — where everything connects, how the organisation will look after the transition, what the roadmap from here to there actually is.
It begins with: let’s replace the finance system. Then HR. Then operations. Each project scoped and funded as if the organisation were a collection of independent functions.
What gets missed in that framing is the connective tissue. The reason the old system works — even when it is outdated and held together with institutional memory — is that someone, years ago, made deliberate decisions about how data moves across the organisation. How a job becomes an invoice. How a purchase order connects to a contract. How one process feeds the next.
Silo projects don’t map that. The new systems go live, each one technically sound in isolation. They meet at the seams and fail. That is where the business actually runs.
The requirements described the past.
When the team sits down to define what the new system needs to do, they describe what the old one already does. Every field. Every report. Every exception handling. Every manual workaround that became so normalised over the years that nobody remembers it started as a workaround.
This is not laziness. It is how requirements get written when the people writing them are immersed in the current process. The question being asked, implicitly, is: how do we make the new system behave like the old one?
That question is the problem.
It forecloses the more important question: what should this process actually look like — and can we use this moment to change it?
The result is organisations that spend significant money to faithfully replicate processes that no longer serve them. A 22-step approval workflow that existed because two directors didn’t trust each other in 2009 gets rebuilt, at cost, in a modern platform. The people are long gone. The logic that created the process is gone. The process remains.
The vendor is not who you think they are.
Software vendors, in this space, are still maturing. Many of them. Their sales teams have targets. Their product roadmaps are optimistic. They win deals by demonstrating capability that is either partially built, dependent on a future release, or conditional on an implementation environment that doesn’t match yours.
This is not always deliberate. It is structural. The organisation buying the system is interacting primarily with the people whose job is to close the deal. The people who will be configuring the system at 11pm the week before go-live are a different group entirely.
Vendors come and go. They promise, under-deliver, get acquired, rebrand, or quietly retire the product. Organisations that have been through this more than once recognise the pattern. The ones that haven’t are still trusting the demo.
Complexity hides until something stops moving.
This is perhaps the most disorienting feature of these programs. While things are in motion, the complexity is not visible. Status reports are green. Milestones are being reached. The steering committee is receiving updates.
Complexity becomes apparent when something gets stuck. A deliverable slips. An integration doesn’t connect. A business unit resists a process change. Suddenly the weight that has been accumulating below the surface is visible — and by then it has been accumulating for months.
The people closest to the work usually know before the reports reflect it. The gap between what is known at the working level and what is reported upward is one of the most reliable indicators that a program is in trouble.
This is transformation. It is not a project.
When an organisation replaces systems that have been in place for 30 or 40 years, it is not running a project. It is undergoing transformation. That distinction matters more than any other in this list.
Projects have managers, timelines, and deliverables. Transformation requires a different quality of leadership — one that holds direction when the work meets resistance, which it always does. One that governs the change rather than just tracking it.
If an organisation misses this, it treats the whole undertaking as a series of standard projects, assigns it accordingly, and wonders why the outcomes keep disappointing. Some organisations run this cycle more than once before recognising what they keep missing.
The discipline required to change how a 40-year-old organisation works cannot be delegated to a project team. It has to live at the top.
We look for our old car in a new dealership.
If you have driven the same model for 30 years, you don’t walk into a showroom looking for the best available vehicle. You walk in looking for your car — but newer. Same seat position. Same instrument cluster. Same blind spots you have learned to compensate for. You buy familiarity dressed as progress.
This is what happens inside organisations too. The ops team insists the new scheduling system match the layout of the old one — because that is how they learned to read it 15 years ago. The finance team rejects a more efficient approval process because it doesn’t match the sequence they know. The new system gets bent toward the shape of the old one until the gains that justified the investment have been designed out.
Identifying the need for change is straightforward. Actually changing — thinking differently, working differently, being willing to unlearn what decades of practice has made instinctive — is a different matter entirely.
What the organisations that get through this do differently.
They are deliberate about the journey before they enter it. They don’t stumble in through a project or two and discover the complexity mid-flight.
They map the enterprise before they scope the silos. They ask what the organisation needs to become, not just what software it needs to replace. They understand the vendor relationship as commercial and govern it accordingly. They watch how the rest of the world handles problems similar to theirs — not to copy, but to learn without having to repeat every mistake from scratch.
And their leaders stay close enough to see what is actually happening, not just what is being reported.
These are not sophisticated interventions. They are foundational ones. The organisations that do them don’t avoid difficulty. They avoid the particular kind of difficulty that comes from being surprised by something entirely predictable.
