ERP Customisation: The Hidden Barrier to AI Value

ERP customisation debt is the accumulated cost of every bespoke modification made to a core enterprise system over its lifetime: custom code, altered standard processes, private tables, point-to-point interfaces and reports built around them. For most of the last two decades it was a maintenance line and an upgrade headache. In 2026 it has become something more serious, because it is now the single biggest reason an organisation cannot use the AI its ERP vendor is shipping.

Boards are being told that AI agents will reshape finance, procurement and supply chain operations. That is broadly right. What is said less often is that those agents are designed for the standard product. The more a business has bent its ERP away from standard, the less of that value it can reach, and the more it will pay to reach any of it.

Customisation was usually a rational decision

It is worth being fair to the people who made these choices. Most customisation was done for good reasons at the time: a standard process that did not fit how the business genuinely made money, a regulatory requirement the package did not cover, an acquisition that had to be absorbed quickly, or a go-live date that could not move. Each modification was individually defensible.

The problem is cumulative. Twenty years of individually defensible decisions produce an estate that nobody fully understands, where business rules live in code rather than in documentation, and where the two or three people who know why a particular routine exists are approaching retirement. The system still works. It simply cannot change quickly, and AI is a technology that rewards the ability to change quickly.

Why AI turns customisation into a board issue

Traditional automation tolerated a customised ERP because it worked at the surface. A robotic process automation bot copied what a user did on screen, so it did not much care what sat underneath. AI agents are different. They act on the business logic, the data model and the interfaces directly, and they are built and tested by vendors against the standard versions of all three.

Gartner put the risk plainly when it predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, noting that integrating agents into legacy systems can be technically complex, often disrupting workflows and requiring costly modifications (Gartner, June 2025). In a heavily customised ERP, those modifications are layered on top of modifications.

McKinsey makes the same point from the other direction. Its May 2026 analysis of AI in ERP (McKinsey) considers whether companies can leave a "good enough" legacy backbone in place and let agents build better processes on top. It concludes that this is unlikely, citing RPA as the precedent: quick wins at the edge, with the structural process and data problems left untouched in the core. Agentic AI is more capable than RPA, but it is likely to hit the same ceiling once a business needs scale, control and consistency.

For a board, the implication is simple. The AI business case and the state of the ERP core are the same conversation, not two separate ones.

Three ways customisation blocks AI value

1. Business logic an agent cannot see

An agent that proposes a credit decision, a purchase order or a stock transfer has to reason about the rules that govern it. In a standard system those rules are documented, configured and exposed through supported interfaces. In a customised one, a meaningful share of them sits in bespoke code that no vendor model has ever seen. The agent will either ignore those rules or be wrapped in so much protective integration work that the efficiency case disappears.

2. Upgrade paralysis keeps you away from where the AI ships

Vendors deliver AI capability through releases. A business that avoids upgrades because every release breaks something bespoke is, by definition, running the version with the least AI in it. The major vendors are directing their embedded AI investment at their current cloud platforms, not at releases that are a decade old. Heavy customisation is therefore not only a barrier to using AI; it is a barrier to receiving it.

3. Fragmented data meaning

Custom tables and locally redefined fields mean the same concept can carry different meanings in different parts of the estate. An AI system will reproduce that inconsistency faithfully and present the result with complete confidence. We covered this failure mode in detail in data readiness for AI; customisation is one of its most common root causes.

The deadline that compounds the problem

For many UK organisations running SAP, this is not a theoretical debate. SAP ERP 6.0 on enhancement packages 6, 7 or 8 reaches the end of mainstream maintenance on 31 December 2027. Optional extended maintenance runs to 31 December 2030, under a separate contract at additional cost, and SAP describes it as a bridge rather than a long-term alternative. Systems on enhancement packages 1 to 5 left mainstream maintenance at the end of 2025 (SAP Community).

Every customisation carried into a move to SAP S/4HANA or SAP Cloud ERP has to be analysed, remediated or rebuilt. Carry too much across and the new platform inherits the old constraints, along with a much larger bill. The same logic applies to organisations on older Microsoft Dynamics, Oracle or Infor estates facing their own platform decisions.

Clean core, and what it does not mean

The industry's answer is the clean core: keep the ERP as close to standard as possible and put genuine differentiation in extensions that sit alongside it, connected through supported interfaces, so the core can take vendor releases without breaking.

Clean core is sometimes presented as zero customisation. That is wrong, and a board should push back on anyone who sells it that way. McKinsey's framing is more useful: in ERP, the objective of most processes is standardisation, not differentiation. Invoice matching, period close and goods receipt are not where a business wins. Pricing logic, a distinctive fulfilment model or a regulated product process might be. The discipline is knowing which is which, and being honest about it.

