ERP customization decisions — SAP, Oracle, Microsoft Dynamics D365

ERP Customization: When to Do It, When to Avoid It, and How to Decide

93% of companies customize their ERP. Most underestimate the long-term cost. The debate between business stakeholders who want the system to match their processes and IT teams who understand the upgrade consequences has been going on for decades — and it still derails implementations today.

By Donald D. Hook — Former CTO & CIO | Founder, Full On Consulting | The Villages, FL

The Tension That Never Goes Away

Every ERP implementation reaches the same moment. A business stakeholder walks into the design session and says: "Our process doesn't work that way. We need the system to do it our way."

The IT team knows what that request really means: months of custom development, years of maintenance overhead, a more complex upgrade path, and regression testing that grows with every enhancement. The business stakeholder knows what they see: a process that has worked for their team for fifteen years, and a system that doesn't match it.

Both perspectives are legitimate. The problem is that most organizations resolve this tension the wrong way — by defaulting to customization without fully accounting for its cost, or by refusing all customization without honestly evaluating whether the standard ERP process is actually better.

This insight covers what the major ERP vendors actually recommend, what the research shows about customization costs, the real-world failures caused by over-customization, and the framework your organization needs before you make these decisions.

How Big Is This Problem?

93%

of companies customize their ERP

Industry research

20–30%

of total implementation budget consumed by customization

Panorama Consulting

44%

of ERP projects experience significant cost overruns, often driven by customization scope

Gartner

Customization is not the exception — it is the norm. The question is not whether companies customize, but whether they govern the process well enough to avoid the compounding costs that follow. Most do not. The average customized ERP system accumulates technical debt that becomes unmanageable within five to seven years of go-live, precisely when the organization starts planning its next major upgrade.

What SAP, Oracle, and Microsoft Actually Recommend

All three major ERP vendors have published explicit guidance on customization. The message is consistent across all three:

SAP — Clean Core Strategy

SAP's official position is its 'Clean Core' strategy: minimize custom code in the core SAP system and use SAP Business Technology Platform (BTP) for all extensions. SAP's definition of clean core is not zero customization — it is intentional customization, limited to processes that are genuine competitive differentiators. SAP explicitly states that clean core enables faster S/4HANA upgrades, better AI adoption, and lower total cost of ownership. Before any S/4HANA migration, SAP recommends a full custom code inventory and remediation — retiring unused code and moving essential extensions to BTP.

Oracle — Configuration First

Oracle recommends a '90% standard configuration' target for Oracle Fusion Cloud ERP implementations. Oracle's guidance is to exhaust configuration options before writing any custom code, and to leverage Oracle's extension framework (Oracle APEX, Oracle Integration Cloud) for any development that is truly required. Oracle notes that heavily customized systems face regression testing costs that can increase upgrade timelines by 50% or more — a cost that compounds with every quarterly cloud update.

Microsoft Dynamics 365 — Cloud-First Limits

Microsoft D365's cloud-first architecture intentionally limits the depth of modification available. Microsoft's guidance is to use Power Platform (Power Apps, Power Automate) and the D365 extension framework for customizations rather than modifying core application code. Microsoft emphasizes that D365's update cadence — with releases every six months — makes deep core customization increasingly untenable, as each release requires re-testing and often re-coding modifications.

When Customization Goes Wrong: Real-World Failures

These are not hypothetical risks. Over-customization has contributed to some of the most expensive ERP failures in enterprise technology history.

Lidl (SAP)

The German discount retailer abandoned a €500 million SAP implementation after years of effort. The core issue: Lidl insisted on customizing SAP to handle inventory valuation using purchase prices rather than adopting SAP's standard average cost method. The customization scope spiraled beyond what was manageable.

Lesson: Refusing to adapt a core business process to the ERP standard can make an entire implementation undeliverable.

Waste Management (Oracle)

After a heavily customized Oracle ERP implementation, Waste Management sued Oracle for $500 million, alleging the system failed to perform as represented. The customization complexity contributed to performance failures and an inability to use the system for its intended purpose.

Lesson: Customization scope must be defined and governed before the implementation begins — not negotiated during delivery.

Hershey Foods (SAP)

A rushed SAP implementation with inadequate customization governance failed during peak Halloween season. Hershey was unable to process over $100 million in orders, resulting in a 19% profit drop in Q3 1999. The implementation was compressed and the customization-to-go-live timeline was unrealistic.

Lesson: Customization adds time and complexity. Compressing the timeline without reducing scope is a predictable failure path.

Haribo (SAP)

The candy manufacturer's SAP S/4HANA rollout included customizations to map its unique manufacturing workflows. When the customizations failed to translate correctly, the company could not track materials through production, contributing to a reported 25% sales decline in affected markets.

Lesson: Custom workflow mapping requires rigorous testing across every scenario before go-live — not just the happy path.

The True Cost of ERP Customization

The initial cost of a customization — typically $50,000 to $500,000 depending on complexity — is the smallest part of its total cost. IT organizations consistently underreport and business stakeholders consistently underestimate the ongoing costs:

