The replace vs extend ERP question is almost always asked in the wrong terms. The system is eight years old, the interface looks dated, three people have said it is holding the business back, a vendor has demonstrated something better, and the discussion becomes a referendum on whether the current system is good. That framing produces expensive decisions, because age and satisfaction are poor predictors of whether replacement is necessary and excellent predictors of whether somebody wants it. There is a narrower test that survives contact with a board. Does the data model still fit the business. Everything else, the interface, the reporting, the missing features, the integrations, is addressable without a replacement. A data model that cannot represent how the business now works is not addressable at all, and every workaround built on top of it makes the eventual correction more expensive.
What data model fit actually means
The question is whether the thing the business needs to do can be expressed using the system's core objects, or whether it requires a parallel structure maintained alongside them. A few examples of genuine model failure, as opposed to inconvenience. A business that has added recurring revenue to a system built for one-off sales, and now tracks contracts, renewals and deferred revenue in a spreadsheet that finance reconciles monthly. A group that has acquired entities in three countries and cannot consolidate without a manual mapping because the chart of accounts and the entity structure were designed for one company. A manufacturer that has moved to configurable products and is maintaining item codes for every variant, with the combinatorics now in the tens of thousands. A services business that needs to report profitability by project and engagement when the system's only meaningful dimension is cost centre. In each case the tell is the same: an important dimension of the business exists nowhere in the system of record, and is kept alive by people. If you want a quick diagnostic, ask finance and operations which spreadsheets they would have to rebuild if they lost them tomorrow. Each one is a dimension the model is missing, and the count is your answer. By contrast, poor reports, an ugly interface, weak mobile access, missing approval workflow and absent supplier portals are all real problems and none of them are model problems. They are addressable with reporting tools, front ends and adjacent applications, at a fraction of replacement cost and risk.
The other three questions
Model fit decides most cases. Three further questions decide the rest. Can the platform keep up with statutory change? Tax regimes, reporting formats and e-invoicing requirements now arrive on a regulator's timetable rather than yours. A system where each change is a bespoke development, rather than a vendor-delivered update, has a ceiling that is not about functionality at all. This is the question most likely to force a decision you did not plan. Is it supportable? Vendor support horizon, the availability of people who know the version, and whether the underlying infrastructure is still patched. That last one is unusually live this year, with both the database and server platform generation that a great many mid-market ERP installations run on reaching end of support during 2019 and early next year. An unsupported operating system beneath a functioning ERP is a security decision masquerading as an IT chore, and it has forced more modernisation programmes this year than any vendor campaign. Can it absorb change at the rate you need? Not whether a change is possible, but how long each one takes and what it breaks. Where every modification requires the original implementer, a six-week lead time and a full regression cycle, the business will route around the system, and the shadow estate that results is the real cost.
The option nobody puts on the slide
The debate is usually framed as two choices. There are four, and the two in the middle are where most of the value sits. Extend, meaning keep the core and add capability around it. Re-implement on the same product, meaning keep the vendor and the licences and rebuild the configuration cleanly, which is frequently the cheapest route out of accumulated customisation debt and is rarely proposed because it is nobody's sales opportunity. Hollow out, meaning keep the ledger where it is and move the capabilities that are failing into specialist products connected to it. And replace, meaning a new core, new data model, full migration. Re-implementation on the same product deserves more consideration than it gets. When the model is sound and the problem is a decade of configuration decisions taken under time pressure, a clean rebuild delivers most of the benefit of replacement, retains the skills you have, and removes the largest risk in any programme, which is that the new system is learned by everyone at once.
| Option | What changes | Evidence to review |
|---|---|---|
| Extend | Add capability around the retained core | Model fit and adjacent integration constraints |
| Re-implement | Rebuild configuration on the same product | Configuration debt, retained support and migration needs |
| Hollow out | Move selected capabilities to specialist products | Ledger continuity and connected-system ownership |
| Replace | Move to a new core and model | Broken flows, migration scope and operational capacity |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for a Replace or Extend Assessment
- Start with the spreadsheet inventory. The spreadsheets finance and operations could not live without are the map of what the data model does not hold. Nothing else diagnoses model fit as quickly.
- Write down the two or three flows that actually break. Not a requirements catalogue. The specific processes that fail today, with volumes and consequences. If a replacement would not fix those, it is not the right project.
- Price all four options, including re-implementation on the same product. A comparison with only two columns is a decision already taken.
- Separate the infrastructure decision from the application decision. An unsupported server is urgent and can be solved by rehosting. Letting it force a two-year application programme is how urgency becomes expense.
- Test the statutory ceiling explicitly. Ask the vendor and the partner how the last three regulatory changes were delivered and how long each took. That history predicts the next one.
- Count the customisations and classify them. How many exist, which are still used, which duplicate standard functionality that has since been released, and which the vendor would refuse to support. Most estates find a third of their custom code is dead.
- Be honest about organisational capacity. A replacement consumes your best operational people for the better part of two years. If the business is also opening a market or integrating an acquisition, the answer is extend, regardless of the model verdict.
- Whatever you choose, fix the process first. A replacement that automates the current process reproduces the current problems on a newer database, which is the most common and most expensive failure mode in this category.
The Regional Angle
The most frequent trigger for this decision in the Gulf right now is not age. It is Saudi expansion. A group whose system was configured for UAE operations wins work or opens an entity across the border and discovers that the requirements are not a configuration variant: Arabic documentation, a separate tax registration and filing, social insurance contributions, nationalisation reporting, in-Kingdom preferences for where systems are hosted, and a customer base that expects locally compliant invoicing. Whether that is an extension or a replacement depends entirely on whether the existing model can carry a second country properly, and a surprising number of regional instances were built as single-country systems with a country field bolted on. The localisation question has a second edge here that global frameworks miss. In many regional implementations, the statutory features are not vendor functionality at all. They are partner-built extensions: the payroll file format, the gratuity calculation, the Arabic invoice layout, the tax report. That matters for this decision because "extend" in such an estate means extending code the software vendor does not support, written by a partner you may not keep, against a regulatory target that moves. Before choosing to extend, establish precisely which of your statutory features are vendor-maintained and which are somebody's custom development, because the answer changes the risk profile of the cheaper option considerably. Speed of business model change is the third regional factor. Groups here create entities for a single tender, enter joint ventures with mandated structures, and diversify into adjacent sectors faster than most mature markets, which means data model fit degrades faster too. A model that comfortably held the business three years ago may now be carrying four entity types it was never designed for. That argues for choosing systems with generous entity, currency and dimension handling even when today's requirement looks simple, because the requirement here does not stay simple. Finally, the politics. A very large share of regional ERP estates were selected by an executive who has since left, and the current leadership inherited both the system and an opinion about it. Replacement proposals in that context are often about authorship rather than architecture. The spreadsheet inventory and the two-or-three-flows exercise are useful precisely because they move the conversation onto evidence that is hard to argue with in either direction.
The objection worth taking seriously
The objection is that frameworks like this one are decoration. The decision is made by whoever has the budget and the conviction, usually a new finance or technology leader within eighteen months of arriving, and the assessment is commissioned afterwards to support it. Consultants know this, which is why the frameworks are always structured to make replacement defensible. The harder version questions the premise rather than the motives. Data model fit sounds rigorous and is difficult to falsify: a sufficiently determined analyst can present almost any estate as either fundamentally sound or fundamentally broken, because every system has workarounds and every business has changed since implementation. Meanwhile the evidence on replacement outcomes is not encouraging. A large share of programmes deliver a newer system running the same processes, with the same spreadsheets rebuilt within a year, because nobody had the authority to change how the work is done and the software was never the binding constraint. That last point is the strongest argument in the whole debate, and it is an argument for a narrower decision rather than a different one. If the honest answer is that the process is the problem and the system merely hosts it, replacing the system will not help and will cost two years of organisational attention. The test that survives this objection is the concrete one: name the flows that break, show why the current model cannot represent them, and state what would have to change in the business regardless of the software. If that document cannot be written in three pages, the answer is extend, and the money is better spent elsewhere.
Common Questions
How old is too old?
Age is not the variable. Systems well over a decade old run substantial businesses perfectly well where the model fits, the platform is supported and statutory change can be absorbed. Systems four years old get replaced when the business they were configured for no longer exists.
Is heavy customisation a reason to replace?
It is a reason to re-implement, which is not the same thing. Where the underlying model is sound and the problem is accumulated modification, a clean rebuild on the same product typically costs far less than a new platform and carries much less change risk.
Our infrastructure is going out of support. Does that force a replacement?
No, and conflating the two is expensive. Rehosting or upgrading the platform beneath an otherwise adequate application is a contained project with a hard deadline. Use it to buy time for the application decision rather than letting it set the scope.
What should we expect over the next twelve months?
Expect the end of support for a widely deployed database and server generation to force infrastructure decisions across the mid-market this year, with application decisions dragged along behind them. Expect the 2025 maintenance horizon on the previous large-suite generation to keep compressing timelines and, with it, to tighten partner capacity and raise day rates. Expect the announced Gulf cloud regions to change the hosting calculus once they open. And expect regulators in the region to keep adding reporting requirements, which will continue to be the quiet forcing function behind more of these decisions than anyone puts in the business case.
Replace or Extend Assessment — we test whether your data model still fits the business, price all four options rather than the usual two, and tell you plainly when the cheapest answer is to leave the system alone.