ECC 2027: Delete Before You Migrate

SAP's mainstream maintenance for ECC ends at the close of 2027, fifteen months from now. For many companies still on ECC, the migration plan starts with an estimate of how much custom code must be converted. My view is that this is the wrong first question. The first question is how much of that code should exist at all.

Custom code is two things at once. It is technical debt, because it complicates every upgrade. It is also the most honest record of how your business actually runs, because every custom program was written to handle something the standard system did not. Delete it without reading it and you lose business logic nobody wrote down. Migrate it without questioning it and you pay to move code nobody uses.

This piece is for CIOs, SAP leaders and finance heads with an ECC landscape and a 2027 date on the wall. It sets out the dates, a delete-first sequence, and a decision framework for what remains.

The short version

ECC mainstream maintenance ends in December 2027, with paid extended maintenance available to the end of 2030. The biggest saving in any migration comes from custom code you retire before you start. Read the code as a map, delete what usage data says is dead, then decide object by object whether to adopt standard, rebuild cleanly or keep with documented risk.

• Confirm your maintenance path for 2028 before the end of 2027.
• Collect usage data on custom code before estimating anything.
• Retire unused objects before migration, not after.
• Ask the business what each surviving object is for.
• Build new extensions on released APIs and ABAP Cloud.
• Track custom code volume as a board-level risk number.

This article sits inside the sap s/4hana, clean core and rap cluster, where the wider argument is set out in full.

What the dates actually say

In February 2020, SAP committed to mainstream maintenance for SAP Business Suite 7 core applications, which include ECC, until the end of 2027. From 2028 to the end of 2030, customers can buy extended maintenance at a premium of two percentage points on the maintenance basis. Customers who do not choose it move to customer-specific maintenance, a narrower service. SAP also committed to maintaining S/4HANA until at least the end of 2040.

SAP has since introduced a private cloud transition option under RISE with SAP that extends support for some large customers to 2033. Eligibility and terms are specific, so check them directly with SAP rather than planning around a date you read in an article.

The practical point is simple. The date is fixed, the extension costs money, and every month spent migrating code that should have been retired is a month you may pay the premium for.

Custom code is a map before it is debt

Before any remediation tool runs, I would ask a different question of the custom code: what does it tell us about the business?

A large custom pricing routine says the standard pricing did not fit how you sell. A cluster of custom reports around one process says managers do not trust the standard output. Custom approval logic says somebody once decided the standard workflow was too loose. None of that is written in a process manual. The code is the manual.

That is why I treat the volume of custom code as an auditable proxy for undocumented process logic. A landscape with a very large number of custom objects is not only expensive to upgrade. It is a business that depends on rules held in programs rather than in policies, which is a governance question as much as a technical one.

My own SAP work centres on clean core, the ABAP RESTful Application Programming Model and BTP extensibility, so my bias is visible: I would rather rebuild a small number of important rules cleanly than carry a large number of unexamined ones forward.

Delete first, and let usage decide

The fastest saving in any migration is the object you never touch. The sequence I would follow:

• Step 1. Switch on usage logging for custom code in production and let it run across a full business cycle, including quarter-end and year-end if time allows.
• Step 2. List every custom object with its usage, owner, last change date and the process it supports.
• Step 3. Mark objects with no recorded use as retirement candidates, and send the list to business owners with a fixed deadline to object.
• Step 4. Retire what nobody claims, in the ECC system, before migration begins.
• Step 5. Only then run the remediation estimate on what remains.

The discipline is to make people argue for keeping code, rather than making IT argue for removing it. Most objects on a retirement list attract no defenders at all.

Risk: usage logs that miss year-end will label your statutory reports as dead code. Time the logging window with finance.

Should your organisation do this now?

• Yes, if you are still on ECC with no usage data on custom code.
• Not yet, if production logging would breach a change freeze.
• Instead, first: agree the logging window with finance and IT operations.
• Measure it by: share of custom objects with at least one quarter of usage data.

Four decisions for what survives

For every custom object still in use, choose one of four paths. The value of the framework is that it forces a decision per object instead of a blanket "migrate everything".

Retire

• When it fits: the object is unused or duplicates standard function.
• Pros: no migration cost, less to test, smaller attack surface.
• Cons: a missed dependency can surface later.
• Cost and risk: lowest cost, low risk if usage data is good.
• My view: the default for anything without a named business defender.

Adopt the standard

• When it fits: the business need is real but S/4HANA now covers it.
• Pros: upgrades carry the logic for you.
• Cons: users must change how they work.
• Cost and risk: change management effort, low technical risk.
• My view: worth pushing hard, because this is where process improvement actually happens.

Rebuild as a clean extension

• When it fits: the logic is a genuine differentiator and changes often.
• Pros: built on released APIs, designed to survive upgrades.
• Cons: rebuild effort and new skills.
• Cost and risk: higher build cost, lower long-term upgrade risk.
• My view: the right home for pricing, credit or approval rules that set you apart.

Keep as classic code, with the risk written down

• When it fits: no released API exists yet and the logic is essential.
• Pros: fastest path through the migration.
• Cons: upgrade risk remains.
• Cost and risk: low cost now, recurring cost later.
• My view: acceptable only with a named owner and a review date.

SAP's refreshed clean core extensibility guidance grades extensions from Level A, built with ABAP Cloud on released APIs, to Level D, which uses objects SAP does not recommend. Use those levels to label the "keep" pile honestly.

