--- title: "Do you need to replace your ERP, or integrate with it?" url: "https://www.octalhq.com.au/insights/articles/replace-or-integrate-erp" kind: article description: "Should you replace your ERP or integrate with it? Why replacement is rarely the right first move, and how integrating around an ERP solves most problems." published: "2026-03-15T00:00:00.000Z" updated: "2026-09-26T08:13:33Z" topics: ["Integrations"] --- # Do you need to replace your ERP, or integrate with it? A big ERP is expensive to replace and disruptive to rip out — but frustrating to work around. Often the answer isn't replacement; it's integration. Here's how to decide. The short answer: replacing an ERP is expensive, disruptive and risky — so unless it's fundamentally wrong for your business, the better move is usually to integrate around it. Keep the ERP as the system of record for what it does well, and connect a system that fits your specific operation at the boundary. ## The short version - ERPs are costly and disruptive to replace — don't rush to. - Most ERP frustration is about fit at the edges, not the core. - Integrating a fitted operational system around the ERP solves most of it. - Replace only when the ERP is genuinely wrong for the business. - The decision comes from mapping where your operation fights the ERP. ## Why is replacement rarely the first answer? An ERP is deeply embedded. Finance, inventory, records, and half your processes all run through it. Ripping it out means migrating years of data, retraining everyone, and risking disruption to the whole business at once. That's a big, expensive, high-stakes project — the kind that goes wrong often enough that "we're replacing the ERP" makes seasoned operators wince. And here's the thing: the ERP's core usually isn't even the problem. The ledger works. The inventory records work. What's driving the frustration is somewhere else entirely, which means a full replacement would be a huge amount of pain to fix something the ERP was never the cause of. ## Where does the frustration actually come from? Almost always, it's the edges. The ERP is rigid exactly where your specific operation needs flexibility, so people work around it — a spreadsheet here, a manual step there, a process bent to fit the software instead of the other way round. The core (ledger, records, inventory) is fine. It's the operational fit at the boundary that hurts. That distinction is everything, because a boundary problem is an integration problem, not a replacement one. You don't need a new engine; you need the specific bit that doesn't fit to be handled by something that does, connected cleanly to the ERP. If people are holding the gaps together with spreadsheets, that's a classic sign — the same one covered in [signs your tool stack has become a tangle](/insights/articles/signs-your-tool-stack-is-a-tangle). ## What does the "integrate-around" approach look like? Keep the ERP as the system of record for what it does well, and build or connect a system that fits your operation, integrating at the boundary. In practice: - Your operational system handles the specific workflow — the part that's genuinely unique to how you run. - The ERP keeps the books, records and inventory it already manages well. - The two share data automatically, so nothing gets re-keyed between them. You get fit without the cost and risk of replacement. The ERP stops being something people fight and starts being one connected part of a stack that actually works. It's the same "keep the good core, build custom where you're different" logic we apply to [CRMs](/insights/articles/integrating-custom-software-with-crm) and [accounting software](/insights/articles/integrating-with-accounting-software). ## A worked example: the spreadsheet that runs alongside the ERP Picture a mid-sized distributor in Sydney running a well-known ERP. The finance and inventory sides work fine. But the way this business handles a particular kind of customer order — split deliveries across multiple sites, with staggered billing — is something the ERP was never built for. So the operations team runs a shared spreadsheet alongside it, tracking what the ERP can't, and re-keying between the two several times a day. That spreadsheet is the tell. It's not evidence the ERP is broken; it's evidence the ERP doesn't fit at one specific edge. Replacing the whole system to fix that edge would be enormous, risky and mostly wasted — you'd be rebuilding a working ledger and inventory engine to solve a problem confined to one workflow. The proportionate fix is to build a fitted system for that split-delivery workflow and integrate it with the ERP, so the spreadsheet — and the re-keying it forces — disappears, while the ERP keeps doing the core job it does well. ## How does the accounting and BAS side factor in? One reason not to rip out an embedded ERP lightly is that it's often wired into your financial reporting and GST position. Years of transactions, tax codes and reconciliations live there, and it may already be feeding your BAS. Migrating all of that to a new system is where big ERP replacements most often come unstuck — a data migration that mishandles historical GST or opening balances creates problems that take quarters to surface. Integrating around the ERP sidesteps that risk. The financial system of record stays put, so your GST history, your BAS trail and your accountant's familiarity with the setup all stay intact. The fitted operational system handles the workflow the ERP couldn't, and passes the financial consequences back to the ERP cleanly. You get the fit you were missing without gambling your compliance records on a wholesale switch. ## When is replacement actually the right call? Sometimes the ERP genuinely doesn't fit the business anymore. It might be the wrong scale — built for a company far bigger or smaller than you've become. It might be unsupported, or running on technology that's a risk in itself. It might be fundamentally mismatched to your industry in a way no amount of integration papers over. In those cases, replacement may well be justified. But that's a considered decision, made after ruling out integration — not the default reaction to frustration. The trap is jumping to "we need a new ERP" when what you actually need is to stop forcing your operation through the wrong part of the old one. Weighing that honestly is part of [what to keep and what to replace](/insights/articles/what-to-keep-what-to-replace-integration). ## The honest first step Deciding replace-or-integrate depends on one question: is your ERP's core sound with only the edges chafing, or is it wrong throughout? You answer it by mapping how your operation actually uses the ERP — and, just as importantly, where it fights it. That map makes the call clear, and usually shows that a targeted integration solves most of the pain for a fraction of the cost and risk of a rip-out. ## Related reading - [What to keep and what to replace: a practical integration approach](/insights/articles/what-to-keep-what-to-replace-integration) - [Integrating custom software with your CRM](/insights/articles/integrating-custom-software-with-crm) - [Integrating your business systems: the complete guide](/insights/articles/integrating-business-systems-guide) *Tell us what you run, and we'll show you what's possible.*