Cost Category	When It Occurs	Typical Impact
Initial development & testing	At implementation	10–30% of total project budget
Annual maintenance	Every year	$10K–$100K per customization annually
Regression testing per release	Every upgrade/patch	50%+ longer upgrade cycles
Major upgrade remediation	Every 3–5 years	Often equals original build cost
Performance tuning	Ongoing	Variable; often hidden in IT support costs
Acquisition integration complexity	M&A events	Can double integration timeline and cost
Talent dependency	Ongoing	Limited consultant pool; premium rates

When to Customize — and When Not To

✓ Customize when:

▸

The process is a genuine, demonstrable competitive differentiator — not just a preference

▸

Regulatory or compliance requirements cannot be met through standard configuration

▸

Integration with a proprietary system has no available standard connector

▸

The cost of changing the business process to match the ERP standard is demonstrably material

▸

The customization can be built on the vendor's approved extension platform (e.g., SAP BTP) rather than modifying core code

✗ Do not customize when:

▸

The process has 'always been done this way' but has never been formally evaluated for efficiency

▸

Business stakeholders prefer the current process but cannot quantify the business impact of changing it

▸

The customization is cosmetic — reports, screen layouts, field labels — that configuration can address

▸

The ERP vendor's standard process is a recognized industry best practice

▸

The customization would modify core financials, procurement, or order management logic

▸

The implementation timeline is already compressed

▸

The organization has limited IT staff to maintain custom code post-implementation

How IT Needs to Position the Customization Conversation

IT teams often lose the customization debate not because they are wrong, but because they argue in technical terms that business stakeholders do not connect to. "This will make upgrades harder" does not land the same way as "this customization will cost the company an additional $300,000 every time we update the system."

IT needs to come to every customization discussion with:

▸

A full lifecycle cost estimate

Build cost, annual maintenance, upgrade impact, and regression testing burden — expressed in dollars over a 10-year horizon.

▸

The process change alternative

A concrete proposal for how the business process could be redesigned to conform to ERP standard — including what that change would require, what it would cost, and what the benefit would be.

▸

A risk assessment

Specifically: upgrade risk, performance risk, support risk, and acquisition integration risk. Expressed in terms of business impact, not technical impact.

▸

A governance framework

A clear process for how customization requests are reviewed, approved, prioritized, and tracked — so business stakeholders understand that the decision is not arbitrary and will be made consistently.

The Change Management Required

The deepest source of ERP customization pressure is not technology preference — it is organizational resistance to process change. Business stakeholders who request customizations are, in most cases, protecting their teams from having to learn and adapt to new ways of working. That is a legitimate concern. It is also the primary reason ERP implementations underdeliver.

Effective change management for ERP implementations requires:

Executive alignment before design begins

The CEO, CFO, and functional heads must visibly and verbally commit to the process change the ERP requires. Without this, every business unit will use customization requests as a shield against organizational change.

Business process owners — not just IT — in the design sessions

The business leaders who will live in the new system must own the process design decisions. IT's role is to facilitate and advise, not to dictate. When business owners make the process decisions, they are far more likely to accept them.

A formal change impact assessment by department

Before go-live, every affected department should receive a clear picture of what is changing, what they need to learn, and what support they will have during the transition.

A post-go-live stabilization plan

The first 90 days after go-live are the highest-risk period. A structured stabilization plan — with dedicated support, a formal issue triage process, and weekly executive check-ins — prevents small adoption problems from becoming large business disruptions.

12 Best Practices Before You Start Your ERP Initiative

📋 Download Checklist

These are the decisions and structures that must be in place before you engage a vendor, sign a SOW, or start a design session. Companies that skip these steps pay for them later — with scope creep, missed milestones, over-customization, and implementations that fail to deliver the original business case.

Define the business case before the RFP

Document the measurable business outcomes the ERP must deliver. Every customization request must be traceable to a business case outcome — not a process preference.

Establish a customization governance board

Create a cross-functional team (IT, Finance, Operations, Legal) with authority to approve or reject customization requests. No customization moves forward without a written business justification and full lifecycle cost estimate.

Map current processes to ERP standard before selecting a vendor

Conduct a fit-gap analysis before committing to a vendor. Understand where your processes diverge from ERP standards and whether those gaps are worth customizing or worth eliminating.

Distinguish configuration from customization

Configuration changes ERP behavior through settings and parameters — no code, no upgrade risk. Customization writes new code that must be maintained and retested. Push every request toward configuration first.

Require lifecycle cost disclosure for every customization

Every approved customization must include a 10-year cost estimate: initial build, annual maintenance, and upgrade impact cost. Present this to the business stakeholder who requested it before approval.

Adopt the vendor's extension platform for new development

SAP BTP, Oracle Fusion middleware, and Microsoft Power Platform exist specifically to extend ERP without touching core code. All new development should default to these platforms.

Audit and retire existing customizations before any upgrade

Before a major upgrade or S/4HANA migration, conduct a full inventory of existing custom code. Remove or retire anything no longer used. Move anything that can be moved to the extension platform.

Define and enforce change control from day one

Any change to requirements, scope, or configuration after the design phase is approved must go through formal change control — with a documented impact assessment and cost estimate.