RAP in business terms

The ABAP RESTful Application Programming Model is SAP's current way to build business applications and services on S/4HANA. For a CIO it matters for one reason. Extensions built with it on released interfaces are designed to survive upgrades, while much of the custom code you already own was not.

That changes the economics of the "rebuild" path. A rule rebuilt this way costs more once and less every upgrade after. A rule carried forward as classic code costs little once and something every upgrade after. The decision per object is therefore a question about how often it will change and how long you expect to run it.

Before you approve it

Checklist:

• Decision on 2028 maintenance path documented and budgeted.
• Usage logging active across a full business cycle.
• Custom object inventory with owners and supported processes.
• Retirement list issued with a deadline for objections.
• Retirements completed before the remediation estimate.
• Per-object decision recorded against the four paths.
• Clean core level recorded for every object you keep.

Questions to ask:

• Your team: how many custom objects ran at least once last quarter?
• Your team: which surviving objects have no named business owner?
• Your SAP partner: does your estimate assume we migrate everything?
• Your SAP partner: which kept objects rely on objects SAP does not recommend?
• Your CFO: what does extended maintenance cost us per year of delay?
• Your board: what is our custom code count today, and what will it be after migration?

How to measure it

• Custom object count. The size of undocumented logic you carry. Baseline: current inventory. Owner: SAP lead. Review: quarterly. Lagging.
• Usage data coverage. Share of objects with a full cycle of usage data. Baseline: zero at start. Owner: SAP basis lead. Review: monthly. Leading.
• Retired before migration. Objects removed ahead of conversion. Baseline: inventory. Owner: SAP lead. Review: monthly. Leading.
• Objects with owners. Share of surviving objects with a named business owner. Baseline: inventory. Owner: CIO. Review: monthly. Leading.
• Clean extension share. Share of kept logic at the cleanest level. Baseline: design phase. Owner: SAP architect. Review: quarterly. Lagging.
• Upgrade rework effort. Days spent fixing custom code per upgrade. Baseline: last upgrade. Owner: SAP lead. Review: per upgrade. Lagging.

Mistakes that cost the most

Estimating before deleting

The estimate then prices code that should not exist.

• Why it happens: partners are asked for a number early.
• Prevention: retire first, estimate second.
• Early warning: estimates quoted before usage data exists.

Short usage windows

A month of logging misses period-end programs.

• Why it happens: schedule pressure.
• Prevention: cover at least one quarter-end, ideally year-end.
• Early warning: statutory reports appearing on the retirement list.

Treating all custom code as debt

Some of it is your competitive logic.

• Why it happens: clean core is read as "no custom code".
• Prevention: ask what each object does for the business.
• Early warning: differentiating rules retired without discussion.

Rebuilding everything

Clean rebuilds cost money that low-value code does not justify.

• Why it happens: enthusiasm for new tools.
• Prevention: rebuild only logic that changes often and matters.
• Early warning: rebuild backlog larger than the retire list.

Leaving the maintenance decision late

Choosing a 2028 path under deadline pressure removes options.

• Why it happens: it is treated as a procurement detail.
• Prevention: decide and budget it in 2026 or early 2027.
• Early warning: no line for maintenance in next year's budget.

Frequently asked questions

When does SAP ECC mainstream maintenance end?

Mainstream maintenance for SAP Business Suite 7 core applications, including ECC, ends at the end of 2027. Optional extended maintenance runs from 2028 to the end of 2030.

What does extended maintenance cost?

SAP stated a premium of two percentage points on the maintenance basis for the extended period. Your actual cost depends on your contract, so confirm with SAP.

What happens if I do not buy extended maintenance?

SAP moves customers who do not choose extended maintenance to customer-specific maintenance, which is a narrower level of support.

Can ECC run beyond 2030 with SAP support?

SAP has introduced a transition option under RISE with SAP for some large customers, extending to 2033. Eligibility and terms are specific, so check directly with SAP.

What is clean core?

Clean core is SAP's approach of keeping the ERP core close to standard and building extensions in upgrade-safe ways, mainly through released APIs and separate extension layers.

What is SAP RAP?

The ABAP RESTful Application Programming Model is SAP's current model for building business applications and services on S/4HANA, designed to work with released interfaces so extensions survive upgrades.

How do I know which custom code is unused?

Switch on usage logging in production across a full business cycle, including period-end, and compare the result against your custom object inventory.

Should all custom code be removed?

No. Unused and duplicated code should go. Logic that differentiates your business should be rebuilt cleanly or kept with a named owner and documented risk.

What to do next

Start usage logging this quarter so you have a full cycle of data before estimates are needed. Then read the SAP clean core topic page, and the related piece on why your LMS-to-SAP interface is a control.

Sources

• SAP Support, Maintenance strategy for SAP S/4HANA and SAP Business Suite 7, February 2020. support.sap.com
• SAP press release via PR Newswire, SAP extends innovation commitment for SAP S/4HANA, 4 February 2020. prnewswire.com
• SAP Community, Why clean core matters: the Extensibility white paper, 2025. community.sap.com
• E3 Magazine, Deadline extension for ECC 6.0 until 2033, October 2025. e3mag.com

Last reviewed: 15 September 2026.

Views are my own and do not represent my employer.