Before replacing your ERP, check the integration layer

Replacing an ERP is expensive, disruptive, and sometimes the right call. But before you sign up for it, take a hard look at the integration layer around the system. A lot of businesses pin the blame on the ERP for problems that actually come from missing connections, fuzzy data ownership, and years of quiet workarounds. Rip out the core system without understanding those workarounds and you’ll rebuild the same mess inside a shinier product.

Be clear-eyed about what “expensive and disruptive” means at the scale of a mid-sized Australian business, because the sales process softens it. A replacement is rarely under six figures once implementation, data migration, customisation and training are counted, and the disruption runs one to two years: months of workshops before anything changes, a cutover period where everyone runs two systems, and a long tail where staff are slower at everything while they relearn their own jobs. Industry folklore says most ERP projects run over time and budget, and our observation says the folklore is generous. None of that makes replacement wrong. It makes it a decision you want to be right about, which is why the diagnosis deserves more than a round of frustrated anecdotes.

What staff complain about

Listen to what people are actually complaining about. Are they frustrated because the ERP can’t support the process? Or because they’re forever copying ERP data into spreadsheets, reports, portals and side tools? Are approvals slow because the ERP is weak, or because nobody’s clear on the workflow around it?

The distinction sounds subtle and isn’t. “The system can’t do partial deliveries against a blanket order” is a complaint about the ERP. “I have to export to Excel to see my backorders the way I need them” is a complaint about the ring around the ERP. In the meetings where replacement decisions get made, both complaints arrive sounding identical, as “the system is useless”, and the vendor in the room has every incentive to accept that framing. Separate them and the picture usually changes. When we run this exercise with businesses, a majority of the gripes turn out to be about the connections and the workflow, not the core record-keeping, and those are problems a replacement doesn’t fix. The new ERP arrives, the same gaps exist around it, and within eighteen months the spreadsheets are back.

The answer changes where your money should go. A poor-fit ERP might need replacing. A disconnected one usually needs integration and some process repair first.

Map the satellite systems

Most ERPs sit inside a ring of other tools: CRM, ecommerce, warehouse, job management, payroll, reporting, document storage, spreadsheets, vendor portals. Any one of them might be holding data that should be wired back to the core record. Draw that map and the true source of the friction tends to show itself.

Drawing it properly is a day’s work, not a consulting engagement. Get the people who do the work, not just the managers, around a whiteboard and mark every system that holds business data, then draw an arrow for every regular movement of information between them, colour-coded: automatic, or a human retyping. The retyping arrows are the map’s payload. A distribution business we’d describe as typical found eleven of them, including one where a warehouse officer spent the first hour of every day keying the previous day’s dispatches from the warehouse tool into the ERP, and another where customer credit limits lived in the ERP but the sales team quoted from a CRM that hadn’t synced in two years. Every one of those arrows is an error source, a delay, and a queue of small resentments, and not one of them is the ERP’s fault. They’re gaps between systems, and gaps can be closed for a fraction of replacement money.

While you’re mapping, note who owns each piece of data, which system is the truth for customers, for pricing, for stock. If the answer is “depends who you ask”, you’ve found a problem no new ERP will solve, because it’s a decision, not a product feature.

Reporting is a common clue

If every report that matters needs an export and a round of manual cleanup, the ERP probably isn’t serving leadership well. But the fix might be a data layer that pulls from the ERP and the systems around it, not a wholesale replacement. A reliable reporting layer buys time, cuts errors, and gives you a clear read on whether the core system is the thing holding the business back.

There’s a diagnostic bonus here that’s easy to miss: building the reporting layer forces the data quality into the open. If the numbers coming out of the ERP are wrong, you find out whether that’s because the system stores them badly or because the processes feeding it are sloppy, and that answer is exactly what the replace-or-repair decision needs. Businesses that replace first discover the same dirty data arriving in the new system, because migration faithfully carries the mess across.

Workflow gaps can be repaired

Plenty of ERPs are bad at the human steps around the work: approvals, exceptions, notifications, document review, talking to customers. A custom workflow layer can sit alongside the ERP, handle those steps, and write clean records back into it. That’s a sensible middle path when the ERP holds important financial or operational data but the experience around it is painful.

This pattern, keep the core, rebuild the edges, is underused because nobody sells it. The ERP vendor wants to sell modules; the rival vendor wants to sell a migration. But the core of most ERPs, the ledger, stock, orders, is usually the part that works. What ages badly is the experience: clunky approval chains, no decent mobile access for the field, nothing that talks to customers. Building those edges as a layer that reads from and writes to the ERP gets you modern workflow on top of stable records, at a cost that’s typically 10 to 20% of a replacement, delivered in months rather than years, with no cutover cliff.

The same layer is where AI enters sensibly, for what it’s worth. The businesses getting value from AI around an ERP aren’t replacing the core; they’re adding capabilities at the edges, a model that reads inbound supplier documents into clean records, an assistant that answers “what did we pay for this part last year?” without anyone learning the report builder. All of it depends on the integration layer existing, which is one more reason to build it before deciding the core’s fate.

When replacement is still right

Sometimes replacement is the answer. When the ERP can’t support core operations, when the vendor risk is too high, the product’s end-of-life has been announced, the support has moved offshore and evaporated, the annual maintenance is climbing double digits, when the data model is wrong for what the business became, when integration is impossible because there’s no API and no way in, or when the cost of all those workarounds has crept past the cost of changing systems. That last one is a genuine tipping point, but it has to be calculated, not felt: add up the retyping hours, the error corrections and the workaround tools, and compare the annual figure against the amortised cost of a replacement. Feelings run hot about old systems; the spreadsheet is calmer.

Even then, map the integrations first. It gives the replacement project a sharper scope and takes the surprises out of it, because every arrow on that whiteboard is a connection the new system must support on day one, and “we didn’t know payroll pulled from that” is the classic mid-migration disaster.

Choose the smaller honest fix

A full replacement can be the brave move. It can also be a waste. A focused business systems review tells you whether integration, reporting and workflow repair would fix the actual problem, or whether you’re right to start again. Either way, spend the money on getting the diagnosis right before you spend it on the cure. If your ERP is the villain of every second meeting, tell us what it is and what surrounds it, and we’ll give you the honest read, including “keep it, wire it up properly” when that’s the truth.