Mainstream maintenance for SAP's Business Suite ends in 2027, with a paid extension available to 2030. That has been public since early 2020, and for three years it has been a slide in someone else's deck. As of this month it sits inside the planning horizon of any organisation whose ERP programmes run two to three years, which is most of them. The question has therefore changed. It is no longer whether the deadline is real. It is who will be available to do the work, and what they will charge by the time you ask.
The deadline is not 2027. It is the last quarter in which you can still hire people who know how to do this
Every large SAP customer is reading the same calendar. Programmes will cluster in 2025 and 2026, because that is what deadlines do to a market, and the supply of experienced conversion teams does not expand to meet a spike — it reprices. Work backwards instead of forwards. A conversion of a moderately customised estate takes twelve to twenty-four months from decision to go-live, longer for a multi-entity group. Add six to nine months for the options analysis, business case and partner selection that precede it. Add a stabilisation period you will not want to run through a year-end close. An organisation that has not begun serious analysis by the end of this year is choosing, whether it knows it or not, to buy its delivery capacity at the top of the market.
Three doors, honestly costed
Convert or rebuild on S/4HANA. The path the vendor wants, and for most large customers the eventual destination. The cost is dominated not by licence but by custom code, integration and testing. Pay for extended maintenance to 2030. Entirely legitimate, buys three years, costs a premium on top of existing maintenance, and changes nothing structurally. It is a financing decision dressed as a technical one: you are borrowing time at a stated interest rate. Useful if you have a genuine reason to defer — a pending acquisition, a divestment, a business model in flux. Corrosive if used as a substitute for deciding. Leave. Rarely chosen at group level and occasionally correct for subsidiaries, divisions and mid-market entities that were put on a heavyweight platform for consistency rather than need. This option is almost never analysed properly, because the people running the analysis are SAP specialists. A fourth exists and deserves mention: third-party maintenance providers who will support the existing estate past the vendor's dates, typically at a substantial discount. This is real and works for genuinely stable estates. It also ends your access to vendor updates and complicates any later return, so it suits organisations whose ERP is finished rather than evolving.
| Choice | Question to resolve |
|---|---|
| Convert or rebuild | How much used custom logic is understood and worth retaining? |
| Extended vendor maintenance | What explicit reason justifies delaying the decision or delivery? |
| Replace the platform | Which entities need the current platform's scope? |
| Third-party maintenance | Is a stable estate an intentional end state, and what options change? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The question that actually decides brownfield versus greenfield
The technical framing — convert the existing system or build new — hides the decision that matters, which is about knowledge rather than architecture. Run a custom code usage analysis before anything else. Most estates discover that a large proportion of custom objects have not executed in a year, and a meaningful number encode business rules nobody can now explain. Those two numbers decide the route. An estate with modest, well-understood customisation converts. An estate where custom code has become the actual business logic, undocumented, maintained by two people approaching retirement, is not a conversion project. It is an archaeology project with a go-live date, and pretending otherwise is how these programmes overrun.
The next ninety days, if you have not started
Three deliverables, none of which require a partner to be appointed. A custom code usage report, showing what runs, how often, and what does not run at all. A contract and licence position, including what the vendor's cloud subscription model would do to your commercial terms, how your existing licences convert, and what maintenance actually costs today. A two-page options paper with dates derived by working backwards from 2027, presenting all four doors with honest cost ranges rather than a single recommendation. That is a small piece of work. Its absence is why so many of these decisions will be made in 2026 under pressure, with one option left.
Practical Guidance for Migration Timing Assessment
- Work backwards from 2027, not forwards from today.
- Run the custom code usage analysis first; it decides the route.
- Price extended maintenance as financing, with an explicit reason for the delay.
- Analyse leaving, at least for subsidiaries, using someone who is not an SAP specialist.
- Name key personnel in the partner contract, with substitution rights.
- Avoid go-lives near statutory deadlines and year-end closes.
- Separate the cloud commercial decision from the technical migration decision.
- Decide this year, even if you execute in two.
The Regional Angle
Three factors shape this decision for groups operating here. The first is that regulatory work will collide with migration work, and paying for it twice is the default outcome. The Saudi electronic invoicing integration waves are running now, and further waves will land through this year and next; other jurisdictions in the region are drafting their own regimes. That integration has to be built on whichever system is live when the wave reaches you. Sequence it deliberately: an entity whose wave lands in the next eighteen months should build once on the current platform and migrate afterwards, while an entity whose obligation arrives later should aim to arrive already on the target platform. The wrong answer — and the common one — is to let the tax deadline and the migration programme run as unrelated projects managed by different people, which guarantees the same interface is built twice and tested twice. The second is that the talent squeeze will be sharper here than the global picture suggests. Regional SAP capability is concentrated in a modest number of consultants, many on project-linked visas, working for partners who serve clients across several countries. When European and North American programmes converge on the same two years, those consultants become internationally priced, and the regional client competes for them on rate rather than on relationship. The protection is contractual and should be negotiated now rather than later: name the key individuals in the statement of work, require notice and equivalent substitution, and tie a meaningful share of fees to delivery milestones rather than to elapsed days. Partners will resist. Partners who refuse entirely are telling you something about which client will get their best team in 2026. The third is that for many regional groups this deadline is an opportunity that only comes once. Family groups and diversified holdings here typically grew by acquisition, and run a heavyweight platform in the entities that were standardised early, alongside a collection of other systems everywhere else. The honest question is not how to move everything to the new version. It is which entities genuinely need the group platform and which were placed on it for uniformity, and whether a deliberate two-tier estate — the core on the major platform, smaller and newly acquired entities on something lighter with clean consolidation into the group ledger — is both cheaper and faster. That analysis has been politically difficult to raise for a decade. A vendor deadline makes it a legitimate agenda item, and this is the year to put it on the table.
The objection worth taking seriously
The strongest objection is that vendor deadlines move. This one has already been extended once, the customer base is enormous and much of it will not be ready, and commercial reality will eventually produce another accommodation. Meanwhile, the target product keeps improving, early movers paid for immaturity, and the organisations that waited will implement something better, faster and cheaper than those who went first. Waiting, on this reading, is not procrastination but a well-evidenced strategy. The historical record supports much of that. Early adopters did absorb genuine pain, and a customer converting in 2026 will implement a more complete product than one converting in 2021. Where the argument fails is that it treats the vendor's calendar as the binding constraint when the binding constraint is delivery capacity. Even if the date moves again, the market will have spent two years pricing on the assumption that it will not, and the extension will arrive too late to change your partner's staffing plan. The extension is also not free — it is a premium, payable annually, on top of maintenance. Waiting is a legitimate option, but it should be bought consciously, with the cost written down, and by an organisation that knows which of the four doors it will eventually walk through. Most organisations currently waiting cannot answer that question, which means they are not choosing to wait. They are choosing not to decide.
Common Questions
Is conversion cheaper than a new implementation?
Usually, for a moderately customised estate with sound master data. It stops being cheaper when custom code is extensive and undocumented, which is exactly when the conversion is chosen for the wrong reasons.
Does the cloud subscription model have to be part of this?
No, though the vendor would prefer it. Evaluate the commercial model separately from the technical migration, because bundling them makes both harder to assess.
Is third-party maintenance safe?
Operationally, for a stable estate, generally yes. Strategically it narrows your options later and should be a deliberate end-state decision rather than a way to postpone one.
What should we expect over the next twelve months?
Expect the vendor to push its cloud commercial terms harder as the deadline approaches, with incentives weighted towards subscription rather than licence. Expect a wave of fixed-price "conversion factory" propositions from partners, which will suit clean estates and badly serve complicated ones. Expect day rates for experienced conversion resources to begin climbing noticeably from next year. And expect a substantial number of organisations to buy the extension to 2030 and still not be ready, because the constraint was never the deadline.
Migration Timing Assessment — we work the dates backwards, cost all four doors honestly, and tell you which entities should move and which should never have been on the platform.