Do You Need a New ERP, or Just the Data Already Inside It?

When the numbers stop keeping up with the business, the reflex is a system project. The ERP is old, half-implemented, or bent out of shape by years of workarounds — so the plan becomes: implement it properly, or buy a new one. Configure the modules. Migrate the data. Roll it out across the group. Onboard everyone. Train them. Eighteen months and a large budget later, the reporting is finally supposed to work.

Sometimes that’s the right call. More often it fixes the wrong layer.

The question worth asking first is narrower than “which ERP.” It’s this: do you need a new system, or do you need the data that’s already sitting in the ones you have?

What the heavy project actually is

A serious ERP implementation is not one project. It’s implementation, customization, data migration, rollout across entities, onboarding, and training — each with its own timeline and its own way of slipping. Gartner and McKinsey have tracked the pattern for years: large ERP and transformation programmes routinely run long and over budget, and a meaningful share never deliver what they set out to.

The disruption is the part nobody prices. For the length of the project, the finance team is running the business and rebuilding the plane at the same time. The cost in the plan is the software and the integrator. The cost that hurts is the two years of attention.

The data is almost always already there

Here’s the part the system pitch skips. The data you need to run the business almost always already exists. The sales are in the ERP or the e-shop. The costs are in accounting. The operational detail sits in the tools each department already uses.

The problem is rarely that the data doesn’t exist. It’s that it’s scattered, defined differently in each system, and never connected into one picture you can trust. That is not an ERP problem — and a new ERP does not fix it. An ERP records transactions well. It was never built to be the single, governed source of decision-useful information across a whole group. We’ve written about why your ERP doesn’t govern your data ; this is the same gap, seen from the budget side.

The other path: use what you already run

So there’s a second option, and it’s usually the one nobody put on the table. Instead of replacing the systems, you connect them. Pull the data from what you already run, standardize it to one model, govern it, and put live reporting and AI on top. The transaction systems stay exactly where they are. You add the layer that was actually missing.

It takes weeks, not years, because nothing is being re-implemented. You’re leveraging what’s already there, not rebuilding it.

Onetribe BI Demo · KPI overview Power BI

That’s the model we build at Onetribe, so I’m hardly neutral here. But the logic holds whoever does the work: fix the layer that’s broken, not the one underneath it that isn’t.

When a new system genuinely wins

The system project is sometimes exactly right, and it’s worth being honest about when:

• The transaction system itself is failing — unsupported, can’t handle the volume, or actively blocking operations. Then you fix the system, because the system is the problem.
• A regulator or auditor requires a specific platform. Compliance isn’t a preference.
• You’re consolidating after M&A and standardizing everyone onto one ERP is the actual strategy — not a reporting fix wearing a strategy’s clothes.
• You’re small and greenfield enough that implementing once, cleanly, is genuinely cheaper than integrating a few existing tools.

If one of those fits, invest in the system. Then put a governed layer on top of it anyway — because even a perfect ERP doesn’t govern data across a group.

The maths is quietly changing

Step back and there’s a bigger shift underneath all this. Heavy implementation used to be the price of good information. If you wanted decision-useful data, you bought a big system and spent two years bending it into shape. That was simply the cost of entry.

AI is changing that price. When a governed layer plus AI can turn the data you already have into live answers, the multi-year implementation stops being the default and becomes the exception.

The output layer — reports, commentary, analysis — is getting cheap. What holds value is the governed data underneath it, and how fast you can get to it.

That shift is only starting, and it deserves its own discussion — we’ll come back to it. For now the practical takeaway is the smaller one: before you price a new system, check whether the data you need is already inside the ones you have. The answer changes the budget by an order of magnitude.

Frequently Asked Questions

Does this mean we should never replace our ERP? No. If the transaction system is failing, unsupported, or blocking operations, replace it — that’s the system being the problem. The argument is narrower: don’t launch a heavy system project to fix what is actually a data and reporting gap, because a new ERP won’t close that gap anyway.

How is this different from building reporting in Power BI ourselves? That’s a separate, downstream decision — how you build the layer once you’ve decided to leverage existing data rather than replace systems. We compare the three delivery models — build, hire, adopt — on the comparison page . This article sits upstream of that: whether you need a new system at all.

Our existing ERP data is a mess. Doesn’t that argue for a clean new system? It’s the most common case, and usually not. Messy data follows you into the new system — a migration doesn’t clean it, it moves it. Governing the data you have is the work either way, and doing it on top of your current systems is far faster than re-implementing everything to get there.

Where this fits in our expertise

This is the entry point to how we think about data governance and AI readiness — the layer that makes the data you already own decision-useful, without a system project. It connects to management reporting (what you do once the numbers are trustworthy) and to why your ERP doesn’t govern your data (why the gap exists in the first place).