When the Old System Ran Better Than the New One

There is a particular moment in transformation programmes nobody forgets. The moment when the new system is supposed to prove everything.

The architecture has been reviewed. The migration has been planned. The testing is complete. Leadership is waiting for the first real production workload.

Then the system fails.

I learned this during a €47M billing system transformation. The system being replaced was 15 years old. Leadership wanted it gone. Too old. Too risky. Time for something modern.

The replacement was supposed to solve those problems. Instead, during its first real test under peak load, the new system crashed. The transaction volume overwhelmed it.

Meanwhile, the 15-year-old legacy system continued running flawlessly.

The old system had just demonstrated something the new system could not. And the lesson was not about better software.

The old system was not better technology

The legacy platform had survived for 15 years because the organisation around it had evolved with the system.

Processes were built around it. People understood its behaviour. Operational teams knew how to respond when something changed.

The surrounding organisation had adapted to the technology. The replacement arrived before the organisation was ready to absorb it.

So the question changed. Instead of asking, “Why did the new system fail?”, I started asking, “What made the old system reliable?”

The answer was alignment. The old technology fitted the operating environment. The new technology did not.

Technology does not operate in isolation

A technology programme is rarely a technology problem alone. A new platform enters an existing enterprise.

Existing processes. Existing roles. Existing governance. Existing data. Existing behaviours. Existing expectations.

If those elements are not ready, new technology inherits the weaknesses around it.

This is one of the hardest lessons for technology leaders to accept. We tend to look for the defect inside the system.

The code. The architecture. The infrastructure. The vendor.

Sometimes the defect sits upstream. The organisation was not ready.

The expensive lesson

The €47M failure taught me more about transformation than many successful programmes. Successful programmes often reinforce what you already believe. Failures force you to examine what you missed.

Looking back, the most important question was not, “Why did the new system crash?” It was, “Why did we believe the organisation was ready for the new system?”

Those are two very different questions. The first leads to remediation. The second leads to leadership accountability.

Readiness comes before replacement

Today, before introducing significant technology change, I look upstream.

Strategy — is the reason for the change clear? Operating Model — are roles, processes and responsibilities ready for the new capability? Governance — who owns the decisions when reality differs from the plan? Data — is the organisation working from trusted information? People & Culture — are people prepared to work differently? Technology — only then does the technology become the force multiplier it was intended to be.

This experience illustrates a principle I later formalised in my Enterprise Transformation Framework: “Technology amplifies organisational capability.”

If the organisation is ready, technology amplifies capability. If the organisation is not ready, technology amplifies the gaps.

The question I now ask

When a transformation struggles, the instinct is often to add more technology.

Another platform. Another integration. Another specialist. Another remediation programme.

Sometimes the better move is to stop. Look upstream. Ask whether the enterprise is ready to absorb the change.

The old system was not better. It was better aligned.

That distinction changed how I think about transformation. Technology is rarely the starting point. Readiness is. And leadership owns readiness.