Build regression testing automation early

Every customization adds to the regression test suite. Automating regression testing from the start — not retrofitting it later — is the only way to keep upgrade cycles manageable.

Align executive sponsors before the project begins

The CEO, CFO, and functional heads must understand and commit to the process change management required. ERP implementations that fail almost always do so because executives underestimated the organizational change involved — not the technology.

Plan the post-go-live optimization phase before go-live

The ERP standard will not perfectly fit every process on day one. A planned optimization phase (90–180 days post-go-live) is the right time to make enhancements — not during implementation, when they create the most risk.

Require vendor accountability in the SOW

The vendor SOW must define deliverables, acceptance criteria, and consequences for missed milestones. Vague SOWs create the conditions for scope disputes, delay excuses, and ultimately the kind of failure described in our ERP implementation failure case study.

How Full On Consulting Helps

Full On Consulting has managed ERP programs across SAP, Oracle, and Salesforce for mid-market and enterprise clients. Our approach to ERP customization is built on 20+ years of running these conversations from both sides — as an IT executive who had to make the case to the business, and as an independent advisor who has seen what happens when the governance breaks down.

Pre-Implementation Assessment

Before you sign with a vendor, we assess your current processes, run a fit-gap analysis against ERP standard, and define your customization governance framework. This is the work that prevents the expensive mistakes.

Customization Governance

We establish the governance board, the evaluation criteria, and the lifecycle cost framework that gives both IT and business stakeholders a disciplined process for customization decisions.

SAP S/4HANA Migration Support

We have led SAP upgrades including a 15-year overhaul of a $400M manufacturer's SAP environment — completed in a 40-hour weekend cutover, saving $400K. Clean core principles were central to that success.

ERP Program Recovery

When an ERP implementation is already off track, we step in as interim program leader, assess the situation independently, and define a realistic path to completion — as we did for the CEO who called us after firing his VP of Technology.

Relevant Client Success Stories:

SAP Upgrade: 15-Year Overhaul, 40-Hour Cutover, $400K Saved →SAP HR/HCM Program Recovery During a $16B Merger →IT Transformation: $40M Saved, 40% Growth Enabled →Application Rationalization Program →

Starting an ERP Initiative? Talk to Us First.

The most expensive ERP mistakes are made in the first 90 days — before the vendor is engaged, before the SOW is signed, before the design sessions begin. A direct conversation about your situation before you commit is the least expensive intervention available.

Start a Conversation 📋 Download the ERP Checklist

Frequently Asked Questions

Should you customize your ERP system?

The answer depends on whether the customization represents a genuine business differentiator or simply reflects a historical process that was never questioned. SAP, Oracle, and Microsoft all recommend defaulting to standard configuration and reserving customization for processes that are truly unique competitive advantages. The hidden cost of customization — in maintenance, regression testing, upgrade complexity, and acquisition integration — is almost always underestimated at the time of decision. A disciplined governance process before any customization is approved is essential.

What is SAP's Clean Core strategy?

SAP's Clean Core strategy is SAP's official guidance that companies should minimize custom code inside the core SAP system and instead use SAP Business Technology Platform (BTP) for extensions and integrations. The goal is not zero customization — it is intentional customization, limited to processes that are genuine competitive differentiators. A clean core enables faster upgrades, easier cloud migration, better AI adoption, and lower total cost of ownership. SAP recommends evaluating all existing customizations before an S/4HANA migration and eliminating or moving to BTP anything that is not essential.

What are the risks of over-customizing an ERP system?

Over-customizing an ERP system creates compounding technical debt that becomes increasingly expensive to manage. The primary risks are: upgrade complexity and cost — every customization must be retested with each new release; regression testing burden — customizations interact with each other and with standard code in unpredictable ways; performance degradation — poorly designed custom code can slow system performance; vendor support limitations — heavily customized systems may fall outside vendor support boundaries; acquisition difficulty — integrating an acquired company into a heavily customized ERP is significantly more complex; and talent dependency — custom code requires consultants who know that specific code, creating vendor lock-in.

When should a company customize its ERP?

Customization is appropriate when: (1) the process is a genuine competitive differentiator — something unique to your business model that standard ERP cannot replicate; (2) regulatory or compliance requirements specific to your industry cannot be met through configuration; (3) integration with a proprietary system has no standard connector available; or (4) the business impact of changing the process to match the ERP standard would be material and demonstrably harmful to operations. In all other cases — especially when the process is inefficient or simply 'the way we've always done it' — the right answer is to change the process, not the ERP.

How should IT present the customization decision to business stakeholders?

IT should present the full lifecycle cost of any customization — not just the initial development cost. This includes: estimated hours to build and test the customization; annual maintenance cost over a 5 to 10 year horizon; estimated additional cost at each major upgrade or version migration; regression testing scope and frequency; and any impact on vendor support. When business stakeholders see that a $50,000 customization carries $200,000 to $500,000 in lifecycle costs over 10 years, the conversation shifts from 'can we customize' to 'is this worth the real cost.' IT should also present the process change alternative — what it would take to redesign the business process to conform to the ERP standard.