Modern tools, legacy thinking, expensive regrets

23 February 2026·Billy Cheung

Source: Pexels

I've lost count of how many system projects I've been part of over the years. Different sectors, different tools, different ambitions - but one question seems to appear in almost all of them:

"Can the system be tailored to follow our existing process?"

It's usually asked with the best intentions: to minimise disruption, make the transition smoother, keep everyone comfortable.
But the more projects I've seen, the more I've realised this question often marks the exact moment a transformation quietly becomes an expensive re-run.

Because once that door is opened, the project slowly shifts from "building the future" to "rebuilding yesterday".

When systems inherit old problems

Two examples come to mind - both familiar, and they illustrate the pattern perfectly.

Project 1: Replacing a CMS for a government body

A government body was investing in a modern content management system (CMS). They'd chosen a renowned platform known for its state-of-the-art capabilities.
Yet it was customised heavily to replicate a complex, multi-departmental approval chain that had evolved over the years simply because the old CMS couldn't operate any other way.
By the end, the new CMS was technically "live", but functionally, it wasn't delivering the benefits it was chosen for. In the expense of new features and efficiency improvements, it became a near-perfect rebuild of the old system.
The organisation paid for a new tool... and then asked it to work in the old ways.

Project 2: A ticketing system turned into an ERP

An organisation commissioned a ticketing system to streamline IT requests - a perfect opportunity to reduce noise and bring structure back into service management.
Instead, bespoke development was added to create a hybrid of budgeting, timesheets, and ERP-like features - not because it made operational sense, but because the organisation had long relied on Excel files and emailed PDFs to keep everything in one place, and expected the new system to do the same.
The result? A once-lightweight workflow engine became a heavy, confused product that satisfied no one.

In both cases, the pattern was the same:
the system didn't fail - it absorbed the limitations of the process that shaped it.

The irony is that the "unchangeable" workflows were never designed with intention; they were artefacts of older tools.
Yet, when given the chance to start fresh, organisations chose to preserve them.

Every system project is actually a change project

This is the part that often goes unspoken.

When an organisation buys a new platform, it thinks it's buying technology. A faster CMS. A smarter CRM. A tidier ticketing system. But beneath all of that, it's actually buying:

• new habits
• new workflows
• new responsibilities
• new expectations
• new ways of understanding work

A new system doesn't magically deliver these things. It simply creates the space for them.
And if that space is immediately filled with old patterns, then nothing really changes - except the cost and the time spent getting there.

Most "system failures" aren't failures of technology at all.
They're failures of willingness. A hesitation to question the familiar. A desire to preserve the path of least resistance. A hope that transformation will happen without having to transform the way the work is done.

And this ties back to something quite fundamental: PMBOK defines a project as a temporary endeavour created to deliver change.
If nothing changes - not the workflow, not the behaviour, not the way decisions move through the organisation - then it isn't really a project at all. It's a purchase order wrapped in a delivery plan. New tools can support change, accelerate it, or enable it, but they can't be the change. That part has always belonged to people.

Mindset makes or breaks the investment

The most effective teams I've worked with share one trait: open-mindedness.

Not the fluffy kind - the practical sort. The kind that's willing to ask:

• Why does this step exist?
• What purpose does it actually serve?
• If the old system didn't force us to do it this way, would we?
• Are we replicating a process, or are we improving it?

This mindset doesn't just make change smoother; it makes the investment worthwhile.

Because when the process is allowed to evolve, the system can finally do the job it was built to do. It can simplify. It can clarify. It can remove unnecessary friction instead of recreating it.

But when the process refuses to bend, the system becomes nothing more than an expensive container for old thinking. A shiny wrapper around an unchanged reality.

A system can only be as transformative as the process behind it. And a process can only be as effective as the mindset shaping it.

Modern tools don't create organisational change.
People do - by questioning practices that quietly limit what the organisation could achieve.

When that doesn't happen, the outcome is painfully predictable:

Modern tools.
Legacy thinking.
Expensive regrets.