What 2027 and 2030 actually force, and what they only appear to force. 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 sixteen, and this opens module four, the S four HANA transition. Before any of the product detail, this session is about a date, because more bad SAP decisions get made under deadline pressure than for any other single reason I can think of. Two dates, actually. The end of twenty twenty seven, when mainstream maintenance on ECC ends, and twenty thirty, when extended maintenance ends. What we are going to do is establish precisely what each of those changes, precisely what neither of them changes, the four routes available to you, and then the part that matters most: how to build a date of your own, because the published dates are almost certainly not your dates. Three knowledge checks. Let's begin.
Five things by the end. First, know the dates precisely: what changes at the end of twenty twenty seven, what happens during extended maintenance, what happens after twenty thirty, and what does not change at any of them. Second, name the four routes: convert, RISE, extend, or third party support, and what each one commits you to. Third, separate support from licence, because a support phase ending is not a compliance event and that distinction is worth real money. Fourth, recognise the pressure, meaning the four ways a published date gets used commercially, and a specific answer to each of them. And fifth, build your own clock: five inputs that produce your actual date, which in my experience is almost never twenty twenty seven and almost never twenty thirty.
Four things to frame the session. Twenty twenty seven: mainstream maintenance on ECC ends, and support does not stop that day, it changes shape and it changes price. Twenty thirty: extended maintenance ends, and after that customer-specific maintenance becomes the default, which means continued support without new fixes or legal updates. Your date: the date your business actually needs something ECC cannot give it, which is derived rather than published, and which is rarely either of theirs. And leverage: a deadline you did not set, used to compress your decision, and owning your own timeline is the entire defence against that. So there are two clocks in this conversation. SAP's, which is published and fixed, and yours, which comes from your regulatory, business and infrastructure needs. Only one of them should drive the decision. Let's play a clip on that.
Guest analyst clip. I have sat through a great many of these conversations and there is a pattern to how they go wrong, and it starts with an unexamined assumption. Somebody says, we have to be off ECC by twenty twenty seven. And everyone nods, and the programme gets funded on that basis, and nobody ever asks the obvious follow up question, which is: why? What specifically happens to us on the first of January twenty twenty eight? And when you actually chase that down, the honest answer for most organisations is that their support cost goes up by a couple of points and they carry on. That is a real change. It is not an existential one. Now, here is why the distinction matters so much commercially. If you believe you have a hard deadline in twenty twenty seven, then in twenty twenty six you are a customer who has to sign something, and every negotiator on the other side of the table knows it. If instead you have done the work and you know your real constraint is, say, a tax reporting change in twenty thirty one, then you are a customer with five years of runway who is choosing when to move. Those two customers are offered very different prices for exactly the same thing. The difference between them is not budget or size or leverage in any conventional sense. It is one week of internal analysis that almost nobody does.
One week of internal analysis that almost nobody does. And notice that this is the same principle from module three in a different costume. Whoever produces the number first defines the conversation, and here the number is a date. If you arrive with your own date, supported by named owners and written reasoning, you are in a completely different negotiation from the customer who arrives with a countdown slide somebody else made. So let's get the dates exactly right first, because you cannot argue about a timeline you have half remembered.
Four rows, and I want to be precise about each. End of twenty twenty seven: mainstream maintenance on ECC ends, and what does not change is that your licences do not expire and the system keeps running exactly as it did on the thirty first of December. Twenty twenty eight to twenty thirty: extended maintenance, at an uplift on your support rate, and what does not change is that you still receive fixes and legal updates, you are simply paying more for them. After twenty thirty: customer-specific maintenance becomes the default, and what does not change is that support continues, but without new fixes and without new legal changes, which for most organisations is the point where it genuinely stops being viable. And any time: third party support is a route some customers take, and what it does change is that it ends the SAP support relationship, and that has its own cost which we will come to. One instruction. Read the uplift and the definition of customer-specific maintenance in your own agreement. A two point uplift on the support rate is commonly quoted, and the wording in your paper is what actually binds you.
Four routes, and each of these is a legitimate answer for some estates. Convert to S four HANA on premise: same deployment model, new product, conversion credits in play, and the FUE metric arrives with it, which is next session in full. Move to RISE: S four HANA Cloud private edition with infrastructure and services bundled into one subscription, a completely different commercial shape, and that is module five. Extend and use the time: pay the uplift and buy runway, which is entirely legitimate when the runway is genuinely spent preparing and expensive when it is not. And third party support: leave SAP maintenance, with real savings and real consequences, and it closes doors you may want open later, so cost it properly rather than dismissing it out of hand. The observation I would make about this slide is that extending is the route most often chosen and least often planned. Paying an uplift for two more years and arriving at twenty thirty in exactly the same position is the most expensive option here, and it is the one that gets chosen by not deciding.
First knowledge check. It is twenty twenty eight and you are still on ECC, paying for extended maintenance. What is your position? A, non compliant, since mainstream maintenance has ended. B, supported, paying an uplift, with your licences unaffected. C, unsupported, and you must move to customer-specific maintenance. D, in breach unless a conversion agreement has been signed. Pause here and pick one.
The answer is B. Maintenance and licence are different things, and confusing them is the most expensive mistake in this entire subject. Perpetual entitlement does not expire because a support phase does. A treats a support phase as though it were a compliance state, and I hear that conflation constantly, sometimes from people who should know better. C describes twenty thirty one rather than twenty twenty eight. And D invents an obligation that appears in no agreement I have ever read. Now, none of that makes waiting a good plan. It does mean that whatever urgency you feel should come from your own analysis rather than from a date on somebody else's slide.
So let's be balanced about it. What the deadline does force, and what it does not. It does force a decision date: at some point the support economics change materially, and you want to have chosen that moment rather than discovered it. It does force budget planning: every route costs money in a specific year, and finance needs that year named long before it arrives. It does not stop your system: ECC keeps running after twenty twenty seven and after twenty thirty, nothing switches off, and nobody in your organisation should be told otherwise. It does not void your licences: perpetual entitlement is perpetual, support is the thing with an end date, and the two travel separately. And it does not require RISE: conversion to S four HANA on premise remains available, and the two should be compared on their merits rather than one of them assumed. That third and fourth point together are where most of the manufactured urgency lives. Let's hear that argued.
Guest analyst clip. I want to separate two things that get deliberately blurred, and the distinction is worth a great deal of money. The deadline is real. I am not going to tell you it is invented, because it is not. SAP has published these dates, they have moved them once already, and they are unlikely to move them again in a way you can rely on. Plan for them. But the urgency attached to the deadline is a separate object, and it is largely constructed. Here is how you tell the difference. A real constraint has a mechanism. You can describe, in one sentence, what physically happens to you and when. My tax authority changes its filing format in twenty thirty one and customer-specific maintenance will not deliver that change, therefore I need to be on a supported product before then. That is a constraint. It has a date, a cause and a consequence. A manufactured urgency cannot survive that sentence. When you ask what specifically happens to us, you get adjectives instead of mechanisms. Exposed. At risk. Behind the curve. Left on legacy. Notice that none of those has a date or a mechanism attached, and notice how uncomfortable it is to ask the question in the room, which is precisely why it works. So my advice is simple. For every claimed consequence, write the mechanism sentence. The ones you can write are your plan. The ones you cannot write are somebody's quarter.
The ones you can write are your plan, the ones you cannot are somebody's quarter. I would make that a working document rather than a principle. Literally a page, with one line per claimed consequence, and the mechanism sentence written next to each one. In my experience you end up with two or three genuine constraints and a much longer list of adjectives, and the two or three genuine ones are what your programme should actually be built around.
Second knowledge check. Your account team says the conversion credits expire with the deadline. What do you do? A, accept it and accelerate, since the credits are worth real money. B, ask for the credit terms in writing and check them against your paper. C, ignore it, since everything is negotiable at any time. D, wait until nearer the date, when the offer should improve. Pause here before you continue.
The answer is B. Conversion credit terms are commercial programme policy rather than contract, which means they can change, they can be extended, and the only way to know what applies to you is to read it. A acts on an unverified claim, which is precisely the behaviour the pressure is built to produce, and it is a very effective piece of pressure because the credits genuinely are valuable. C is nearly right and it is overconfident, because some programme terms genuinely do end and assuming otherwise will eventually cost you. And D bets on the vendor's calendar rather than deciding anything, and an offer made near a deadline is shaped by their quarter rather than by your readiness.
So how does the date actually get used? Four patterns, and an answer to each. The countdown slide: a timeline with your logo on it and a narrowing window, and the answer is to replace it with your own timeline built from your own dependencies. The expiring incentive: credits or discounts tied to a signature date, and the answer is to ask in writing what happens the day after, while noting that these programmes are routinely extended. The bundled decision: conversion, cloud move and new products presented as a single choice, and the answer is to separate them and price each on its own merits. And the risk framing: unsupported, exposed and non compliant used more or less interchangeably, and the answer is to get precise about which of those is true and from exactly which date. None of this is bad faith, by the way. It is a competent sales motion built on a real date. Let's hear how to answer the first one properly, because it is the most effective of the four.
Guest analyst clip. The countdown slide is the single most effective artefact in enterprise software sales, and I want to explain both why it works and what actually defeats it. Why it works is psychological rather than logical. It is a picture of time running out with your company's name on it, and it gets shown to your executives, who are not licensing specialists and who reasonably assume that a vendor timeline is a statement of fact. By the time it reaches you, the date is no longer a claim to be examined. It is background. It is the shape of the room. Now, what does not defeat it is arguing. If you stand up in that meeting and explain that perpetual licences do not expire and that customer-specific maintenance exists, you will be technically correct and you will sound like the person slowing things down. I have watched capable people lose that argument while being entirely right. What does defeat it is a second timeline. Not a rebuttal, a document. Your own dates, your own five inputs, a named owner against each one, and a recommended decision date at the end. Put that on the table next to theirs. You have not contradicted anybody. You have simply changed what the meeting is about, from when must we move to which of these two analyses is better. And yours has owners' names on it, and theirs does not.
Not a rebuttal, a document. That is the practical technique and I would take it beyond this session, because it works anywhere you are handed somebody else's framing. Arguing against a slide puts you in the position of the obstacle. Producing a better slide puts you in the position of the analyst. Same content, entirely different reception, and the second one is also just more useful, because at the end of it you have a plan rather than a disagreement. So let's build that document.
Five inputs, and each has an owner who is not you. Regulatory change: what legal or statutory updates will you need after twenty thirty, and that is a question for finance and tax, not for IT. Business roadmap: what is planned that ECC genuinely cannot support, which the process owners answer, and be strict about the word genuinely. Infrastructure: when do the hardware, the operating system or the database run out of runway, because those have their own end dates and they are frequently earlier than SAP's. Skills: when do the people who actually understand your ECC estate retire or leave, which the application owner knows and which is a real constraint that almost never appears on any plan. And contract dates: when is your next renewal or major transaction with SAP, because that is when the commercial window opens, and procurement owns that. Put those five answers together and you have a date. It is usually neither twenty twenty seven nor twenty thirty, and it is the only date that should drive a decision of this size.
Five traps. Treating support end as system end: the most common error in the subject, and the one that produces panic buying at the worst possible moment. Extending without a plan: paying the uplift for two years and then arriving at twenty thirty in precisely the same position, with less money and less time than you started with. Letting the date bundle the decision: conversion, cloud and new products signed together because one deadline was pressing on one of the three, and the other two came along for the ride. Skipping the entitlement baseline: converting without knowing what you own, which throws away conversion credit you were entitled to, and session ten exists precisely for this. And having no internal date: with no timeline of your own, the vendor's timeline becomes your plan by default, and the thing about defaults is that nobody ever decided them.
Last knowledge check. Which single piece of work most improves your position before any S four HANA conversation? A, a technical readiness assessment of the ECC system. B, a current entitlement baseline: what you own, what you use, and the gap. C, a cost comparison between RISE and on premise. D, an internal communication plan for the migration. Pause here, and think about what every other number depends on.
B. Conversion is priced against what you already own, so the baseline is the input to every other number in the conversation, including the credits. A matters and it comes second, because a readiness assessment tells you effort rather than cost. C cannot be done accurately without B, because both options are priced off your existing entitlement, so a comparison built without it is a comparison of two guesses. And D matters a great deal for delivery and changes nothing whatsoever about your commercial position. Let's hear why the baseline is the thing, because this is the third module in a row it has come up and there is a reason for that.
Guest analyst clip. I want to explain why the entitlement baseline keeps reappearing, because from the outside it looks like an administrative document and it is not. Here is what happens in a conversion. Your existing licences are exchanged for new ones. What you receive is calculated from what you currently hold. So the value of your position on the day of that conversation is a direct function of how well you can describe what you own. Now consider the two customers. The first has a baseline that is eighteen months old, assembled once for an audit, and nobody is quite sure whether the acquisition from last year is in it. When the conversion proposal arrives, that customer is essentially accepting the vendor's arithmetic, because they cannot check it. And the vendor's arithmetic is not dishonest, it is simply built from what the vendor can see, which is not everything you own. The second customer has a current baseline, reconciled against signed contracts, with a named owner. When the proposal arrives they can say, this line understates our engine entitlement, here is the amendment from two thousand and nineteen. And that conversation is worth real money, sometimes a great deal of it, and it takes about twenty minutes because the work was already done. Same product, same programme, same discount percentage. Very different outcome, decided months earlier by whether somebody kept a document up to date.
Decided months earlier by whether somebody kept a document up to date. So, five things to own the timeline. Publish your own date: one internal date, derived from the five inputs, owned by a named person and revisited once a year. Keep the baseline current: session ten's document, refreshed, because conversion credit is calculated from what you own and a stale figure understates it. Price all four routes annually: convert, RISE, extend, third party, on one page, updated, so that nobody has to build that comparison under time pressure. Log every deadline claim: what you were told, by whom, on what date, because programme terms move and a log is how you notice that they moved. And keep the decisions separate: product, deployment model and new capability are three questions, so answer them as three, whatever shape they arrive in.
Three sentences. The twenty twenty seven and twenty thirty dates change how support works and what it costs, and neither of them switches off your system or voids a perpetual licence. Four routes exist, convert, RISE, extend or third party support, and extending is the one most often chosen and least often actually planned. And build your own clock from regulatory need, business roadmap, infrastructure, skills and contract dates, because that date is the only one that should drive a decision this large. Next session we get into the product itself: S four HANA licensing on premise, the FUE metric and how it differs from the named user model you learned in module two, and what a conversion actually does to the entitlement you already hold.
Homework before session seventeen, about an hour, and most of it is other people's answers rather than your analysis. One, find your maintenance clause: what your agreement says about support phases, the uplift, and what customer-specific maintenance actually covers in your case. Two, ask the five clock questions, one each to finance, the process owners, infrastructure, the application owner and procurement. Short questions, and ask for written answers. Three, write your date: one date, one paragraph of reasoning, one named owner, and that page is what you put next to any countdown slide you are ever shown. Four, check the baseline is current, meaning session ten's document, and if it is more than a year old it is not usable for conversion pricing, so refreshing it is the highest value hour available to you right now. And five, start the claim log: every statement you have been given about deadlines, credits and expiry, with the date and the source beside each one.
Five guides, all on redresscompliance dot com. The twenty twenty seven deadline licensing strategy covers the commercial strategy behind the date and how to plan against it, which is this session in written form. Whose clock is it takes slide twelve further, with the specific internal questions to ask and who should answer them. The ECC end of maintenance strategy guide sets out the support phases in detail and what each one costs, which is the arithmetic behind slide four. Extended maintenance versus third party support costs the fourth route honestly on both sides, and it is worth reading even if you have already decided against it, because knowing what you are declining is part of the negotiation. And the ECC to S four HANA migration playbook covers the route most customers take, from decision through to conversion, which is where the next four sessions live.
That is session sixteen. If you take one thing from it, take the mechanism sentence: for every claimed consequence, write what happens, when, and why. Next time, the FUE metric and what conversion does to your entitlement. See you then.