Before You Replace Your ERP, Consider This

Deciding to replace your ERP because something isn't working is a bit like calling in a full kitchen renovation because the oven's playing up. Sometimes the kitchen genuinely needs to go. More often than not, it just needs someone to work out what's actually broken before anyone picks up a sledgehammer.

It's almost always framed as a technology question

The conversation that leads to an ERP replacement tends to follow a familiar pattern. Something isn't working, the teams are frustrated, and someone with a budget decides the system is the problem. From that point, it becomes almost entirely technical, and the more important question, whether replacing the system will actually fix what's wrong, tends to get skipped entirely.

That matters because the people making the decision and the people living with it are rarely the same people. Leadership sees the business case, but the people using the system every day know where the friction really is, which workarounds have become essential and which processes were built around the system's limitations rather than how the business actually works. Getting both perspectives into the same conversation before anything is decided is usually where the real answers are.

The real cost runs in both directions

There is a genuine cost to staying with a system that has run its course, and it tends to creep up rather than announce itself. Technical debt grows at around 20% a year if left unaddressed, which means something that feels manageable today can become a proper headache sooner than expected. Nearly a third of businesses surveyed in 2024 found that up to 25% of their legacy systems couldn't support AI tools and workloads. In regulated environments like pharma, where data integrity and compliance reporting come with the territory, that kind of gap has a way of becoming urgent fairly quickly.

But the cost of replacing something that didn't need replacing is just as real, and a good deal harder to recover from. ERP implementations take longer and cost more than anyone plans for, and if the underlying problem was never properly understood, the new system tends to inherit the same issues in a slightly different environment, the workarounds come back, the teams build around them, and eighteen months later, the conversation starts again.

Five things worth working out before the conversation goes any further

Has the system ever been properly configured for the way the business works now, rather than the way it worked at implementation? It sounds like a basic question, and it is, but the answer is often more surprising than people expect.

Who actually uses the system day to day, and have they been asked what's working and what isn't? The people closest to the friction tend to know exactly where it's coming from, and they're rarely the ones in the room when the replacement decision gets made.

Is the reporting problem coming from the ERP itself, or from something that was added above it later and has never quite worked properly? These are very different problems with very different solutions.

Are the gaps between systems causing more day-to-day difficulty than the systems themselves? Integration problems can look like ERP problems right up until someone maps out where the data actually breaks down.

And perhaps most usefully: if the ERP were replaced tomorrow, would the processes around it be ready for something new, or would they recreate the same difficulties in a different environment?

Where Verasseti comes in

James Percy has spent 33 years delivering software projects, and the most expensive ones are almost never about building something new. They're about unpicking something that was built to solve a problem nobody quite understood at the start, and that distinction tends to become clear very early in the conversation if you ask the right things.

Before we recommend anything, we start with the business, what it's trying to achieve, where it's slowing down, and what good actually looks like for the people relying on these systems every day. Sometimes that conversation ends with a clear case for replacement, and sometimes it ends somewhere considerably less disruptive and less expensive, but either way, the place to start is always the same: understanding the real problem properly, before anyone picks up a sledgehammer.