Legacy ERP Modernisation Without Migration: The Complete Guide for UK Manufacturers

Your ERP is 15–20 years old. It works. The data is solid. The financials balance. The inventory numbers are correct. But the user experience belongs to a different era. Staff complain. Customers wait on hold while someone navigates six screens to find an order status. Your management team exports spreadsheets every Monday morning because the reporting module cannot produce a usable dashboard.

The conventional answer has been: replace the whole thing. Gartner data suggests 55–75% of ERP replacement projects fail to deliver their expected outcomes — a figure that has held steady for a decade. For UK manufacturing and distribution SMEs running Sage 200, OrderWise, Business Central, Kerridge K8, or SAP Business One, the failure rate is no lower. The cost of replacement typically starts at £300,000 and frequently exceeds £1 million before hidden consultancy fees, data migration overruns, and productivity losses are factored in.

There is a better path. You can modernise your ERP without replacing it.

The modernisation landscape: four approaches

Before making a decision, it helps to understand the strategic options available. Each approach has a different risk profile, cost structure, and timeline.

1. Wrap and extend

You build a new interface layer that sits between your users and the legacy ERP. The ERP continues doing what it does well — transactions, financials, inventory logic — but users interact through a modern, role-specific interface. The ERP API or database layer feeds data to the new front-end in real time. No data moves. No business logic is duplicated. Your team never sees the old UI again for the functions you have wrapped.

Risk: Low. The ERP is untouched. Rollback means pointing users back at the old interface.

Timeline: 6–12 weeks for a focused scope (e.g. customer portal, order management dashboard, or warehouse mobile app).

2. Strangler fig pattern

Named after the strangler fig vine that gradually envelops a host tree, this approach replaces specific ERP functions one at a time. You build a new service for, say, order management or pricing. It becomes the authoritative system for that function, calling the legacy ERP as needed for data. Over months or years, the old ERP's role shrinks until it is a narrow data store or is decommissioned entirely.

Risk: Medium. Each replacement is individually low-risk, but the programme requires sustained commitment.

Timeline: 12–36 months for full strangling, depending on the number of functions replaced.

3. Overlay / interface layer

This is the approach Sysgraft specialises in. You build a purpose-built application that connects to the ERP via its API or database layer. The overlay handles all user interaction for a defined domain — a customer portal, a sales dashboard, a warehouse picking screen, a supplier collaboration platform — while the ERP handles the transactional back-end. The ERP is not modified. No customisations are applied. The interface layer is independently deployable, independently upgradeable, and entirely under your control.

Risk: Very low. No ERP changes. No data migration. No business process disruption.

Timeline: 6–12 weeks per overlay application.

4. Clean core

Popularised by SAP and increasingly adopted by Microsoft for Dynamics 365, the clean core approach means keeping the ERP as standard as possible and moving all customisation and extension outside the core. It is conceptually similar to the interface layer approach, but typically enforced by the ERP vendor's licensing or architectural mandates. It works well for organisations with modern, API-rich ERPs. It is harder to apply to genuinely legacy systems that lack modern API coverage.

Risk: Low to medium, depending on the ERP's API maturity.

Timeline: Variable. Clean core is more of an architectural principle than a project.

Why most modernisation projects fail

The data on ERP project failure is sobering, and it is worth understanding why. Gartner's most recent ERP implementation surveys consistently report that 55–75% of ERP projects fail to meet their stated objectives. The 2024 Panorama Consulting Solutions ERP Report puts the figure at 60% for implementations and over 50% for upgrades. The reasons cluster around a few predictable failure modes:

• Big-bang replacement carries disproportionate risk. Gartner data shows big-bang ERP replacements succeed only 42% of the time. Phased deployments succeed 73% of the time. The gap is stark and consistent across industries.
• Data migration is the single largest source of cost and schedule overruns. Moving 15–20 years of transactional history from one ERP to another almost always uncovers data quality issues, orphan records, and structural incompatibilities that were invisible in the source system.
• Business process re-engineering is underestimated. Every ERP replacement forces your team to adapt to the new system's way of doing things — or pay heavily for customisation to preserve existing workflows. Either way, productivity drops for months.
• User adoption fails when the new system feels foreign. Staff who have developed muscle memory in the legacy ERP resent being forced into a completely different interface for functions that worked perfectly well.

The common thread is that the most disruptive part of any ERP project is not the software, it is the change management. Modernisation without migration avoids almost all of these failure modes because it does not ask your team to unlearn what they know. It adds capability without removing anything.

The interface layer approach

The interface layer is the most direct route from a legacy user experience to a modern one, and it involves the least risk. Here is exactly how it works.

