The decision itself, and what staying on ECC past 2030 really costs. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twenty four, and this is the one module five has been building towards. You now know what RISE is, what is in the bundle, how the FUE sizing works, and what GROW gives you and takes away. So the question left is the actual decision: which of these should you buy, and how do you defend that answer to the people who have to fund it? I am going to argue for four routes rather than the two most organisations consider, for a ten year window rather than three, and for pricing the risk instead of describing it. Three knowledge checks. Let's begin.
Five objectives. First, name the four routes: RISE private edition, GROW public edition, S four HANA on premise, and staying on ECC, because all four of those are genuinely real options. Second, compare them on the same basis, meaning ten year total cost, control, risk and effort, with identical assumptions applied to every column. Third, cost the stay option honestly, because staying is neither free nor reckless, it has a real price and a real risk profile and both can be stated. Fourth, judge third party support fairly: what it covers, what it does not, and what it does to your relationship with the vendor while you are using it. And fifth, build a case that survives, which means the four questions a board will ask that most SAP business cases cannot actually answer.
Four things to frame it. Four options: RISE, GROW, on premise and stay, and ruling any of them out before you cost it is how organisations end up in the wrong one. Ten years, not three, because the differences between these routes only become visible over the life of the decision. Same assumptions: one growth rate, one discount rate, one scope, applied to every column, and most comparisons fail exactly here. And risk is a number, because unsupported software, migration failure and vendor dependency are all costs, so price them rather than describing them. The most common failure I see is not choosing wrongly. It is choosing between two options when there were four, on assumptions that quietly favoured the answer somebody had already picked. Let me be specific about how that happens.
Guest analyst clip.
Rejecting an option with a number next to it is analysis. That is the discipline, and it is worth insisting on even when you are confident, because the cost of building the extra two columns is an afternoon and the cost of not building them can be a decade. Let's look at what the four routes actually are.
Four routes. RISE private edition: subscription, SAP operates it, you keep your extensions, so it is the highest flexibility of the cloud options and you stop owning. GROW public edition: subscription, standard process, fastest and cheapest to run, and you give up the ability to shape the software. S four HANA on premise: you still own perpetual licences and you still run it, so highest control, highest effort, and it is the option people forget exists. And stay on ECC: defer, which is real and has a shelf life, and the question is what it costs per year and how long you can hold it. Notice that on premise S four HANA remains available and keeps you in the perpetual model from session twenty one. If ownership matters to your organisation, that is the route that preserves it, and it is the one most often left out of the comparison entirely.
Now the four routes on one page. Ownership: subscription, subscription, perpetual, perpetual. You operate it: no, no, yes, yes. Core changes: yes for RISE, no for GROW, yes for both of the perpetual routes. Upgrade control: shared with RISE, none with GROW, full on premise and full if you stay. Programme cost: high, medium, high, and none yet if you stay. And the main risk on each: renewal pricing for RISE, fit and standardisation for GROW, effort and skills on premise, and the support cliff if you stay. Every row there is a trade rather than a score, so there is no column that wins. Read down the one that matches how your organisation actually behaves rather than how it describes itself in a strategy document, because those two things differ more often than anyone likes to admit.
First knowledge check. Which route keeps you in the perpetual ownership model? A, RISE private edition, because your extensions come with you. B, S four HANA on premise, or staying on ECC. C, GROW, because the contract is shorter. D, none, because perpetual licensing has been withdrawn. Pause here and pick an answer before you continue.
The answer is B. Both cloud routes are subscriptions, so both of them remove the floor we talked about in session twenty one. A confuses two different things, because keeping your extensions is a technical freedom and it has nothing whatsoever to do with whether you own the licence. C has it backwards, since a shorter contract is not a longer lasting entitlement. And D is the belief that quietly eliminates a real option from a great many business cases, and it is simply wrong: S four HANA on premise is still sold perpetually. Whether it suits you is a separate question, and for many organisations it will not, but it belongs in the comparison rather than being assumed away before anybody looks at it.
So what does staying actually cost? Five things. Mainstream maintenance ends in twenty twenty seven for most ECC customers, with extended maintenance running to twenty thirty at a premium, and that premium is a known, quotable number rather than a mystery. After twenty thirty you are on your own or with a third party: no SAP patches, no legal and regulatory updates from SAP, no new functionality, though the system does keep running. The real risk is regulatory rather than technical, because tax, statutory reporting and country legal changes stop arriving, and for a multinational that is the binding constraint. The skills market moves against you, since ECC specialists get scarcer and more expensive every year, and that is a cost line that rises predictably. And deferring is buying an option, which is entirely legitimate when the business is mid-merger or mid-restructure. Just price the option rather than drifting into it.
Guest analyst clip.
Deferring against drifting, and they look identical for about eighteen months. I think that is the most useful distinction in this whole session, because it gives you something concrete to test. Ask whoever is proposing to wait for three things: the annual cost of waiting, the date the regulatory exposure becomes material, and the day the transition programme starts. If those three exist, you are deferring. If they do not, you are drifting, whatever the paper says.
Second knowledge check. For a multinational manufacturer, what is the binding constraint on staying past twenty thirty? A, security patches stopping. B, statutory and tax legal changes no longer arriving. C, hardware reaching end of life. D, losing access to new SAP functionality. Pause here before you continue.
B. A is real and it is manageable, because third parties and your own controls can address security perfectly well. C is an infrastructure problem with an infrastructure solution. D is an opportunity cost rather than a constraint, and plenty of organisations forgo new functionality quite happily for years at a time. B is the one that binds, because a manufacturer operating in twenty countries needs payroll, tax and statutory reporting to track local law, and those changes are not optional and they do not wait for your programme. Third party providers do supply them, which is exactly why the next slide matters, but that capability has to come from somewhere and it has to be verified country by country rather than assumed.
Third party support. Four points, and judge it on the specifics rather than the reputation. It cuts the support bill, typically to around half of vendor maintenance, and on a large ECC estate that is a material annual saving that is entirely real. It covers legal and tax updates, because the good providers do deliver statutory changes for the countries they support, so verify your specific country list. It does not give you new SAP releases, so you are frozen, which is fine while you are deferring and does mean the transition still has to happen eventually. And it changes the vendor relationship, because you are leaving support, so you lose that leverage and that goodwill, and returning later is possible and usually costly. Let me give you the framing I actually use.
Guest analyst clip.
A good way to fund a transition, a poor way to avoid one. And the practical test is simply whether there is a transition being funded. If the third party contract sits alongside a dated programme plan, it is doing its job. If it sits alongside nothing, then what you have bought is not runway, it is just a cheaper way to stand still, and the risk keeps accumulating quietly in the background.
So, the four questions a board will ask, and one they should. What happens if we do nothing? Have a costed answer year by year, including the support premium, the skills cost and the date the regulatory risk becomes real. Why this route and not the other three? Show all four columns, because a case that presents one option looks like a decision that was made before the analysis, and boards notice that. What is the total over ten years? Subscription or licence, implementation, run cost, testing and the exit, with the same assumptions in every column, stated openly. What could go wrong and what would it cost? Migration overrun, standardisation failure, renewal repricing, each named with a number and an owner. And the one they should ask but usually do not: what does this decision cost us in year eleven? That is precisely where subscription and perpetual diverge most sharply.
Five traps. Comparing three years rather than ten, which flatters subscription and hides the renewal, because the differences live in years six to ten. Different assumptions per column, so optimistic growth in one route and conservative in another, and this is genuinely the most common flaw in the cases I am shown. Leaving on premise out, by assuming perpetual is gone so the only choice is which subscription, which removes your ownership option without anybody deciding to. Treating staying as free, with no line for the extended maintenance premium, the scarce skills or the regulatory exposure, because staying costs money too. And deciding on the deadline, meaning moving because of twenty twenty seven rather than because of a business case. The deadline sets your timing. It should never set your destination.
Last knowledge check, and there are two problems here rather than one. Your business case compares RISE against staying, over three years. What is the main flaw? A, three years is too short, and two routes are missing. B, nothing, since three years matches the planning horizon. C, staying should not be presented as an option at all. D, RISE cannot be compared to staying on a cost basis. Pause here.
A, and the two flaws compound each other. A three year window ends before the first renewal, which is where the subscription cost changes most, so it systematically flatters one column. And presenting two routes when four exist means GROW and on premise were eliminated without any analysis, which is a decision disguised as a comparison. B mistakes the planning horizon for the decision horizon, and these are commitments that outlive both. C is wrong, because staying is a legitimate option that has to be costed even when you reject it. And D is simply false, since everything on this slide can be costed including the risk, and a board expects exactly that. Let me explain why the three year case is so persistently misleading.
Guest analyst clip.
What happens in years six through ten, and why is that not on the page. Good question to carry with you. So, five things for running the decision well. Build all four columns, even the ones you will reject, because rejecting an option with a number beside it is analysis and rejecting it silently is not. Write the assumptions once: one page covering growth, discount rate, scope and timeline, used by every column, and circulate it before anybody sees a total. Separate timing from destination, because the deadline tells you when you must act and only the business case tells you where to go. Put a number on each risk, probability and impact however rough, because an unpriced risk is invisible in a spreadsheet and gets ignored in the room. And revisit annually, since prices, deadlines and your own estate all move, and a two year old case is a stale one.
Three sentences. There are four routes rather than two, because S four HANA on premise still exists and still preserves perpetual ownership, and staying on ECC is a legitimate option with a price rather than a failure to decide. Compare them over ten years on one page with a single set of assumptions, because a three year window ends before the first renewal and quietly flatters the subscription columns. And third party support is a good way to fund a transition and a poor way to avoid one, so use it to buy planned runway, verify the statutory coverage country by country, and price the risk rather than describing it. Next session starts the detailed work: reading and negotiating the RISE contract itself, clause by clause, and where the commercial traps are hidden in it.
Homework before session twenty five, about two hours, and this one produces something you can actually use. One, write the assumptions page: growth, discount rate, scope, timeline, headcount, on a single page, agreed before any option is costed. That discipline alone is most of the value. Two, cost the do nothing route, year by year out to twenty thirty two, covering the extended maintenance premium, the skills cost, and the date at which regulatory exposure becomes material for you specifically. Three, add the missing columns: if your organisation is looking at a case with two routes, build the other two, and it usually takes an afternoon. Four, get one third party quote even if you never intend to use it, because it prices your alternative to vendor maintenance and that is useful in every later conversation. And five, answer the year eleven question: what does each route cost in the year after the second term ends? Most cases have simply never been asked.
Five guides, all on redresscompliance dot com. RISE versus S four HANA on premise gives you the two column comparison in detail, and that is the core of today's table. SAP ECC end of maintenance twenty twenty seven and twenty thirty sets out the dates, the extended maintenance terms and exactly what stops. Third party SAP support evaluated expands slide eleven, including how to verify statutory coverage properly. Building the S four HANA business case takes the four board questions and works through the structure for each one. And the RISE pricing benchmarks are there for putting defensible numbers into the subscription columns, because a business case with invented pricing does not survive its first serious review.
That is session twenty four, and the end of the decision itself. Four routes, ten years, one set of assumptions, and every risk priced. Next time we get into the RISE contract clause by clause. See you then.