Horizon LabsHorizon Labs
Back to Insights
19 Oct 2026Updated 19 Oct 20267 min read

ERP Modernisation for Manufacturers: Replatform or Integrate?

Deciding whether to replatform or integrate your ERP comes down to one test: is the pain in the core data model, or at the edges? This article applies that test to production scheduling, inventory, and finance consolidation for manufacturers.

ERP Modernisation for Manufacturers: Replatform or Integrate?

Here is the short answer: decide based on where the pain actually sits. If it is inside the ERP's core data model — the item master, bill of materials, costing method, or multi-entity handling can no longer represent how the business operates — replatforming is usually the more durable fix. If the core data model is still sound and the pain is at the edges, in how the ERP connects to scheduling, warehouse, or reporting tools, incremental integration is typically faster, cheaper, and lower risk. Everything else in this article is detail on how to apply that test to production scheduling, inventory, and finance consolidation, which are the three areas where this trade-off shows up hardest for manufacturers and distributors.

Growing Australian manufacturers and distributors tend to hit this decision at a predictable point: the ERP that ran the business well at a smaller scale starts working against it. Scheduling drifts into spreadsheets, inventory data disagrees with the warehouse floor, and finance spends days reconciling numbers across sites or entities. None of that tells you whether to replace the system or build around it on its own — you need to know whether the problem is structural or peripheral first.

What does ERP and core systems modernisation actually mean?

ERP and core systems modernisation is the process of upgrading, replacing, or re-architecting the software that runs a company's core operational and financial processes — typically production planning, inventory and warehouse management, procurement, and finance — so the system can support current scale, integrate with modern tools, and produce trustworthy data. It is not a single project type. It spans everything from a full platform replacement to a set of targeted integrations layered over an existing system, and the right answer is rarely at either extreme.

For manufacturers and distributors specifically, the core system usually sits at the centre of a web of other tools: shop-floor scheduling software, warehouse management systems, EDI connections to customers and suppliers, and increasingly, data and reporting layers that leadership relies on for decisions. Modernisation has to account for all of it, not just the ERP in isolation. This is the same lens we apply in application modernisation work more broadly — the goal is rarely a wholesale rebuild for its own sake, it is identifying which parts of the system are genuinely load-bearing and which can be modernised incrementally.

Should you replatform the legacy ERP or integrate modern systems around it?

The test is the one above: core data model, or edges. Replatforming means migrating to a new ERP platform (or a significantly re-architected version of the current one) and re-implementing core processes on it. It is a high-effort, high-disruption path, but it resolves structural limitations that integration cannot paper over. Incremental integration means leaving the core ERP in place and connecting modern systems — scheduling tools, inventory platforms, BI layers, or middleware — around it via APIs, data pipelines, or integration platforms. It reduces short-term disruption but can leave structural problems unresolved, and sometimes adds complexity by layering more systems onto an already strained core.

A useful general principle for modernisation decisions: a deeper, consultancy-led approach tends to fit best when an organisation is early in its modernisation journey or facing a genuinely cross-functional, novel challenge — situations where off-the-shelf tooling alone will not resolve the underlying architecture problem. ERP replacement for a manufacturer with custom production logic, multi-site inventory, and consolidated finance reporting is frequently exactly that kind of challenge, which is also where a clear ai product strategy pays off before any AI capability is bolted onto the new or existing system — sequencing matters as much as the platform decision itself.

How does production scheduling change the calculus?

Production scheduling is often the deciding factor, because it is the area most likely to have drifted outside the ERP entirely. If planners are already managing schedules in spreadsheets or a separate advanced planning tool because the ERP's native scheduling cannot handle the company's actual constraints — changeover times, multi-step routings, capacity across shared equipment — that is a signal the core system's production model no longer fits. That points toward replatforming or a deep re-implementation, not just a bolt-on integration.

Low-angle view from a factory floor looking up at a production planner standing beside a whiteboard covered in a hand-drawn scheduling diagram, lit by bright daylight from warehouse windows.

Conversely, if the ERP's scheduling logic is broadly adequate but lacks visibility or real-time updates, integrating a modern scheduling or MES tool via API can close the gap without a full platform change. The key question is whether the limitation is in the data model (what the system can represent) or the interface (how visible and usable that data is). The former points to replatforming; the latter points to integration.

What are the trade-offs for inventory management?

Inventory accuracy problems usually come from one of two sources: the ERP's inventory model is too simplistic for the business (no proper lot or serial tracking, no multi-warehouse logic, poor support for consignment or vendor-managed stock), or the data flowing into the ERP from the warehouse is unreliable regardless of what the ERP can theoretically support. Diagnosing which one you have matters before committing to either path — the two problems look similar from the outside but need opposite fixes.

If the ERP's inventory model is the constraint, integration alone will not fix it. A more capable WMS can mask the problem for a while, but reconciliation issues tend to resurface at month-end as volumes grow. If the issue is data capture — manual counts, delayed updates, disconnected warehouse systems — integrating a modern WMS or scanning solution with real-time sync back to the ERP is usually enough, and it is considerably less disruptive than a full ERP change. This is also where well-scoped ai engineering work can help once the underlying data is trustworthy: demand forecasting or anomaly detection on inventory data is only as good as the pipeline feeding it, which is why we always sequence data foundations before any AI layer.

How should finance consolidation factor into the decision?

Finance consolidation problems — multiple entities, multiple currencies, or multiple instances of the same ERP across sites that do not talk to each other — are a strong signal toward replatforming, because consolidation logic is usually baked into the core data model rather than sitting at the edge of the system. Middleware can move data between instances, but it generally cannot resolve mismatched chart-of-accounts structures, inconsistent costing methods, or entity-level rules that differ site to site. If finance is manually adjusting and re-keying numbers every close cycle to produce a single consolidated view, that manual effort is doing the job the ERP's core model should be doing, and integration will not remove it.

The practical approach we take with manufacturing and distribution clients is to map all three areas — scheduling, inventory, and finance — against the same data-model-versus-edges test before recommending a path. In our experience, it is rare for a company to be purely one or the other: most have a genuine structural problem in one area (often finance consolidation) alongside integration gaps elsewhere (often scheduling visibility). A combined modernisation plan that replatforms where it matters and integrates where it does not tends to be both cheaper and less disruptive than treating the whole ERP estate as one binary decision. You can find more detail on how we approach related problems in our more insights section.

If you are weighing this decision for your own operation, it is worth getting a second, independent read on where the real constraints sit before committing capital to either path. Get in touch and tell us about your challenge — we can talk through what we are seeing and whether a replatform, an integration programme, or a mix of both fits your situation.

Share

Chris Kerr

Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.