The bottom line
Cloud and AI have inverted the ERP mandate: you can no longer customize the core freely, and a heavily modified estate is now a barrier to consuming the vendor's embedded AI rather than just a maintenance cost.
A field guide for IT leaders deciding how much of their next ERP to customize — and how much to leave alone.
The views below are my own, drawn from two decades in the ERP ecosystem and from public vendor documentation and analyst research. Vendors and integrators would frame parts of this differently, and I welcome that conversation.
The mandate quietly inverted
For most of the last twenty years the CIO's marching order was "align IT with the business." Inside an ERP program that translated into a willingness to bend the software until it matched the organization's historical workflows — the model variously called Fit-to-Requirements or Fit-to-Gap. If the business wanted a square peg, IT chiseled the round hole until it fit.
The bill for that approach is now visible on most balance sheets as a calcified monolith: an ERP so heavily modified that upgrades become multi-year capital projects, every regulatory patch triggers a regression-testing marathon, and operational data sits in proprietary tables that modern analytics and AI tooling cannot read cleanly.
Cloud delivery and the arrival of usable AI have reversed the mandate. The new question is not how to adapt the software to the business; it is how much of the business to adapt to the standard. That model is Fit-to-Standard, and for anyone running a customized SAP ECC, Oracle E-Business Suite, or comparable legacy estate, the shift is not academic — it determines whether your next decade of ERP spend buys capability or just maintenance.
An honest autopsy of Fit-to-Requirements
The traditional on-premise method began with a blueprinting phase. Consultants asked process owners how they wanted to handle, say, an invoice. Users described their current routine — a blend of genuine business logic and habit accumulated over years of mainframes and spreadsheets. IT then ran a gap analysis and, wherever the software disagreed with the user, wrote custom code: the familiar RICEFW objects (reports, interfaces, conversions, enhancements, forms, workflows).
Day-one user comfort came at the cost of compounding technical debt. Two patterns recur in nearly every legacy estate I have reviewed:
- Tangled logic. Decades of modifications produce architectures where a change to a pricing routine can silently break a shipping notification. Analyst reviews of legacy SAP environments have reported that a large share of custom objects — commonly cited around 60 to 70 percent — are rarely or never executed yet still demand maintenance and testing. Treat those figures as research estimates, not a fact about your estate, until your own usage analysis confirms them.
- The innovation freeze. The steepest cost is strategic, not financial. Because upgrades hurt, organizations stop performing them and strand themselves on software that is five, ten, or fifteen years old. While competitors deploy AI-driven forecasting and real-time inventory visibility, running 2010-era logic becomes a quiet competitive disadvantage.
What changes under Fit-to-Standard
Moving to SaaS ERP — S/4HANA Cloud, Oracle Fusion Cloud, Workday — alters the physics of deployment. In a multi-tenant environment you generally cannot touch the core source code, and every tenant consumes the vendor's quarterly or semi-annual updates on the same schedule. That constraint forces a different methodology, and with it a different definition of the word "gap."
In the old world a gap was a deficiency in the software. Under Fit-to-Standard a gap is treated as a deficiency in the process, on the premise that software embodying the codified practices of thousands of peers is probably more efficient than a single company's legacy routine.
The mechanics reinforce the mindset. Instead of a blank whiteboard, these projects start from a preconfigured model company loaded with standard workflows. The consultant demonstrates the standard process and asks a pointed question: is there a legal or fiscal reason you cannot use this? That inverts the burden of proof. Previously IT had to prove the standard worked; now the business has to prove it fails. A deviation has to clear a real bar — it generates revenue, or it satisfies a regulatory mandate. "Convenience" and "we have always done it this way" stop qualifying.
The clean core is now an AI prerequisite
The most durable argument for standardization is no longer maintenance cost; it is artificial intelligence. Generative and machine-learning models depend on consistent, structured data, and the vendors train their models against their own standard data model.
That creates two consequences worth planning around:
- The customization penalty. If you have replaced standard fields with custom tables — SAP's Z-tables are the canonical example — the vendor's embedded AI is far less likely to interpret your data correctly without remediation.
- The capability gap. Estates with clean, unmodified cores can switch on new AI features close to the moment vendors ship them. Heavily customized cores get locked out until they fund data-remediation work to make custom structures legible to standard tooling.
A clean core, in other words, has graduated from an IT convenience to a precondition for business intelligence.
Standardize the core, differentiate at the edge
The reasonable objection from business leaders is that if everyone runs identical processes, no one competes on them. The resolution is composable architecture — segmenting processes ruthlessly into two buckets and treating them differently.
Systems of record — standardize. Accounts payable, general ledger, payroll, indirect procurement. No customer chooses you because you process vendor invoices more idiosyncratically than your rival. Adopt the SaaS standard at full strength and pursue touchless efficiency through configuration, not code.
Systems of differentiation — extend. The processes where you actually win: a logistics firm's routing algorithm, a retailer's allocation logic. Here the move is not to modify the ERP core but to build side-by-side extensions on a platform layer — SAP Business Technology Platform, Oracle Cloud Infrastructure, or equivalent.
The architecture is the point. The core stays clean and upgradeable; the differentiated logic lives outside it and talks to it through stable, published APIs. A chemical maker that needs density-based pricing does not rewrite the ERP pricing engine — it builds a density-pricing app on the platform layer, lets the ERP hand it order data via API, and takes the calculated price back. The core upgrades on the vendor's cadence because it was never touched, and the custom app survives because the interface stayed stable.
The financial case, with the hidden costs named
Fit-to-Standard reshapes total cost of ownership, and the effect compounds over time rather than appearing as a one-off saving.
- Upgrade avoidance. A major legacy upgrade could run 30 to 50 percent of the original implementation fee and disrupt operations for months. On standard SaaS that recurring cost trends toward zero.
- Speed to value. Configuring prebuilt processes instead of writing code pulls implementation timelines from years down to months.
- Documented ROI. A Forrester Total Economic Impact study of SAP S/4HANA public cloud reported a 273 percent three-year ROI for the Fit-to-Standard approach, driven mainly by implementation speed and avoided legacy maintenance. That is a vendor-commissioned figure — useful as a directional signal, not a forecast for your estate.
Two costs tend to hide inside the business case. Side-by-side extensions consume their own platform credits, and "chatty" apps making thousands of API calls can run up consumption charges if the integration is not designed with restraint. And the money saved on developers has to be reinvested into organizational change management, because the hard part is not technical.
Adopt, do not adapt
The real barrier to Fit-to-Standard is psychology. Users defend legacy screens and buttons and describe processes as "critical" when they are merely habitual. Two governance moves do most of the work.
First, stand up a change-control board with genuine C-level backing, operating on a simple rule: standard is the default, and customization requires executive approval. The most effective tactic I have seen is to attach a price to every deviation — show the requesting department the five-year cost of the custom feature across development, maintenance, testing, and upgrade risk, and ask whether that button is worth, say, fifty thousand dollars against their own budget. Most requests evaporate when the cost is made concrete.
Second, shift change management from training to education — from how to press the buttons to why the standard is being adopted at all. The honest narrative is that standardization removes administrative drudgery so people can spend their time on work that actually moves the business.
A practical action plan
The path is clear even where it is uncomfortable:
- Audit the custom code. Run a usage analysis and identify the objects that no one executes; mark them for retirement rather than carrying them through the migration.
- Segment the processes. Decide explicitly which areas are commodity (Fit-to-Standard) and which are differentiating (extend at the edge), before any implementation begins.
- Establish governance first. Form the change-control board now and start socializing the clean-core philosophy ahead of the project, not during it.
- Use AI as the lever. Frame the standardization case around the impending AI wave — a customized core is a barrier to adoption, and that argument lands with business leaders in a way maintenance economics never have.
The era of building bespoke ERPs is closing. The era of composing intelligent enterprises around a clean core has begun, and the advantage will accrue to organizations that consume the standard cleanly and reserve their engineering for the places where it differentiates them.
Analysis by Ravi Madhavan. Originally published on LinkedIn. Allari runs the ERP support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — keeping the core clean, the extensions stable, and the repeatable work visible for automation.
