
Contents
ERP modernization in 2026 means three decisions made in order: what your ERP should stop doing, how clean you will keep its core, and whether your data is good enough for AI to be useful. For SAP customers there is a hard date behind all three: ECC mainstream maintenance ends on 31 December 2027, with paid extended maintenance to the end of 2030.
This is for CIOs, CFOs and enterprise architects who have finished the analysis and now have to execute. It covers the forces driving action, the backbone-plus-satellites architecture, clean core, the governance gap, AI readiness, and a risk table for the next 18 months.
In 2024, most leaders were still buying time: studying ECC timelines, debating hybrid against full migration, running sandbox tests without committing. That window has closed. The technical debt in ECC and Oracle E-Business Suite landscapes is no longer theoretical. It shows up in failed regression tests after updates, in audit findings on custom code nobody owns, and in data that takes 12 hours to move between planning and execution systems.
The deadline. After 2027, ECC customers can buy extended maintenance to the end of 2030 at a higher fee. Beyond that, SAP offers an ERP private edition transition option for 2031 to 2033, but only through RISE, and SAP is explicit that it is a paid transition offer, not a maintenance extension. Meanwhile Gartner research reported by The Register found that by the end of 2024 only about 39% of SAP's roughly 35,000 ECC customers had bought or subscribed to S/4HANA licences. Licensed is not the same as migrated. The partner market will be tight.
The budget model. Cloud ERP moves spend from capex licences to subscriptions. That sounds cleaner. In practice, CFOs find cloud costs less predictable: under RISE with SAP and SAP GROW, Full User Equivalent (FUE) growth, add-on services and integration overhead add costs that weren't in the original business case.
Fragmentation in finance and supply chain. Finance teams run AI on payables and receivables while audit processes still use templates built for a different era. Supply chains are partly modernised: SAP IBP for planning, older warehouse management for execution, Ariba for procurement but manual goods receipts. The bottleneck is not technology. It is the joins between systems.
ERP is one layer, not the whole stack. ServiceNow runs process orchestration in many enterprises, Salesforce runs customer workflows, Workday or SuccessFactors runs the HR lifecycle. ERP has become the financial backbone, not the all-in-one process hub it was sold as in the 1990s.
The model most enterprise architects now work with is a financial backbone (SAP S/4HANA or Oracle Fusion) surrounded by specialist platforms.
| Layer | What sits here | What doesn't |
|---|---|---|
| Financial backbone | General ledger, controlling, procurement, inventory, manufacturing execution, statutory close | Workflow approvals, CRM, workforce management, analytics |
| Workflow | ServiceNow for IT and operations processes, approvals, change management | Transactional record-keeping |
| Customer engagement | Salesforce or SAP Sales and Service Cloud | Financial processing |
| Workforce | Workday or SAP SuccessFactors | Operational transactions |
| Analytics | SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake | The system of record |
The separation is deliberate. Forcing everything back into SAP adds friction, slows updates and blurs ownership. Cramming CRM, workflow, analytics and EHS into one system is what made earlier programmes so painful.
The question to ask: what should ERP no longer be responsible for? Skip it and you rebuild the same monolith on a newer licence. My piece on ERP modernization with SAP and ServiceNow works through one version of that split.
In August 2025 SAP replaced its three-tier extensibility model with four clean core levels. Level A uses only released, stable APIs, side by side on SAP BTP or in-system with ABAP Cloud. Level B uses classic APIs and technologies SAP still considers clean. Level C reaches into internal objects and needs special measures. Level D is not clean.
The public edition (SAP Cloud ERP, sold as SAP GROW) only allows level A, so the platform enforces clean core and absorbs two major releases a year. The private edition (SAP Cloud ERP Private, under RISE) and on-premise still allow classic extensions, so clean core there depends on governance. Either way, a heavily customised system turns every upgrade into a project and every regression test into a crisis.
What clean core asks of you:
- Take unused custom code out of the core. Every custom program you keep is something to test at each upgrade.
- Build new extensions at level A where you can: on SAP BTP, with SAP Build, or in-system with ABAP Cloud.
- Use standard processes wherever SAP ships them, and customise only where regulation or real competitive difference requires it.
The resistance is cultural, not technical. Business leads who relied on custom code for 15 years still expect it to "just be re-implemented". That expectation belongs to 2012.
A typical ECC landscape carries 1,500 to 3,000 custom objects, based on assessments I have run across manufacturing and services, and only about a quarter show active business use. The rest is historical weight that inflates migration cost and creates audit exposure.
The practical move: run a usage scan now. Deprecate what is inactive. Publish a cut list before design begins. Teams that plan clean core from week one have far better upgrade experiences than teams that treat it as a constraint to work around. My clean core strategy article goes into the method.
With ERP as one layer among many, ownership questions become critical. Who owns:
- The API between Salesforce and the ERP?
- A workflow that spans SAP and ServiceNow?
- Conflicting change priorities when both systems need updates at once?
I have seen this delay go-lives by months. Teams don't realise they are stuck until integration testing exposes the overlap.
In one case, five systems were touching the same supplier master record. Five. No one had a master data ownership document, and nobody had designed who could change what, in which system. That isn't a technology failure. It is a governance failure that technology exposed.
Modernization is not about shiny tools. It is about strategic subtraction. Deciding what ERP should no longer be responsible for, and being honest about who owns the boundaries.
AI value in ERP is real, but it depends on data quality and a clean architecture. Joule now spans S/4HANA, SuccessFactors, Ariba and other SAP products, and SAP's agents run under Joule assistants. Agentic use cases on SAP BTP are shipping, not slideware. They all depend on clean, consistent, structured data.
If your data is duplicated, inconsistently coded or sitting in custom tables S/4HANA doesn't recognise, AI has nothing reliable to work with. Finance teams running AI on payables find this out fast when invoices match to the wrong vendor because the vendor master was never cleaned.
The sequence that works: clean core first, data governance second, analytics third, AI fourth. Skipping steps doesn't speed anything up. It moves the problem later.
- Set the boundaryDecide what ERP should stop doing
- Clean the coreRetire unused code, build new at level A
- Govern the dataOne owner per data object
- Build the analyticsSAP Business Data Cloud, SAC or Power BI on governed data
- Add AIJoule and agents on a reliable base
AI with something reliable to work with
| Risk | Signal | Practical response |
|---|---|---|
| ECC deadline pressure | Mainstream maintenance ends December 2027; most ECC customers had not licensed S/4HANA by end of 2024 | Lock partner resource plans now; senior US day rates already run $1,800 to $3,500 |
| Custom code debt | 1,500 to 3,000 custom objects, about a quarter in active use | Run usage scans, publish a cut list, start retirement sprints |
| Release disruption | Releases collide with financial close and supply chain peaks | Set release windows away from close; automate regression tests |
| Data migration risk | Late harmonisation produces defects teams mislabel as bugs | Early sizing; bank, tax and compliance data checks before design freeze |
| Integration ownership gaps | Five or more systems touching shared master data | Publish an authority matrix; one owner per data object |
| Two lifecycle tools | Hybrid landscapes run Solution Manager and SAP Cloud ALM in parallel | Cloud ALM as the default for cloud programmes; Solution Manager 7.2 mainstream maintenance ends end of 2027 |
For the delivery-level version of these risks, see ten ERP modernization mistakes to avoid, and for the migration paths themselves, the ECC to S/4HANA migration guide.
What is clean core in SAP S/4HANA?
Keeping S/4HANA as close to standard as possible and putting extensions where upgrades can't break them. Since August 2025 SAP grades extensions from level A (released APIs only, on SAP BTP or in-system with ABAP Cloud) to level D (not clean). The business reason is upgrade protection: a clean system absorbs releases in days, a heavily customised one turns each into a project.
What is the backbone-plus-satellites architecture for ERP?
ERP (SAP S/4HANA or Oracle Fusion) handles what it is built for: financial records, inventory, procurement, manufacturing transactions and statutory reporting. Specialist platforms handle the rest: ServiceNow for workflow, Salesforce for customer engagement, Workday or SuccessFactors for HR, and analytics platforms for insight. Forcing all of that into the ERP creates a monolith that updates slowly and customises heavily.
How should companies approach the 2027 SAP ECC deadline?
Start with SAP Readiness Check. It surfaces custom code volumes, add-on dependencies and data sizing, the three factors that decide whether you go brownfield, greenfield or selective. Complex enterprise migrations typically run 18 to 24 months from assessment to go-live, so if you haven't chosen an approach and started partner conversations by now, a 2027 go-live is already tight. Extended maintenance to 2030 costs more and buys time, not innovation.
When is AI valuable in ERP modernization and when is it not?
When the data is clean, consistent and structured and the process has clear rules: payables automation, demand forecasting and anomaly detection in financial transactions are proven cases. AI is not a shortcut past poor data or governance gaps. Decisions made on bad inputs are harder to catch than manual errors. Clean core, data governance and stable processes come first.
What are the biggest ERP modernization mistakes companies make?
Treating it as a technology project, so the clean core debate is lost before business leads are in the room. Starting data governance after design, when decisions made in week one would have saved months of testing. Not defining what ERP should stop doing, so core scope expands by default, which is how the last monolith was built.
What does ERP modernization cost?
A brownfield ECC-to-S/4HANA conversion for a mid-market company typically runs $2M-$8M in implementation costs, plus the ongoing subscription. Enterprise programmes with global scope, significant customisation and many entities can run $20M-$100M+. Model integration, testing and operational support as well as licences, and under RISE and SAP GROW model FUE growth across the contract term.
Next step
Running an ERP programme right now?
If this article touched on a programme you are live in right now, a 30-minute conversation usually gets further than another week of internal analysis.




