Your ERP has been running for twelve years. Users complain at every meeting: outdated interface, patched-together integrations, laborious CSV exports. The board wants results. And the first replacement quote you received from your SAP partner exceeds eight million euros with a three-to-four-year timeline.
That is the moment most IT leaders leave the boardroom with two bad options in mind: commit to a massive migration at the wrong time, or do nothing and wait until the situation becomes unbearable.
There is a third path. This article outlines five concrete strategies for modernizing a legacy ERP without a full replacement, with estimated costs, limitations, and conditions of applicability for each.
Why Replacing Your ERP Is Not Always the Right Answer
The True Cost of an ERP Replacement
The total cost of an ERP project is consistently underestimated at the quoting stage. Panorama Consulting’s 2024 ERP Report places total implementation costs between 3% and 6% of annual revenue, inclusive of all charges (licences, integration, training, transitional productivity loss, change management). For a mid-market company with £150 million in annual revenue, that represents £4.5 to £9 million. For a company at £400 million, £12 to £24 million.
Actual timelines range from two to five years for a full scope. These are not cautious consultant estimates: they reflect structural delays caused by data quality issues, organizational trade-offs, and in-flight scope changes.
The most documented example is Lidl. Between 2011 and 2018, the German retailer invested close to €500 million in an SAP project called eLWIS, before abandoning it and returning to its legacy system. The root cause: Lidl managed inventory at purchase price, while SAP natively operated on selling price. Rather than adapting its processes to the ERP standard, Lidl tried to force the software to replicate its existing practices, accumulating an insurmountable customization debt.
This case illustrates a broader reality: the risk of ERP project failure is not linked to software quality, but to the gap between the actual complexity of the existing system and the assumptions built into the replacement project.
When Partial Modernization Is Preferable to Full Migration
Partial modernization is relevant in three specific situations.
Stable core processes. Your general ledger, procurement, and logistics have been running reliably for ten years. The problem is not in the transactional core, but in the outdated user interface, the lack of modern integrations, or the on-premise infrastructure running on ageing hardware. Replacing the ERP to solve these peripheral problems is like replumbing an entire building because a tap is dripping.
Short-term blocking constraints. Budget constrained by an ongoing acquisition, IT resources absorbed by another programme, an imminent regulatory deadline, or a post-merger integration phase. In these contexts, simultaneously launching a multi-year ERP project creates disproportionate operational risk.
Team resources insufficient for a full project. A replacement ERP project absorbs an average of 15–20% of business team time over two to three years. For a company with 200 employees and an IT team of five, this is structurally unfeasible without significant impact on day-to-day operations.
Warning Signs: When You Really Must Migrate
Partial modernization has its limits. Three situations justify committing to full migration despite the cost.
Confirmed end of vendor support. SAP has announced the end of mainstream maintenance for SAP ECC 6.0 (Enhancement Packages 6–8) on 31 December 2027, with no further extension. Extended maintenance is available until 2030 for a paid option, but it covers neither new functionality nor non-security fixes. Remaining on SAP ECC after 2030 without vendor support exposes the organization to uncovered security risks.
Technical impossibility of integration. If your ERP has no API layer and the only ways to extract data are direct database queries or flat file exports, peripheral modernization reaches its structural limits. Grafting modern tools onto a system with no integration layer is building on sand.
Data model incompatible with new business models. Multi-channel e-commerce, marketplace, subscription-based sales: if your ERP was designed for a single sales model and cannot accommodate a second model without a deep database redesign, partial modernization is insufficient.
Strategy 1: API Wrapping — Building a Modern Service Facade Around Your ERP
The Principle
API wrapping exposes the data and processes of the existing ERP through a REST or GraphQL API layer, without modifying the core application. Third-party systems (CRM, e-commerce, BI, HR) communicate with this facade rather than accessing the database directly or via flat-file interfaces.
The term “wrapper” is explicit: you encase the existing system in a modern interface, without touching what is inside.
Tools and Platforms
Several integration platforms enable this layer. MuleSoft Anypoint Platform is the enterprise market reference, with broad coverage of native ERP connectors. Azure Integration Services (Logic Apps, API Management, Service Bus) is relevant for organizations already in the Microsoft ecosystem. Dell Boomi and Kong cover more targeted use cases around iPaaS mid-market and API gateway management respectively.
A Concrete Use Case
A mid-market industrial company wants to connect Salesforce to its SAP ECC 6.0 so that sales reps can see real-time stock levels from the CRM. The SAP migration is not planned before 2028. The solution: deploy MuleSoft to expose SAP stock feeds as a REST API. Salesforce consumes this API. SAP ECC is not modified. Implementation timeline: 3 to 6 months. Estimated cost: £70,000 to £170,000 depending on complexity and number of entities exposed (2026 market estimate, including licences and services).
Limitations to Anticipate
API wrapping does not resolve performance issues in the underlying ERP, nor does it address data quality problems. If the ERP database contains inconsistent or redundant data structures, the API facade will expose those inconsistencies. This strategy is an integration solution, not a data-cleansing solution.
Estimated cost: £45,000 to £260,000 depending on complexity and number of flows (2026 market estimate).
Strategy 2: User Interface Modernization
The Principle
The most frequently cited complaint from legacy ERP users is the interface: unintuitive navigation, cluttered screens, no mobile version, excessive loading times. UI modernization replaces the frontend without touching the transactional backend.
This is a deliberate decoupling between the presentation layer and the application layer.
Available Solutions
SAP Fiori is SAP’s UI framework, deployable on SAP ECC without migrating to S/4HANA. It enables a redesign of the most frequently used transactions with a modern, responsive UX. Note: Fiori is available only for a subset of ECC transactions, not the entire system.
Mendix and OutSystems are low-code platforms that allow the construction of custom business interfaces connected to the ERP via API or native connector. They are particularly suited to company-specific processes not covered by standard ERP functionality.
Microsoft Power Apps offers a cost-effective option for organizations already in the Microsoft 365 ecosystem, with native connectors to Dynamics 365 and third-party connectors to SAP or Oracle.
Expected Results and Limitations
Field feedback from UI modernization projects consistently points to significant improvement in adoption rates and a reduction in support tickets related to navigation. The impact on process handling times is more variable: a modernized interface does not accelerate a poorly configured workflow.
The main limitation is structural: UI modernization does not resolve backend performance issues, data quality problems, or rigidity in the data model. If the ERP takes 30 seconds to calculate a cost price, a new interface will not change that.
Estimated cost: £25,000 to £130,000 depending on the redesign scope (2026 market estimate).
Strategy 3: Partial Migration in Hybrid Mode
The Principle
Hybrid migration involves keeping the production core in the legacy ERP while migrating to a new system the modules with the highest ROI or the greatest regulatory risk. The two instances coexist during a deliberately planned transition period.
A Concrete Example
A 300-employee pharmaceutical company uses SAP ECC for all its processes. EMA regulatory pressure imposes strengthened accounting and financial traceability from 2027. Migrating the full scope in 18 months is not realistic. The decision: migrate the Finance and Controlling module to S/4HANA Public Cloud while keeping production and logistics on ECC for an additional two years. A data exchange interface synchronizes the two systems on inter-module flows.
The Double-Maintenance Challenge
This operating mode generates a non-negligible coordination cost: two active licences, two support teams, two update cycles, and an exchange interface to maintain. This operational overhead must be factored into the profitability calculation from the decision stage.
Hybrid migration is viable when the target module has strong functional autonomy (Finance, HR, CRM) and when the synchronization interfaces between the two systems are limited in number and complexity. It becomes counterproductive when modules are highly interdependent — for example, Production with Procurement with Logistics in a lean flow context.
Estimated cost: £175,000 to £700,000 for the first phase (partial licences, integration, synchronization), depending on the module migrated and the vendor (2026 market estimate).
Strategy 4: Enrichment Through Complementary Cloud Modules (Best-of-Breed)
The Principle
Rather than replacing the ERP, you add specialized cloud modules to cover the most critical functional gaps. The ERP core continues to handle fundamental transactional processes, while third-party tools take charge of the areas where the legacy ERP is most behind.
Practical Examples
Common use cases in mid-market companies:
- Business Intelligence: connecting Power BI or Tableau to the ERP to replace manual Excel exports with real-time dashboards. Implementation timeline: 2 to 4 months. Cost: £13,000 to £52,000.
- HR and payroll management: adding Sage HR, Access People, or Factorial to an ERP that handles payroll or time management unsatisfactorily, without touching the financial core.
- E-commerce: connecting Shopify or WooCommerce to the ERP via a connector (Boomi, Zapier, or native connector) to manage online orders without migrating stock management.
- Document management: implementing M-Files or DocuWare to digitize contract and invoice management without touching the accounting ERP.
The Risk of Application Layer Sprawl
The main risk of this strategy is uncontrolled accumulation of third-party solutions. Each additional module generates a coordination cost (integration, connector maintenance, training) and a risk of data divergence between systems. The rule of thumb: beyond four or five active third-party modules orbiting a legacy ERP, the total coordination cost begins to outweigh the benefits of functional specialization.
Before each third-party module addition, ask explicitly: is this a permanent functional gap in the ERP, or a configuration or training problem? The answer fundamentally changes the decision.
Strategy 5: Lift-and-Shift and Infrastructure Modernization
The Principle
Lift-and-shift involves migrating the existing ERP application, unmodified, to cloud infrastructure or modernized virtualized servers. The application remains strictly identical. Only the infrastructure changes.
This strategy is often the first step in a longer modernization programme, as it frees the organization from the constraints of ageing hardware and end-of-life data centres, without committing to an application migration.
Differences Between Infrastructure Approaches
It is useful to distinguish three levels of transformation:
- Lift-and-shift: the application is copied as-is to the cloud (VM migration to EC2 or Azure Virtual Machines). No application change.
- Replatforming: the application is lightly adapted to benefit from managed cloud services (managed databases, object storage), without code refactoring.
- Refactoring: the application is rearchitected to become cloud-native. Applicable primarily to in-house developed applications.
For a packaged ERP, lift-and-shift or light replatforming are the only relevant options. Refactoring a packaged ERP is outside the client’s scope.
Expected Benefits
The benefits of a well-executed lift-and-shift are concrete: elimination of hardware and data centre maintenance costs, improved availability (cloud SLA versus self-managed on-premise infrastructure), and scaling flexibility. An ERP running on out-of-warranty servers with 99% uptime can reach 99.9% on cloud infrastructure at the same or lower hardware cost.
Major cloud providers offer dedicated migration tooling: AWS Migration Hub, Azure Migrate, and Google Cloud VMware Engine allow migration planning and execution with controlled risk.
Estimated cost: £35,000 to £175,000 depending on infrastructure size and level of cloud provider support (2026 market estimate).
Decision Matrix: Which Strategy for Which Context
The table below synthesizes the five strategies across four operational criteria.
| Strategy | Indicative budget | Implementation timeline | Technical complexity | Viability horizon |
|---|---|---|---|---|
| API wrapping | £45K–£260K | 3 to 9 months | Medium | 3 to 7 years |
| UI modernization | £25K–£130K | 2 to 6 months | Low to medium | 3 to 5 years |
| Hybrid migration | £175K–£700K | 12 to 24 months | High | 5 to 10 years |
| Modular best-of-breed | £13K–£130K per module | 1 to 4 months per module | Low to medium | 2 to 5 years per module |
| Infrastructure lift-and-shift | £35K–£175K | 2 to 6 months | Low | 4 to 8 years |
Quick read: if your main constraint is budget and urgency, start with lift-and-shift or API wrapping. If the problem is user adoption, prioritize UI modernization. If regulatory pressure affects a specific module, hybrid migration is the most targeted approach. If functional gaps are spread across several domains, modular best-of-breed offers the most granular flexibility.
These strategies are not mutually exclusive. The most common sequence in companies with 200 to 800 employees combines lift-and-shift (stabilize the infrastructure), then API wrapping (open up the system), then UI modernization (improve adoption), over an 18-to-36-month horizon, before undertaking a full migration under better conditions.
Further Reading
To structure the decision between partial modernization and full replacement, our legacy ERP decommissioning guide in 8 steps details the criteria that justify moving permanently to a new system, with a module-by-module qualification checklist.
If your context involves a major version upgrade within the same vendor ecosystem — particularly SAP S/4HANA — our major ERP upgrade methodology covers the preparation phases, customization management, and risk factors to neutralize before go-live.
If the infrastructure question arises in the context of a lift-and-shift, our analysis of cloud ERP repatriation to on-premise helps you evaluate rollback scenarios and the economic conditions under which an on-premise return makes sense.
Download our ERP evaluation grid to benchmark your situation across 30 criteria: current system maturity, regulatory pressure, available resources, and modernization options. A 100-point decision tool designed to structure the conversation with your executive team before signing a quote.