A practical triage for your customisation estate

The most effective thing a board can commission is not a migration. It is an evidence-based classification of what already exists. We use four categories.

• Retire. Modifications that are no longer used, or that support a process, product line or entity the business no longer has. In long-lived estates this is often a substantial share, and removing them costs little.
• Return to standard. Modifications that recreate something the current standard product now does adequately. These were often justified years ago and have since been overtaken by the vendor.
• Rebuild outside the core. Logic that genuinely differentiates the business but does not need to live inside the ERP. Moving it to a supported extension layer protects the core and keeps the capability.
• Retain, deliberately. A small set of modifications that are both differentiating and inseparable from the core. These stay, with documented ownership and a known cost of carrying them through each release.

The value of this exercise is that it turns an abstract technical debt into a costed, prioritised decision the board can actually take. It also tends to shrink the scope and cost of any subsequent migration, which is why it should come before vendor-neutral ERP selection, not after.

What AI changes about the migration itself

There is good news. The same technology that exposes customisation debt is starting to reduce the cost of dealing with it. McKinsey reports that AI agents have the potential to cut the effort needed to implement ERP systems by at least 50% and halve programme duration, with emerging tools already reading custom code and mapping it to the new standard.

The caution sits in the same research. McKinsey expects change management to become the major constraint in future ERP roadmaps, because users still have to be taken along the journey. It also notes that just 25 to 35% of large technology programmes achieve their targeted EBITDA and cash-flow impact, while 65 to 80% exceed their planned budget or timeline. Faster tooling does not fix that. Making change land inside the business does, which is the principle behind our Embedded Change Model™. If a programme is already off track, the question becomes whether to recover it or write it off.

The private equity dimension

For a sponsor, a heavily customised ERP is an asset quality issue with a timeline attached. It slows the AI and automation levers in a technology value creation plan, it inflates the capital cost of any platform move inside the hold period, and it is discoverable. A buyer's technology diligence will ask how far the core has drifted from standard, what it will cost to modernise, and whether claimed AI efficiencies are real. Establishing that position early, and on your own terms, is part of technology exit readiness.

Questions the board should ask

1. How far is our ERP from standard, and does anyone have a current, evidence-based inventory of our customisations?
2. What share of those customisations is still used, and by whom?
3. Which of them genuinely differentiate us, and which simply preserve the way we used to work?
4. Which AI capabilities in our vendor's roadmap can we not adopt because of our current version or modifications?
5. What is our maintenance position and date, and what does the extended maintenance option cost?
6. Who owns the decision to retire a customisation, and is that a business owner or an IT one?

Frequently asked questions

What is ERP customisation?

ERP customisation is any change to an enterprise resource planning system beyond its standard configuration, including bespoke code, modified standard processes, custom tables, reports and interfaces. Configuration uses options the vendor provides; customisation changes or extends the product itself, and therefore has to be maintained, tested and carried through every upgrade.

Why does ERP customisation block AI value?

Vendor AI capabilities and agents are designed and tested against the standard product. Customisation hides business rules in code the AI cannot see, discourages the upgrades through which AI features are delivered, and fragments data definitions so AI outputs become unreliable. The result is higher integration cost and lower benefit.

What is a clean core ERP?

A clean core ERP keeps the central system as close to vendor standard as possible and places differentiating capability in extensions connected through supported interfaces. This allows the core to take vendor releases, including new AI features, without breaking bespoke code. It does not mean zero customisation.

When does SAP ECC support end?

For SAP ERP 6.0 on enhancement packages 6, 7 or 8, mainstream maintenance ends on 31 December 2027, with optional extended maintenance available to 31 December 2030 at additional cost. Earlier enhancement packages left mainstream maintenance at the end of 2025.

Should we remove all customisations before adopting AI?

No. The right approach is to classify them: retire what is unused, return to standard what the product now covers, rebuild differentiating logic outside the core, and deliberately retain the small set that is both differentiating and inseparable from it. Then focus AI on the processes where the core is clean enough to support it.

Can AI help reduce ERP customisation?

Yes, increasingly. Emerging tools can read custom code, map it to current standard functionality and accelerate testing and data migration. They reduce the technical effort, but they do not make the business decisions about what to keep, and they do not remove the need to take users through the change.

Talk to us

Intology is independent by construction. We implement no ERP software and take no vendor commission, so our view of what your customisation estate is costing you is not an argument for a migration or a particular platform. If your AI ambitions are running into the limits of a heavily modified ERP, or a maintenance deadline is forcing the question, our independent ERP consultancy can give the board an evidence-based triage and a clear decision. Arrange a confidential conversation with a senior consultant.