Contract conversion against product conversion, and the credit arithmetic. 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 nineteen, and this closes module four. Sessions sixteen to eighteen were all preparation: the date, the user model, the database. Today is the transaction itself, which is the licence conversion to S four HANA, and I want to start by naming what it actually is. A conversion is not a purchase. It is an exchange of contracts. Your existing entitlement goes in one side and a new agreement comes out the other, and the credit you receive is only half of what changes. The other half is the paper you are now living under. Two routes, one credit calculation, and one decision that turns entirely on how good your current contract is. Three knowledge checks. Let's begin.
Five things by the end. First, name the two routes: contract conversion against product conversion, what each one exchanges, and the trade between them. Second, build the credit base, meaning how conversion credit is calculated from what you already own and the five inputs that go into it. Third, price what you surrender, which is the five things that change when the contract itself is exchanged, some of which are worth considerably more than the credit. Fourth, use the shelfware, because a conversion is the one moment when entitlement you never deployed is genuinely worth money. And fifth, sequence the work: five steps, four of which happen before any number is discussed, because a conversion is decided in the preparation rather than in the meeting.
Four things to frame it. Two routes: contract conversion exchanges the whole agreement, while product conversion swaps individual products and leaves the rest of the paper alone. Credit: what you receive is calculated from what you already hold, which makes session ten's baseline the direct input to the number. New terms: contract conversion moves you onto the current price list and the current terms, and that is the largest effect and the least discussed one. And one way: conversions are not reversed, so whatever you accept becomes the agreement you live under for the next decade. Here is the sentence for the session. The discount is negotiable and the terms are the deal. Let's play a clip on that, because I think this is the single most misunderstood transaction in SAP licensing.
Guest analyst clip. I want to describe how a conversion is usually framed, and then how it should be. It is presented as a product decision. You are on the old product, there is a new product, here is what it costs to move, here is a credit for what you already have. Everybody in the room understands that conversation, and it feels like an upgrade. Now here is what is actually happening. Your existing contract, which may be fifteen or twenty years old and which contains every concession anybody at your organisation ever won, is being terminated and replaced. The metric definitions change to whatever the current price list says. The audit clause changes. Any cap you negotiated in two thousand and fourteen after a difficult year, gone unless somebody specifically carries it forward. Any indirect access settlement, replaced by whatever the new paper says about indirect access. None of that is hidden and none of it is announced either, because the conversation is about products. So my advice is to insist, internally, that this is treated as a contract negotiation and not a product migration. Different people in the room. Legal reads the old agreement before anybody discusses a credit. Because the credit is a one off number and the terms are what you live inside for the next ten years, and those are not comparable things.
Treat it as a contract negotiation and not a product migration. That is a governance instruction as much as a licensing one, and the practical version is simple: whoever reads contracts in your organisation should see the old agreement before anybody sees a credit figure. If the first document in the room is a proposal, the framing is already set. So let's look at the two routes, because the difference between them is exactly the difference between keeping your paper and trading it.
Contract conversion: the whole agreement is exchanged for a new S four HANA contract, typically the better credit, and everything moves to current terms and the current price list. Product conversion: individual products are swapped and the rest of the contract stays as it is, so less credit, far less disruption, and your existing terms survive intact. The trade: more credit for new terms, or less credit for old terms, and that is genuinely the whole choice. And read the old contract first, because you cannot value what you are giving up until you know what is in it, which makes session four's contract library the prerequisite for this entire decision. Let me put the point sharply. If your agreement contains favourable terms won in earlier negotiations, a contract conversion surrenders them in exchange for a discount. Sometimes that is the right trade, genuinely. It should never be an accidental one, and in my experience it very often is.
So how is the credit built? Five inputs. Licences you own: the value base the credit is calculated from, and you check every licence including the ones nobody has ever used. Shelfware: it counts in the base whether deployed or not, which means that unused entitlement finally has somewhere to go. Maintenance history: continuity of support can affect the offer, so check for any lapsed lines and what that does to eligibility. Product mapping: which S four HANA item each old licence becomes, and you want that mapping table line by line before anybody shows you a total. And programme terms: policy rather than contract, so they move, and you want them in writing with an end date, exactly as session sixteen said about deadlines. Now, the fourth of those is where the money is. A total figure hides a hundred line level decisions, and disputing a total is impossible while disputing a single line is completely straightforward.
First knowledge check. You hold five hundred unused Professional licences from an acquisition. What are they worth in a conversion? A, nothing, since they are shelfware and that money was wasted. B, they contribute to the credit base, so they have real value here. C, only if you deploy them before the conversion happens. D, only under product conversion, not under contract conversion. Pause here and pick one.
The answer is B. Conversion credit is calculated from what you own rather than from what you use, which makes a conversion one of the very few moments where shelfware is worth something. A is the usual assumption and it leaves real money on the table, and I would guess it is the most expensive wrong assumption in this module. C invents a deployment condition that does not exist, and deploying them would achieve nothing except a larger measured population, which is actively worse. And D reverses the position, because a contract conversion is generally where a large unused holding does the most work. The instruction is simple: count everything you own before anybody prices anything.
Now the other half of the deal: five things that change when the contract is exchanged. The price list version: you move to the current one, which can redefine metrics you have been reading under older definitions, and session four explains why that matters so much. The metric definitions: a named user type or an engine metric can be worded differently in the new paper, and nothing announces the change to you. Your negotiated terms: caps, exclusions, favourable audit clauses and price protections won over years all go, unless each one is carried forward explicitly. The maintenance base: support is recalculated from the new entitlement, so ask for the before and after figure exactly as session fourteen said. And the indirect access position: any settlement, definition or exclusion you had may simply be replaced by whatever the new agreement says. Let's hear why that list is worth pricing properly.
Guest analyst clip. I want to give you a way of pricing the terms you would surrender, because people find that hard and so they skip it, and skipping it is how a bad conversion gets signed. Take each favourable clause you hold and ask one question: what would it cost me if this clause were not there? A price increase cap. If you have one, work out what your costs would have been over the last five years without it, and project the same forward. That is a real number, it is usually large, and it is defensible because it is your own history. An audit frequency limit. Estimate what an audit costs you in internal effort and settlement risk, and multiply by the extra audits you would be exposed to. An indirect access exclusion negotiated after a dispute. Ask what the exposure was before you got it, because somebody once calculated that, and it will be in a file. Now add those up and compare the total to the one off credit. Sometimes the credit still wins, and then you have made a good decision with your eyes open. But quite often you find that a clause somebody won years ago is worth several times the discount you were about to accept it for, and nobody had noticed because nobody had ever put a number against it.
Nobody had ever put a number against it. That is the gap this session is trying to close, and I would make it a standing document rather than a one off exercise. One page, every favourable clause you hold, with a rough annual value beside it. It takes an afternoon, it is useful in every renewal and not only in a conversion, and it means the trade is visible at the moment somebody offers you a discount for it.
Second knowledge check. You are offered a strong credit under contract conversion. What do you check before accepting? A, the discount percentage against market benchmarks. B, which existing terms you give up, priced across the term. C, the implementation timeline and resourcing. D, whether the credit covers your full FUE requirement. Pause here before you continue.
The answer is B. A conversion exchanges terms as well as products, so the real question is what the surrendered terms were worth, and a price cap or a favourable audit clause can be worth more across a decade than the credit is worth once. A is worth doing, and it comes after B, because benchmarking a discount tells you nothing about what the discount cost you. C matters a great deal for delivery and nothing for the commercial position. And D is a genuinely important sizing question and a separate one, because a credit that happens to cover your requirement is not evidence that the deal is good. It is only evidence that the arithmetic closes.
Now the happier part of the session. Shelfware. It counts: unused licences contribute to the credit base, so everything session ten catalogued becomes an input rather than something to apologise for. Find it first: you cannot trade entitlement you cannot evidence, and the vendor's record of what you hold may not match your own. Do not deploy it: deploying shelfware ahead of a conversion raises your measured position and changes nothing at all about the credit. And do not lose it quietly: products dropped from the mapping table simply vanish from the credit base, so check specifically for what was left out rather than only reviewing what was included. This is the real argument for keeping a complete baseline, including products you regret buying. Let's hear that properly.
Guest analyst clip. There is a moment I enjoy in this work, and it is watching somebody realise that their worst purchase has become useful. Every large SAP customer has entitlement it never deployed. A module bought for a programme that was cancelled. Licences from an acquisition whose systems were retired. Something a predecessor bought under pressure in a bad quarter in two thousand and seventeen. Nobody talks about those. They sit in the contract quietly embarrassing everybody, and the standard organisational response is to stop counting them, because counting them means explaining them. And then a conversion comes along and the credit is calculated from what you own. Suddenly every one of those lines is worth something. The module nobody deployed contributes. The acquired licences contribute. That bad quarter contributes. I have seen unused entitlement account for a substantial share of a conversion credit, and I have also seen it left out entirely, because the baseline the customer brought to the meeting only listed the things they were actually using. So keep the complete list. Not the useful list, the complete one. For nine years it is a record of mistakes, and in the tenth year it is money, and you cannot reconstruct it in the three weeks before a signature.
Not the useful list, the complete one. And notice this reframes something from module two. Session eight told you to find dormant users and remove them, because dormant users cost you money in a measurement. Shelfware is the opposite: unused entitlement costs you nothing in a measurement and pays you in a conversion. Those are not contradictory, they are two different objects. Clean up the consumption. Keep the entitlement, and keep the record of it.
So, the order of the work. Refresh the baseline: everything you own with evidence, and it comes first because it is the credit base and it therefore decides the total. Read the old contract: the list of terms you would surrender, which you need before you can price the trade at all. Get the mapping table: line by line, old product to new, because totals hide the decisions that actually matter. Model both routes: contract and product conversion, both costed, because the comparison between them is the negotiation. And price the recurring line: maintenance base before and after, because the one off is what gets presented and the recurring is what you live with. Look at the shape of that list. Four of the five steps happen before any number is discussed. A conversion is decided in the preparation, and the meeting only confirms which side prepared better.
Five traps. Converting on the vendor's mapping: accepting a mapping table without checking it line by line, so quiet omissions become permanent the day it is signed. Surrendering terms for a discount: trading a decade of price protection for a one off credit, with neither of them priced against the other. Leaving shelfware out: products you had written off omitted from the credit base, because nobody went looking for entitlement they had stopped counting. Ignoring the support base: a good credit and a higher recurring cost, which nets out badly around year four and is very hard to undo. And converting under a deadline: doing the largest contractual reset of the decade in the last three weeks of somebody else's quarter, which is a sentence that should need no further comment.
Last knowledge check. Which route is better: contract conversion or product conversion? A, contract conversion, since the credit is larger. B, product conversion, since your existing terms survive. C, it depends on how good your current agreement is. D, whichever the account team recommends, since they model both. Pause here, and think about what the trade actually is.
C. The trade is more credit for new terms against less credit for old terms, so the answer turns entirely on the value of what you currently hold in writing. An organisation with a weak, old, generic agreement often gains a great deal from contract conversion, and should probably do it. One with hard won caps and definitions frequently does not. A and B each state one half of the trade as though it were the whole answer, and both are the kind of confident half truth that gets repeated in meetings. And D outsources a decision that depends on your paper to a party that has not read it with your interests in mind, which is not an accusation, it is just a description of whose job it is. Let's hear how to actually make the choice.
Guest analyst clip. Let me give you a practical way to make this decision, because it depends on your paper and that is not a useful answer on its own. Do this. Take your existing agreement and go through it looking for anything that is better than standard. Not everything, just the parts a lawyer would call negotiated. Price increase caps. Audit terms that limit frequency or scope. Metric definitions that are more favourable than the current price list. Any exclusion or settlement you fought for. Territory or entity language that lets you use licences somewhere the standard terms would not. Write them down. Now, if that list is short or empty, which for many customers it genuinely is, then contract conversion is probably right for you, because you are surrendering almost nothing and receiving a larger credit for it. Take the money. But if that list is long, and particularly if it contains a price cap or a favourable indirect access position, then you are looking at a very different calculation, and product conversion deserves serious modelling even though the credit is smaller. The thing I would most like you to avoid is doing this decision by instinct or by whichever option arrived with the bigger number on it. It is an arithmetic question, and the inputs are all sitting in a contract you already own.
It is an arithmetic question and the inputs are sitting in a contract you already own. So, five things to stay ready for a conversation you did not schedule. Baseline current before any approach: the credit base is your evidence and it goes stale within a year, so refreshing it is the highest value preparation available. Keep a terms inventory: one page listing every favourable clause you hold, so you can price what a contract conversion would actually cost you. Line by line, always: never accept a total, because the mapping table is the negotiation and a total is a way of not having one. Model both routes annually: so the comparison already exists on the day there is pressure to choose rather than being built under that pressure. And recurring cost in every model: support base before and after, per session fourteen, because that is the number that compounds across the whole term.
Three sentences. A conversion exchanges a contract and not just a product, so the credit is only half the deal and the terms you surrender are the other half. Credit is calculated from what you own rather than from what you use, which makes a conversion the one moment when shelfware is genuinely worth money. And contract conversion buys more credit with new terms while product conversion keeps your old terms for less credit, so which is better depends entirely on how good your existing paper is. Next session closes module four properly: the business case and the migration paths, greenfield, brownfield and selective, what each one does to your licence position, and how to build a case that survives contact with finance.
Homework before session twenty, about ninety minutes. One, refresh the credit base: everything you own including what you never deployed, with a line of evidence against each entry. Two, write the terms inventory: every favourable clause in your current agreement, on one page, and that page is what a contract conversion would cost you. Three, ask for a mapping table, even hypothetically, because seeing how your products map is instructive long before you have any intention of converting. Four, get the support base, meaning the current annual maintenance figure, so that you can compare before and after rather than after only. And five, decide which route you would want and write one paragraph of reasons. Then revisit it when an offer actually arrives, and check whether the offer changed your reasoning or only your mood.
Five guides, all on redresscompliance dot com. The S four HANA conversion estimator lets you model the credit and the cost against your own entitlement, which is the homework in tool form. The S four HANA migration strategy guide covers the routes and the sequencing end to end. S four HANA migration negotiation covers the commercial terms worth pushing on during a conversion, which is the practical companion to slide eight. The ECC to S four HANA migration playbook takes you from decision through to conversion with the checkpoints named, and it is the written version of this whole module. And the S four HANA licensing guide describes what you end up holding once the conversion is finished, which is worth reading before you agree to it rather than after.
That is session nineteen, and module four is nearly done. The habit to take away is the terms inventory: one page, every favourable clause, with a number beside it. Next time, the business case and the migration paths. See you then.