Your legacy ERP sits at the bottom of the stack, handling transactions, data storage, and business logic as it always has. Above it, an API integration layer connects to the ERP via its published API, ODBC connection, direct database views, or flat-file exchange — whatever the ERP supports. On top of that sits one or more front-end applications: a customer portal, an internal operations dashboard, a mobile warehouse app, a supplier self-service platform, or any combination.

The key properties of this architecture:

• The ERP is never modified. No customisations, no AL code, no bespoke extensions. Upgrades happen as normal. The interface layer adapts, not the other way around.
• Data stays in place. Nothing is migrated. The interface layer reads and writes through the ERP's existing data access mechanisms.
• Authentication and authorisation are handled independently. Single sign-on via Microsoft Entra ID (Azure AD) or whatever identity provider you already use. Role-based access is enforced at the interface layer, not inside the ERP.
• Each interface application is independently deployable. Build a customer portal first. Add a sales dashboard three months later. Add a warehouse app six months after that. No dependencies between applications.
• Rollback is trivial. Staff who already know the old ERP interface can continue using it. The new interface is additive — you can turn it off and the business keeps running.

The interface layer is not a theoretical architecture. It is what we build at Sysgraft, and it works across virtually every ERP we have encountered — including systems that predate any modern API.

The Strangler Fig Pattern explained

The strangler fig pattern takes a longer view. Rather than wrapping the entire user interface, you systematically replace individual ERP functions with purpose-built services. Each new service becomes the system of record for its domain, while the legacy ERP gradually shrinks in scope.

A typical strangler fig progression for a UK manufacturer might look like this:

1. Phase 1 — Replace the customer-facing order tracking and self-service portal with a standalone application connected to the ERP via API. The ERP still processes orders internally; customers interact with the new portal.
2. Phase 2 — Replace the warehouse management screens with a mobile-first picking, packing, and dispatch application. The ERP retains inventory master data; the warehouse app handles execution and writes back transactions.
3. Phase 3 — Replace pricing and quoting logic with a dedicated pricing engine that integrates with the ERP for customer and product data but applies its own business rules.
4. Phase 4 — Replace reporting and business intelligence with a dedicated analytics layer that reads from the ERP database and provides self-service dashboards.
5. Phase 5 — Replace purchasing and supplier management with a standalone procurement platform.

At each phase, the legacy ERP loses responsibility for a specific domain. It becomes a progressively narrower transaction engine. At the end of the process — typically 18–36 months — the legacy ERP either runs a small residual set of functions or is decommissioned entirely.

The advantage over a big-bang replacement is that the business never stops. Each phase is independently testable, independently deployed, and independently rolled back. User adoption happens gradually. The data stays in the ERP until the moment each new service is ready to take ownership.

Decision framework: modernise vs replace

Not every ERP should be modernised in place. Here is a framework for deciding which path fits your situation.

The decision is not binary. Many organisations start with modernisation for the highest-pain areas (customer portal, reporting, mobile access) while planning a longer-term replacement of the core ERP. That is a sensible hybrid strategy. It reduces immediate pain without foreclosing the replacement option.

ERP-by-ERP modernisation options

Each ERP system has a different set of integration options. Here is what is available for the most common platforms in UK manufacturing and distribution.

Microsoft Dynamics 365 Business Central

BC exposes a well-documented REST API covering sales orders, purchase orders, items, customers, vendors, posted invoices, warehouse entries, and more. Authentication uses OAuth 2.0 via Microsoft Entra ID. API rate limits are generous enough for real-time interface layer use. BC also supports Azure SQL database access for read-heavy reporting. This is one of the easiest ERPs to build an interface layer on top of, and the one where the case for not replacing it is strongest — the back-end is modern; the UI is the problem.

Strong API OAuth 2.0 SQL access

Sage 200

Sage 200 (both Standard and Professional) exposes a REST API via Sage 200 API, though coverage is narrower than BC. The API covers core entities: sales ledger, purchase ledger, stock items, sales orders, and invoices. For read-intensive use cases, direct SQL access to the Sage 200 database is available and reliable. Sage 200 does not support OAuth natively; API keys or SQL authentication are the standard mechanisms. The Sage 200 API has improved significantly in recent versions, but organisations on older versions (pre-2020) may need to work through ODBC or direct database access.

Moderate API SQL access Version-dependent

OrderWise

OrderWise provides a REST API (OrderWise API) that covers sales orders, stock, customers, suppliers, purchase orders, and warehouse transactions. It uses API key authentication. The API supports both read and write operations, making it feasible for customer portals, warehouse apps, and supplier portals. OrderWise also provides a .NET SDK and COM interface for deeper integration, though the REST API is the simplest route for a modern interface layer. The API has improved notably since OrderWise version 12+.

Strong API REST + SDK Version-dependent

Kerridge K8 (now Epicor Kinetic)

