Greenfield, brownfield and selective, and a case that survives finance. 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, and this closes module four. Over the last four sessions we have covered the date, the FUE metric, the database and the conversion. Today we put them together into the decision itself, and I want to open with the thing that goes wrong most often. There are two decisions here, not one. There is a technical decision about how you move the system, which is greenfield, brownfield or selective. And there is a commercial decision about what happens to your contract, which is session nineteen. Those two get bundled into a single conversation constantly, they have different owners and different evidence, and bundling them is how both of them get answered badly. Three knowledge checks. Let's begin.
Five things by the end. First, separate the two decisions, because the technical migration path and the commercial licence route are different questions with different owners and bundling them costs money. Second, know the three paths: greenfield, brownfield and selective, what each one actually is, and which problems each is good at solving. Third, trace the licence effect, meaning what each path does to your user counts, your engines and your conversion credit, because those are not the same across the three. Fourth, build a defensible case: five components, and the difference between a case that survives finance and one that survives only the first meeting. And fifth, include the honest costs, which is the five lines that get left out of migration business cases and why leaving them out is what destroys your credibility later.
Four things to frame it. Technical: greenfield, brownfield or selective, which is how you move the system, and it is owned by architecture and the process owners. Commercial: contract conversion, product conversion or a new purchase, which is what happens to the paper, and it is owned by procurement and legal. Linked: they do interact, because the technical path changes your user counts and your engine footprint, and that changes what you buy. And not the same: different owners, different evidence, different timelines, so answering them as one question is how both get answered badly. Here is the framing sentence. The technical path is chosen for business reasons and the commercial route is chosen for contractual ones, and where they meet is a sizing question. That is the only place they should be discussed together. Let's play a clip on the boundary, because getting it right is what keeps you in the room.
Guest analyst clip.
Give them the number, do not give them the answer. That is the whole discipline in one line, and it is worth noticing that it makes you more influential rather than less. The moment you stop trying to own somebody else's decision, your numbers start being treated as information instead of as advocacy, and information gets used. So let's look at the three paths, on the understanding that we are pricing them rather than picking one.
Greenfield: a new implementation, standard processes, clean data, nothing carried over. It is the longest and most expensive route and it is the only one that genuinely removes accumulated customisation. Brownfield: a technical conversion of the existing system, keeping processes, data and customisation, which is the fastest and cheapest and it carries your history with it including the parts you dislike. Selective: a hybrid, where some entities or processes move new and others convert, which is flexible and the hardest to plan and to govern, and that governance difficulty is where its cost actually lives. And the fourth point, which matters most: none of these is chosen for licensing reasons. They are chosen for process, data and risk reasons, and then they have licensing consequences. I would add one caution about how these get presented. Be suspicious of any comparison that shows one path as obviously right for everyone, because the correct answer depends entirely on how much of your current process you actually want to keep, and only you know that.
So what does each path do to the numbers? Greenfield: you recount from scratch, which gives you the cleanest FUE number available, because nothing carries over and every band assignment is made deliberately. Conversion credit still applies and a new contract is likelier, which brings session nineteen's terms question straight back. Brownfield: it carries the current population and the current engine footprint across, so whatever you have now is what you are sizing, and conversion credit is the central mechanism. Selective: two populations to size, and double counting is a genuine risk, and both commercial routes may run in parallel so you have to watch the totals carefully. Now notice the tension on this slide. Greenfield gives the best licensing outcome for the worst project cost, and brownfield gives the reverse. That tension is real, and it is still not a reason to let licensing pick the path.
First knowledge check. Your migration lead proposes brownfield because it is fastest. What is the right licensing response? A, object, since greenfield produces a cleaner and cheaper licence position. B, accept the path, and size the licence position that comes with it. C, delay the decision until the entitlement baseline is complete. D, ask SAP which path gives the better conversion credit. Pause here and pick one.
The answer is B. The technical path is not yours to choose, and trying to choose it on licensing grounds is exactly how licensing people get excluded from the next conversation. Your job is to price the path accurately and early, and to say clearly what it will cost. A picks a fight you will lose on somebody else's ground, and you will lose it even when your arithmetic is right. C is obstruction dressed as diligence, because you can size in parallel and everybody knows it. And D invites the vendor to influence a technical decision inside your organisation, which is not in your interest even in the cases where their answer happens to be correct.
So, five components of a case that survives. The counterfactual: what staying costs, meaning extended maintenance, the uplift, the growing risk, and without this the case has no baseline to be measured against. The licence position both ways: what you pay today and what you pay after, including engines, database and indirect, which is session nineteen's arithmetic applied to each path. The one off cost: implementation, data, testing, training and the contingency, honest, and higher than the first estimate anybody gives you. The recurring change: support base before and after, infrastructure, and the operating model, and this is the number finance will still be looking at in year five. And the benefits, named and owned, each with a business owner who agrees to be measured on it, because unowned benefits are how a case gets approved and then quietly disbelieved. The first of those is the one that is missing most often. Let's hear why that is fatal.
Guest analyst clip.
A large cost against another large cost, rather than a large cost against nothing. That reframing is available to you for about a day of work, and the inputs are mostly things this course has already told you to gather. The maintenance uplift is in your agreement, from session sixteen. The database growth curve is in the quarterly memory report from session eighteen. The skills risk is a conversation with the application owner. Put those three on a page with dates and you have a counterfactual, and the entire case becomes easier to argue.
Second knowledge check. Which component do migration business cases most often get wrong? A, the implementation cost, since it is always underestimated. B, the counterfactual, meaning what staying actually costs. C, the benefits, since they are always overstated. D, the licence position after migration. Pause here before you continue.
The answer is B. Most cases compare a fully costed migration against an implicit assumption that staying is free, and staying is never free: it has an uplift, a rising database line, a skills risk and an eventual cliff. Without the counterfactual the case is a list of costs with no comparison, which is why finance either rejects it or approves it for the wrong reasons, and the second outcome is worse. A and C are both real and both entirely familiar, and everybody in the room already scrutinises them, which is precisely why they are less dangerous. And D is genuinely often wrong, and it is a component rather than the frame, so getting it right inside a case with no counterfactual does not save the case.
Now the costs that get left out, and I want to be clear that this is not usually dishonesty. They get left out because no single person owns them and they arrive late. Parallel running: two systems live at once during cutover, which means two sets of infrastructure and, depending on your paper, two sets of licences. Non production estate: development, test, quality and disaster recovery all need to exist in the new world, and each may carry its own entitlement, which session eighteen flagged for the database specifically. Integration rework: every interface touching the old system gets retested and often rebuilt, and each one is a document volume question from module three. And the year after: stabilisation, retraining and the optimisation nobody funded, all landing in the year the project is declared finished. Let's hear the argument for putting these in yourself.
Guest analyst clip.
A case you can still defend in year three. That is the standard, and it is a higher one than getting approval. I would add a practical trick for making the uncomfortable lines easier to accept: present them as ranges with named assumptions rather than as point estimates. A range invites a conversation about the assumption, which is a conversation you can win. A single large number invites a challenge to the number itself, which is a conversation nobody wins.
So, the order the decisions should be taken in, with owners. Your own date, owned by you from session sixteen, which settles when a decision is genuinely required. The technical path, owned by architecture and the process owners, which settles greenfield, brownfield or selective. The licence sizing, owned by you, which settles FUE, engines, database and indirect for that path. The commercial route, owned by procurement and legal, which settles contract conversion, product conversion or purchase. And the case itself, owned by the programme with finance, which settles whether it proceeds and on what evidence. Notice what happens if you invert steps two and three. Sizing before the path is chosen means sizing something nobody has decided to build, and every number you produce will be revised, which is how licensing figures acquire a reputation for being unreliable.
Five ways the case falls over. No counterfactual: comparing a costed migration to an implied free alternative, which is not a comparison at all. Benefits without owners: savings nobody has agreed to be measured on, approved once and believed never again. Licensing bolted on late: the licence position added after the case is written, so it appears as an overrun rather than as a planned line. One path modelled: a case for the chosen path with no comparison, which reads as advocacy and gets treated as advocacy, quite reasonably. And the deadline as the reason: building the case on twenty twenty seven rather than on value, and session sixteen explained at length why that argument does not survive a single competent question.
Last knowledge check. What is the single most useful thing a licensing specialist contributes to a migration business case? A, the lowest possible licence cost for the chosen path. B, an accurate licence cost for every path, produced early. C, a recommendation on which technical path to take. D, the negotiated discount, secured before the case is signed off. Pause here, and think about what the case actually needs from you.
B. Early and accurate beats late and optimised, because a number that arrives before the decision shapes it while a number that arrives after only explains it. A optimises one branch and leaves the comparison unpriced, which is the less useful half of the job. C is not your decision, and claiming it costs you the seat at the table, which is the first clip's argument. And D is genuinely valuable and it comes later, because you negotiate a requirement you have already defined, and that is the same ordering error the database session warned about when it said not to negotiate a block price before minimising the memory. Let's hear why the timing matters more than the precision.
Guest analyst clip.
Publish a range, name your assumptions, and be in the room. So, five things to own the licensing side of a case. Price all three paths, even the ones nobody is proposing, because it takes a day once the baseline exists and it makes you useful before you are asked. Keep the counterfactual live: the cost of staying, updated annually, so the comparison is available whenever somebody raises the question. One number, one owner: every licence figure in the case has your name against it, which means nobody else invents one, and somebody always will if you leave a gap. Show the range: a best and worst case on the licence line with the assumptions named, because a single figure invites false precision and then blame. And update on the same cadence as everything else, because the case is a living document for as long as the decision is open, and a stale number in it is worse than no number at all.
Three sentences, and then module four is complete. The technical path and the commercial route are two decisions with different owners, and the licensing job is to price each path accurately rather than to choose between them. Greenfield gives the cleanest licence position for the highest project cost and brownfield gives the reverse, with selective flexible and hardest to govern, and none of them is chosen for licensing reasons. And a case survives finance when it has a counterfactual, an honest set of one off and recurring costs, and benefits with named owners, and it fails when the deadline is used as the argument. Next session opens module five, which is RISE with SAP: what is actually inside the bundle, what leaves your control when infrastructure and operations move across, and the questions to ask before the shape of the deal is settled.
Homework before session twenty one, about ninety minutes. One, write the counterfactual: what does staying cost across the next five years, meaning the uplift, database growth and skills risk, on one page with real figures. Two, price the three paths: a rough licence cost for greenfield, brownfield and selective using your own baseline, and rough is completely fine, absent is not. Three, find the missing lines: parallel running, non production, integration rework, the year after, and simply ask whether any of them are in the current plan. Four, name the benefit owners: for each claimed benefit identify the person who would be measured on it, and then check that they know. And five, check the sequence: where is your organisation in the five steps on slide twelve? If licensing is not in that sequence yet, that is the thing to fix this week rather than any of the analysis.
Five guides, all on redresscompliance dot com. The S four HANA migration strategy guide covers the three paths in detail with the decision criteria for each, which is slide four expanded properly. The S four HANA conversion estimator lets you put real numbers against the paths using your own entitlement, which is most of the homework. The S four HANA or RISE migration report for twenty twenty six shows where the market is going and what that means for your comparison. RISE versus S four HANA on premise is the commercial comparison, and that is exactly where module five begins next session. And the ECC to S four HANA migration playbook is this whole module in written form, from the decision through to the conversion.
That is session twenty, and module four is done. You can now put a defensible number against every route out of ECC. Next time, module five, and the RISE bundle. See you then.