The customization bill is coming due
For two decades, ERP customization was sold and bought as competitive advantage. Enterprises paid consultants to bend SAP, Oracle and other core systems around their existing processes rather than adapt their processes to the software, and for a long time that trade made sense: differentiated workflows supported differentiated business results. Maribel Lopez of Lopez Research put it plainly, no one arrived at today's heavily customized ERP landscape by accident, every customization was a deliberate decision that made sense at the time it was made.
That bill is now due. Mickey North Rizza of IDC frames the core problem precisely: AI agents, and agentic AI in particular, need a single trustworthy version of a business process to act on, and technical debt built up through years of customization slows AI deployment and scaling directly. A customized ERP landscape does not have one version of a process, it has as many variants as there are customized workflows layered on top of the base system, and an AI agent cannot reliably automate a process that does not have a consistent definition to begin with.
The numbers make the case
IDC data shows how stubborn the customization habit is: the share of organizations preferring a customized approach moved only from 52 percent to 51 percent between late 2024 and August 2025, essentially no change despite a year of mounting AI pressure. Meanwhile the cost of that stance is climbing. Technical debt tied to customization drives maintenance costs 49 to 60 percent higher at large enterprises, and unaddressed technical debt consumes 18 to 29 percent of AI implementation budgets before those projects produce any measurable value.
Those figures explain why roughly 80 percent of ERP transformations still miss their stated goals. James Baker of Bain and Co. notes that companies are not yet funding wholesale de-customization purely to enable AI, which means most organizations are layering new AI investment on top of the same fragile, over-customized foundation that has been producing failed transformations for years. Scott Hicar, a fractional CIO, adds a time pressure most boards underestimate: the useful shelf life of an AI investment is short given how fast the technology moves, so time spent standardizing eats directly into the window where an AI investment can still pay off.
What standardization actually looks like
Sunlight Group Energy Storage Systems offers a concrete model. The company implemented standardized S/4HANA across factories in Greece, Germany and the United States, deliberately keeping customization only where it produces genuine competitive differentiation, in Sunlight's case a B2B order entry variant configurator specific to how the company sells complex configured products. Everything else runs on the standard process, which gives AI agents a single, consistent definition of core workflows to act on across every plant.
That distinction, between customization that creates real competitive advantage and customization that simply accumulated because no one made the decision to remove it, is the practical test CIOs should apply. Angela Maragkopoulou, who led the Sunlight transformation, is blunt about how to sell it internally: do not present standardization to your board as technical cleanup, present it as the price of admission to AI. Bolt AI onto a heavily customized landscape and, in her words, you get your existing complexity, automated and scaled, which is a worse outcome than not automating at all.
The SAP HANA clock is forcing the issue anyway
Even organizations reluctant to fund standardization purely for AI face an external deadline: SAP's end-of-life timeline for older ECC systems is pushing customers toward S/4HANA migrations regardless of their AI ambitions, and the average migration now runs about 15 months. That migration is, whether framed this way internally or not, a forced opportunity to make the standardization decision that AI strategy alone has not been enough to force, and treating it purely as a compliance deadline wastes the best budget justification most CIOs will get for this work.
The risk is treating that migration purely as a technical lift-and-shift, preserving existing customizations one for one in the new environment rather than using the migration window to actually reduce them. A CIO who migrates to S/4HANA while carrying forward every legacy customization has spent 15 months and a significant budget line without solving the underlying problem IDC's research identifies, and will face the same AI deployment friction on the other side of a costly migration. The migration deadline is an opportunity to make the standardization case to the board using a forcing function that already exists, rather than waiting for a separate AI-specific budget conversation that may never get prioritized on its own merits.
How to sequence this without stalling the business
The practical sequence that emerges from these accounts starts with an honest audit: which customizations produce measurable competitive advantage today, and which persist simply because removing them was never prioritized. That audit alone typically surfaces more standardization opportunity than most CIOs expect, because customization decisions made a decade ago rarely get revisited once the original justification has expired, and the team that made the original call has often moved on without documenting why the customization existed in the first place.
From there, sequence standardization work against planned AI deployments rather than treating them as separate workstreams competing for the same budget and the same scarce implementation talent. A process targeted for AI-driven automation in the next 12 months should be standardized first, while a process with no near-term AI ambition can reasonably wait its turn in a later phase. That sequencing turns standardization from an abstract technical debt reduction project, which is genuinely hard to fund on its own, into a direct enabler of AI initiatives the business already wants funded, which is a far easier conversation to have with a skeptical finance committee.
The decision this puts on your desk
The uncomfortable finding across this research is that most CIOs already know their ERP customization is a problem, they simply have not funded the fix because it was easy to frame as deferrable technical cleanup. AI adoption removes that option, because the cost of deferring standardization now shows up directly in failed or underperforming AI projects that executives outside IT can see and measure, in a way that a quiet technical debt line item on an internal IT roadmap never did.
Bring your board a specific standardization plan tied explicitly to named AI initiatives, using Maragkopoulou's framing: this is the price of admission, not overhead. Identify the customizations that survive the differentiation test and the ones that do not, sequence the removal against your actual AI roadmap, and use any SAP HANA migration deadline you are already facing as the forcing function that gets this funded, rather than treating the deadline as a separate infrastructure line item disconnected from your AI strategy. The alternative, bolting AI onto an uncorrected customized landscape, has already produced the 80 percent failure rate this research describes, and there is no reason to expect your organization to be the exception without doing this work first, however capable your chosen AI vendor's technology turns out to be.