Kerridge K8 (Epicor Kinetic) presents a mixed picture. Modern Kinetic instances have a REST API covering sales, purchasing, inventory, and financials. Older K8 on-premise deployments — still common in UK automotive and wholesale distribution — often have no REST API at all. In those cases, the integration path goes through direct SQL database views (read-only) or the Epicor ICE framework (a proprietary integration bus). For older K8 deployments, an interface layer typically uses SQL views for data retrieval and flat-file or stored-procedure mechanisms for writes. This is achievable but requires more careful architecture than BC or OrderWise.

No API (legacy K8) SQL views only Kinetic has REST API

SAP Business One

SAP Business One exposes a SOAP web service (DI API) and a REST API via Service Layer, depending on version. The API covers the full range of business objects: sales, purchasing, inventory, financials, production. Authentication is via username/password or SSO through SAP's identity framework. On HANA-based versions, direct SQL access to the HANA database is available for reporting. Business One's Service Layer REST API (version 10.0+) is well-documented and suitable for interface layer development. Earlier versions require DI API (SOAP), which is more complex but still workable.

REST API (v10+) SOAP (older versions) HANA SQL access

Real cost comparison: modernisation vs replacement

Let us be specific about costs, using realistic figures for UK manufacturing and distribution SMEs.

The cost differential is not subtle. For the price of a full ERP replacement, you could modernise three to five different functional areas with dedicated interface layers — and still have budget left over. More importantly, you would see results in weeks, not years, and you would never risk the business continuity issues that come with a failed replacement.

These figures assume a fixed-price engagement with a specialist interface layer builder like Sysgraft. Replacement estimates assume a typical UK SI partner. Your actual costs will vary with scope, ERP complexity, and the number of integrations involved.

Frequently asked questions

Do I need to migrate my data to modernise my ERP?

No. The interface layer and strangler fig approaches both preserve your existing ERP and its data. You add a modern front-end or API layer on top, or gradually extract specific functions. Your historical data stays in place. No migration, no data transformation, no ETL scripts, no risk of data loss.

What if my legacy ERP does not have an API?

Many legacy ERPs support ODBC or direct SQL database access, flat-file exports, or screen-scraping techniques. A middleware layer can wrap these interfaces into a clean REST API. Sysgraft has done this for ERPs with no published API, including legacy versions of Kerridge K8 and Sage 200. The architecture is more complex but the outcome is the same: modern interfaces driven by live ERP data.

Does upgrading my ERP break an interface layer?

Rarely. A well-built interface layer connects to stable API endpoints or database views, not internal structures that change with upgrades. If your ERP vendor deprecates specific endpoints, the integration contract provides months of notice. Compare this to native customisations, which break on almost every upgrade and require re-validation and re-testing each time. The interface layer is independently versioned and tested against the ERP's integration contract.

Can I use the strangler fig pattern with proprietary ERP code?

Yes. New functions are built externally as standalone services that call the ERP via its API or database layer. Over time, the ERP becomes an increasingly narrow data store and transaction engine. The old UI remains available for anything not yet replaced. You never modify the ERP's proprietary source code. Your support contract and upgrade path remain unaffected.

What does ERP modernisation without migration cost?

A focused interface layer or portal starts around £30,000–£60,000 fixed-price, with a typical build timeline of 6–12 weeks. A full strangler fig programme covering multiple modules runs £100,000–£250,000 depending on scope. Compare this to a replacement ERP project at £300,000–£400,000+ with 18–36 months of disruption and a 55–75% failure rate. The economics strongly favour modernisation.

Does this approach mean I am stuck with my legacy ERP forever?

Not at all. Modernising in layers actually makes a future migration easier. Your business logic is already abstracted behind clean APIs. The interface layer is framework-agnostic. When you eventually want to replace the ERP, you swap out the back-end without rebuilding the front-end. Your users barely notice the change. Modernisation today is the best preparation for replacement tomorrow.

How long does an interface layer project take?

A discovery sprint takes 3–5 days and produces a live API audit, a technical feasibility assessment, and a fixed-price proposal. The build phase for a portal or interface layer typically takes 6–12 weeks from kick-off to go-live, depending on scope and the complexity of your ERP integration. Ongoing maintenance is minimal — a few hours per quarter for compatibility testing against ERP updates.

What are the risks of doing nothing?

Staff productivity erodes as they continue navigating outdated UIs. Customer experience suffers due to slow query responses and no self-service. Spreadsheet workarounds proliferate as staff find ways to do their jobs outside the ERP. Skilled staff get frustrated. Competitors who have modernised their interfaces win on service speed and data accessibility. Every year of inaction compounds the urgency, often leading to a rushed, high-risk full replacement that costs more and delivers less than a planned modernisation would have.

---