31 December 2027
Mainstream maintenance for the core applications of SAP Business Suite 7 ends. For SAP ERP 6.0 this covers the last three enhancement packages, 6, 7 and 8.
SAP replacement
A deadline you did not choose.
Maintenance for SAP Business Suite 7 ends on 31 December 2027. That date does not decide which system you run next. It only decides that you have to decide.
The deadline
What actually runs out.
Four dates matter, and they are not the same for everyone. Which one applies to you depends on the enhancement package your system runs on – a number most companies have to look up.
31 December 2025 – already past
SAP ERP 6.0 without an enhancement package, and with enhancement packages 1 to 5, left mainstream maintenance at the end of 2025. Anyone on an older stack is not facing the deadline; they are past it.
2028 to 2030
Optional extended maintenance can be booked for three further years, at a premium of two percentage points on the maintenance base. It buys time. It does not answer the question.
2040
SAP has committed to maintaining SAP S/4HANA until the end of 2040. That is the horizon of the road SAP is offering – useful to know when you compare it against another one.
Sources, checked August 2026: SAP on maintenance until 2027, 2030 and 2040 · SAP maintenance strategy for Business Suite 7 and S/4HANA. Dates are SAP's own and can change; check them against your maintenance contract before you plan around them.
Three roads
Not one decision. Three.
Two of them lead to S/4HANA and differ in how much of the old system comes along. The third leaves the product line. The table compares architecture, not price or quality – judge those for yourself.
| Property | System conversion | New implementation | Platform change |
|---|---|---|---|
| What comes along | Configuration, customising and historical data of the existing system | Selected master and transaction data, the configuration is built fresh | The data; the processes are rebuilt on a standard that is read and changed openly |
| What has to be reworked | Every modification that the new core no longer permits | The process design, deliberately and from the ground up | The process design, plus everything that hung off SAP-specific interfaces |
| Where it runs afterwards | Cloud or your own data centre | Cloud or your own data centre | Your data centre or EU cloud, your choice |
| How your own logic attaches | Released APIs, ABAP Cloud, beside the core – the clean-core principle | The same; a new implementation does not change the extension rules | Your own modules in the same process as the data |
| Database | SAP HANA | SAP HANA | PostgreSQL, open licence |
| What the deadline does to it | Fixed end date, the effort scales with how much was modified | Fixed end date, the effort scales with how many processes are redesigned | No vendor deadline; the date becomes yours to set |
In plain words: the system conversion is what the market calls brownfield, the new implementation greenfield. Between them sits selective data transition, a hybrid that converts a shell of the old system or transfers parts of the configuration into a fresh installation. It changes how much comes along – not the extension rules and not the database.
Sources, checked August 2026: SAP on clean-core extension · SAP on selective data transition · Odoo Community licence.
What it costs
The bill has six lines.
Not one of them is the project price, and that is the point: the project ends, the other five recur. This compares where the money goes, not how much – see below for why there are no figures on this page.
| Cost driver | On the SAP road | On a platform change | What decides it |
|---|---|---|---|
| Database licence | A licence of its own, next to the application | None; PostgreSQL is openly licensed | Data volume and the contract you already hold |
| Application licence | Per user and scope, under the vendor's model | Per user, plus the modules you actually use | How many people really need a seat |
| Extension | Built beside the core, at the points the vendor opens | Built into the process, in the language the platform is written in | How far your processes sit from the standard |
| Operations | Vendor cloud or your own data centre, with specialists to match | Your data centre or EU cloud, with standard administration | Whether the skills already exist in the house |
| Upgrade cycle | Planned releases; modifications raise the cost of each one | Planned releases; own modules are tested against each one | How much you built yourself, on either road |
| Leaving again | Data exportable, extensions bound to the vendor platform | Open formats, the core source public | What it would cost you to change your mind in year seven |
Why there are no figures here
A total cost of ownership without your licence contract, your user count and the state of your data would be a number we made up. It would also be the number you remember. So we compare the drivers, and we put an honest range on the table once the assessment has looked at all three.
The line that is usually underestimated
Not the licence – the modifications. What was built into the old system over fifteen years decides the effort on every road, including the one that stays with SAP. Counting them is the first thing an assessment does, because everything else is a guess until it is done.
How it runs
What is different about an SAP replacement.
The sequence is the one every controlled replacement follows. Three things are specific to a system that has carried the business for two decades.
-
01
Find out what is actually in there
Enhancement package level, modifications, custom developments, interfaces and the reports somebody built in 2011 that a department still runs the month-end on. This is the step that decides every figure that follows, and it is the one most often skipped.
-
02
Separate what has to come along
Not every custom development is a requirement; some are workarounds for a limitation that no longer exists. Each one is decided explicitly: rebuild, replace with standard, or drop. What is dropped is written down, so nobody rediscovers it after go-live.
-
03
Move in stages, not in one night
A scope that can go live and already carry value, then the next. Historical data is dealt with deliberately: what is migrated, what stays readable in an archive, and how long the old system has to remain available for audits.
-
04
Then someone has to run it
The day after go-live is when the replacement is judged. Monitoring, support, updates and a named responsibility are agreed before the project starts, not negotiated once it is over.
Risk and the way back
The question nobody asks until it is too late.
What happens if this turns out to be the wrong road. A replacement that cannot be stopped is not a project, it is a bet – so the exits are built in before the first stage starts.
Parallel operation
Both live
- The old system stays available while a stage settles
- Reconciliation runs against the source, not against a copy
- Cutover per area, not for the whole company at once
Decision points
Before each stage
- Every stage ends with a result you can judge
- The next stage is commissioned separately
- Abort criteria are written down in advance
The way back
Readable
- The old system stays readable for the retention period
- What was archived instead of migrated is documented
- Audits do not depend on the new system alone
Your data
Yours
- Extraction into open formats, not into a black box
- The target database is yours: PostgreSQL, exportable at any time
- What we build for you belongs to you
What we do not promise
That a replacement is cheaper than staying. Over a maintenance term it usually is, but that depends on your contract, and we do not know it. What we do promise is that you see the numbers before you commit, not after.
When you should stay with SAP
If your processes are deeply tied to industry solutions SAP has built for your sector, if worldwide localisation and deep regulatory requirements shape your daily work, or if the modifications turn out to be few and the standard fits – then the conversion is the shorter road, and we will say so.
Questions
Asked in the first meeting.
- When exactly does maintenance for our SAP system end?
- For SAP ERP 6.0 with enhancement package 6, 7 or 8, mainstream maintenance ends on 31 December 2027. Without an enhancement package, or with enhancement packages 1 to 5, it already ended on 31 December 2025. Which case applies is worth checking before anything else, because it changes how much time there is.
- Does extended maintenance to 2030 solve the problem?
- It moves it. SAP offers three additional years, from the start of 2028 to the end of 2030, at a premium of two percentage points on the maintenance base. That is time to decide properly rather than in a hurry. It is not a decision.
- Do we have to move to S/4HANA?
- No. The end of maintenance forces a decision about which platform carries your business, not the choice of a particular product. S/4HANA is one answer, and for some companies it is the right one. It is not the only one.
- How long does a replacement take?
- We do not quote a duration before we have seen the system, because the honest answer depends on the number of modifications, the state of the data and how many processes change. The assessment that produces that answer takes two to three weeks and ends with a roadmap and a budget corridor.
- What happens to twenty years of historical data?
- Part of it is migrated, part of it is archived, and the split is decided deliberately rather than by whatever the migration tool manages. What stays readable, for how long and in which form is written down before the first stage, because that is what an audit will ask about later.
- And if it turns out mid-way to be the wrong road?
- Each stage is commissioned on its own and ends with a result you can judge, the old system stays available while a stage settles, and the abort criteria are agreed in advance. The assessment can also end with the recommendation not to do the project at all – that is a possible outcome, not a failure of the exercise.
The next step