Trading support streams for subscriptions, the fate of the perpetual estate, and the point of no return. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
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. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle 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 of thirty, and the finale of module four. We have spent four sessions learning to buy Oracle SaaS well: the metrics, the order, ERP, HCM. Today is the session about the decision underneath all of them, the migration itself, moving the on premises application estate, EBS, PeopleSoft, JD Edwards, Siebel, Hyperion, to the Fusion cloud. This is the largest single trade an applications estate ever makes, and it is genuinely a trade: you hold a support annuity Oracle already owns, they want a subscription that grows, and the exchange rate between those two things is negotiable in exactly one window. Today: the anatomy of the deal, the fate of the perpetual licenses you spent decades buying, the sequencing that keeps your fallback alive, the ten year business case built honestly, and the migration as the biggest piece of negotiating capital you will ever hold. Let's trade carefully.
Five takeaways. One, the trade: what a migration deal actually is, a flat support annuity exchanged for a growing subscription, and why that asymmetry of motivation is worth money to you. Two, the estate's fate: the three places every perpetual license ends up, kept and supported, kept unsupported, or terminated for value, and what each choice forecloses. Three, the sequencing: when support ends relative to go live, who funds the parallel run, and the rule that the fallback stays alive until the new system has survived a full business cycle. Four, the honest case: subscription forever versus support forever, over ten years, with real uplifts, the reimplementation, and the parallel run actually on the page, because the year one slide is flattering and wrong. And five, the leverage: a migration decision is the single largest card in the applications estate, and it is spent the moment Oracle knows it is decided, so we spend it deliberately. Module four's finale earns its place: everything from sessions sixteen through nineteen gets used at once here.
The anatomy, five elements on the table. The estates: EBS, PeopleSoft, JDE, Siebel, Hyperion, moving to Fusion ERP, HCM, CX, EPM, and say the quiet part immediately, this is a reimplementation, not an upgrade, new data models, new processes, new integrations, price it as the program it is. The support annuity: the twenty two percent stream on the perpetual estate, paid for decades, flat, predictable, and already Oracle's, this is what you bring to the table. The migration programs: customer to cloud style offers where support spend gets credited toward the subscription, real money with conditions, and the conditions, which spend qualifies, over what period, against which SKUs, are where those programs get read carefully. The incentives: discounts, implementation funds, quarter end sweeteners, all priced against the leverage you surrender at signature. And the subscription itself: everything from the last four sessions, the metrics, the scoping, the clauses, applied at estate scale simultaneously. Now the seller's arithmetic, because understanding it is your advantage: your support stream is mature, flat, and won, their subscription grows and compounds. Oracle is trading a maturing asset for a growing one, they want this trade structurally, every year, at every account. Which means the migration buyer negotiates from a position no renewal buyer ever sees. Remember that when the incentives are dangled: they are dangling them because they want this more than you need it this quarter.
The fate of the perpetual estate, three destinations. Destination one, kept and supported: licenses still running workloads, or held as the migration fallback, support continues, nothing changes until you decide it does, and the fallback estate stays exactly here until the new system proves itself, that is a rule we will defend at length. Destination two, kept with support terminated, and here is the distinction decades of sales conversations have deliberately blurred: perpetual rights survive support termination. You may run the software, unsupported and unpatched, forever, that is what perpetual means, and it is the standard pattern for read only legacy access, a whole check on it shortly. But, and this trap has teeth: support terminates per license set, and partial termination lets Oracle reprice the support that remains, the matching service levels problem, discounts recalculated, the saving quietly clawed back. Model the entire support ledger before terminating anything, set by set, not line by line. Destination three, terminated for value: licenses surrendered as part of the migration deal in exchange for credits or discount, and once gone, gone, no fallback, no reversal, and if you dropped support and want it back later, reinstatement means back support plus penalties, the door is priced to stay shut. Three destinations, and the whole art of this session is refusing to move anything to destinations two or three prematurely. First check, the parallel run.
First check. An eighteen month Fusion migration replaces EBS. During the build you pay EBS support and the Fusion subscription simultaneously, the parallel run. The proposal has the subscription starting at signature, full quantity. Who should fund the overlap, and how? A, you, parallel running is a normal cost of migration. B, largely Oracle: a ramp starting subscription fees at go live milestones, plus migration program credits against the support paid during the build, negotiated at signature. C, terminate EBS support at signature to fund the subscription. Or D, delay the subscription signature until the build is done. Pause here. Session seventeen's ramp arithmetic, applied to a migration. And ask of option C: what does that leave you running the build on?
The answer is B, and the logic flows straight from the anatomy slide: the overlap is real, but its allocation is negotiable, and the party that wants the trade funds the friction. Oracle wants this trade. B combines the two standard instruments. The ramp, session seventeen's clause doing migration duty: subscription quantities stepping up at deployment milestones, pilot pricing during the build, full population from go live, which alone removes most of the double payment. And the migration credits: support spend during the transition offset against subscription fees, which Oracle's own customer to cloud style programs exist to provide, with conditions you read before counting the money. A simply accepts the vendor's preferred deal shape at list. D surrenders the leverage: the signature is the moment Oracle is hungriest, delay it and you buy the subscription later as an ordinary customer with the migration already public. And C, terminating EBS support at signature to fund the subscription, deserves to be named as what it is: running an eighteen month build on an unsupported fallback. No patches, no fixes, no safety net, under the one system your business is actually operating on, to save money that B gets Oracle to fund anyway. Our guest analyst watched a client take exactly that door, and the story is worth more than any slide, so let's set the table for it: the sequencing.
The sequencing table, five steps, and what each one forecloses. Step one, sign the subscription with the ramp and the credits, keep all support running: nothing foreclosed, every option open, this is the safe harbor. Step two, go live, and then run the first full business cycle on the new system, a year end close, a payroll year, a peak season, whatever your business's real test is: still nothing foreclosed, the fallback still works. Step three, terminate support on the replaced estate, whole license sets at a time with the repricing modeled: this is the first one way door, cheap return ends here, reinstatement now means back support plus penalties. Step four, terminate or surrender the licenses themselves: the second one way door, the fallback ceases to exist. Step five, decommission, with data retention solved separately, and if retention was not designed, access to your own history forecloses with it. The discipline of this slide is a single sentence: the one way doors are steps three through five, and none of them gets walked through early, however attractive the incentive attached, until the new system has survived a full cycle. Sellers will attach incentives to early termination, that is precisely the point of the incentives. Our guest analyst, on what the early door costs.
Guest analyst The client I think about every time a migration deal crosses my desk was a distribution company, PeopleSoft to Fusion HCM and payroll, and by the time they called me the damage was already signed. The original deal had a sweetener: an extra six points of subscription discount in exchange for terminating PeopleSoft support at signature, not at go live, at signature. The account team's framing was elegant, you are leaving anyway, why pay for support on a system you are abandoning? The CFO took it. Then the program did what programs do: the payroll implementation slipped eleven months, and the company ran PeopleSoft payroll, unsupported, through an entire tax year end. A statutory tax table change landed mid year, the kind that arrives as a support patch, except there were no patches anymore. They hand built the tax updates with contractors at roughly four hundred thousand, carried the compliance risk of self maintained payroll calculations, and when a critical bug surfaced in year end processing, they had no vendor to call. Total cost of the six points of discount: about one point one million, plus a quarter of sheer fear. Here is the arithmetic that should have happened at signature: the sweetener was worth about seven hundred thousand, and the insurance it replaced, supported payroll under the running system, was priceless during exactly the window they sold it. My rule since, and I give it to every migration client on day one: the fallback stays fully supported until the new system has survived one complete business cycle, a full close, a full tax year, a full peak. Any incentive offered for terminating early is the vendor buying your safety net from you, and they are never paying what it is worth.
Six points of discount, one point one million in costs, and an unsupported payroll system through a tax year end. Any incentive for early termination is the vendor buying your safety net, below its price. The fallback survives until the new system survives a full cycle, no exceptions. Second check.
Check two, the read only estate. After Fusion go live, you keep EBS running read only for seven years of transaction history and audit access. Compliance asks whether this is allowed and what it should cost. The answer: A, not allowed, unsupported Oracle software may not be run. B, allowed: perpetual licenses permit running the software after support termination, unpatched and unsupported; the license cost is near zero, but check the repricing effect on your remaining support, and solve archival access properly for the long term. C, allowed only if you keep paying full support on the EBS estate. Or D, allowed only through a special Oracle read only license. Pause here. What exactly does support termination end, and what does it not end?
The answer is B, and it rests on the distinction from the estate slide, the one worth repeating until it is reflexive: the perpetual license is the right to run the software, support is a separate annual purchase, and terminating the second does not touch the first. Running EBS read only on terminated support is lawful use of licenses you own, at near zero license cost, and it is the standard post migration pattern for history access. The two real caveats are inside B, and they are practical, not legal. First, the repricing effect: terminating the EBS support sets interacts with the pricing of every support set that remains on your ledger, so you model the termination across the whole ledger before executing it, this is the third time this course has said that and it will not be the last. Second, unsupported means unsupported: no security patches ever again, so the read only estate gets network isolated as a matter of hygiene, and for a seven year retention window, honestly evaluate the archival alternative, extracting the history into a queryable store and decommissioning the stack, because keeping a full application platform alive into its second unpatched decade is a security finding waiting for its audit. A is the myth that keeps support streams alive years after their workloads died, and it transfers money from your budget to no one's benefit. C pays full price for zero service. D invents a SKU that does not exist. Terminate the support, keep the rights, isolate the system, plan the archive.
The business case, honestly, and the slide contrasts two comparisons. The wrong one, which is also the one in most board decks: year one subscription, discounted and ramped, against this year's support bill. It flatters the migration three ways at once, the discount is at its deepest in year one, the uplift has not started compounding, and the reimplementation program is on a different slide. The right one: ten years, both paths, everything on the page. The SaaS path: subscription with realistic uplifts, capped if you negotiated the cap, uncapped if you did not, plus the reimplementation, plus the parallel run. The stay path, priced with equal honesty: support with its own uplifts, plus the real costs of staying, aging infrastructure, scarce skills, the platform risk of software drifting out of its era, and, tell the truth here too, an eventual forced modernization anyway, because indefinitely is not a strategy. The honest conclusion, most times I have run this: the migration still wins, on capability and on retiring platform risk, but it wins by far less than the year one slide claims, and knowing the true margin is what funds the negotiation. One structural fact deserves italics: the subscription is forever. There is no year in which Fusion becomes paid off, no asset accretes, which is exactly why the renewal cap and swap rights from session seventeen matter more in a migration than anywhere else in this course. Last check does this arithmetic with real numbers.
Setting up the last check with the leverage slide still to come, here is the scenario. The migration business case shows year one Fusion at two point one million against current EBS support of two point four million, presented as a saving. Over ten years with a six percent annual uplift and no cap, plus a nine million reimplementation and eighteen months of parallel run, the honest picture is: A, still a saving, year one proves the trajectory. B, roughly twenty seven million of subscription against roughly twenty eight million of support, before the nine million program: near parity in fees, decided by capability and platform risk, and the negotiation should therefore chase the cap, the credits, and the ramp, not the year one price. C, the migration is a mistake, stay on EBS indefinitely. Or D, the comparison is impossible to make. Pause here. Compound two point one million at six percent for ten years, then decide what the negotiation should actually optimize.
The answer is B, and the compounding is one spreadsheet row: two point one million growing at six percent sums to roughly twenty seven point seven million over ten years, while two point four million of support with its own typical uplifts lands near twenty eight, and the nine million program plus the parallel run sits entirely on the SaaS side of the scale. So the year one saving was real, and it was also the high water mark of the entire decade: deepest discount, no compounding yet, program costs elsewhere. Near parity in fees. Which does not make the migration wrong, C overcorrects, because the stay path carries its own honest decade, aging platforms, evaporating skills, and a forced modernization eventually anyway. It makes the migration a decision about capability and platform risk, and it makes the money a decision about clauses. Here is the arithmetic that should redirect the negotiation: capping that six percent uplift at three saves roughly three and a half million over the term, several times what another point of day one discount is worth, and the migration credits and the ramp determine whether the nine million program carries an extra three million of double running on top. A stares at the flattering year. D gives up on a calculation a graduate could run. The analyst's summary, and it is the sentence to take out of this session: migrate for the capability, negotiate for year ten.
The migration as leverage, three rules for spending the biggest card in the estate. Rule one, spend it once: the moment Oracle knows the migration is decided, the leverage is spent, so the evaluation runs visibly, the alternative stays alive and credible, Workday for HCM, the hyperscalers for infrastructure, staying put with third party support as the honest baseline, and the decision remains open, in Oracle's perception, until the paper is right. Loose talk from an infrastructure team at a conference has repriced deals worth millions, message discipline is real money. Rule two, time it: Oracle's fiscal Q4, your renewal calendar, and the support annuity all arrive at the same table, and the migration signature is the once a decade opportunity to restructure the entire relationship, not merely add a subscription to it. Rule three, bundle it deliberately: the support credits, the ULA position if one exists, audit peace during the transition, because nothing invites scrutiny like a customer mid migration, the OCI commitments if module three pointed you there. Every one of those negotiates better inside the migration package than it ever will on its own, one table, one deliberate package, which is, not coincidentally, the exact method the session thirty capstone will rehearse. And with that, module four closes: the portfolio, the order, ERP, HCM, and the migration. Module five picks up the story where the signature ends: the lifecycle, renewals, shelfware, exit, and compliance.
Session twenty, three sentences, and module four in the bank. One: a migration trades a flat support annuity Oracle already owns for a growing subscription Oracle wants more, which is why the migration buyer holds leverage no renewal buyer ever sees, and why the parallel run gets funded by the seller, through the ramp and the credits, not by you. Two: perpetual rights survive support termination, the one way doors are support termination, license surrender, and decommissioning, and none of them gets walked through, whatever incentive is attached, until the new system has survived one full business cycle, Tom's rule, bought at one point one million by someone else so you get it free. Three: over ten years the fees often land near parity, so the migration is decided by capability and platform risk, and the negotiation chases the cap, the credits, and the ramp, migrate for the capability, negotiate for year ten. That is module four complete: metrics, orders, ERP, HCM, migration. Module five, the SaaS lifecycle, starts next week with the initial deal done properly. See you there.
One more thing before the homework, because module boundaries are worth marking. Four modules in, look at what you now hold. Module one gave you the contract stack, the CSA, the orders, the policies. Module two gave you OCI commercially, credits, commitments, BYOL, Support Rewards, governance. Module three put Oracle on every cloud and gave you the five row method for choosing between them. And module four gave you SaaS: the metric families and their definitions, the order read like an analyst, ERP and HCM in depth, and today, the migration that moves an estate. What remains is the part most estates do worst: living with what they signed. Module five is the SaaS lifecycle, the renewal, the shelfware, the exit, the compliance machinery, five sessions on the years between signatures. And module six assembles everything into governance and the capstone negotiation. The homework tonight closes module four properly: it makes you build the migration ledger for a real estate, because the discipline of this whole module, definitions before signatures, sequences before incentives, ten years before year one, only becomes yours when you run it on your own numbers. Half the course behind you, the applied half ahead.
Homework, about an hour, the migration ledger for one estate. One, pick the estate: your largest on premises Oracle application, EBS, PeopleSoft, JDE, Siebel, or Hyperion, and the exercise works whether the migration is decided, underway, or merely rumored in steering committee. Two, build the support ledger: every support set attached to that estate, its cost, the licenses it covers, and, the part almost nobody has written down, what repricing exposure a partial termination would trigger across the sets that remain. Three, run the ten year case: subscription with a realistic uplift against support with its uplift, reimplementation and parallel run on the page, and note where parity sits, that number reframes every incentive the seller offers. Four, sequence the doors: write the five steps for your estate with dates, signature, go live, first full cycle, support termination, license decision, and mark honestly which are already behind you. And five, inventory the leverage: if the migration is not yet signed, list what belongs in the package, credits, cap, ramp, audit peace, the ULA if one exists, with a value against each. That list, priced, is the negotiation, and most estates walk into it without one. An hour of ledger work for the largest trade the estate will ever make. Do this one.
Five reads before next session, all free on redress compliance dot com. First, the CIO playbook for transitioning Oracle on premises applications to Fusion Cloud, the whole trade end to end, today's session in reference form. Second, Hyperion to EPM Cloud migration costs, a worked estate migration with the licensing arithmetic on the page. Third, Siebel to Fusion CX migration licensing, the CX flavor of the trade with its own traps. Fourth, dropping Oracle support and reinstatement, the one way door in detail, termination mechanics, the repricing problem, and the priced to stay shut cost of coming back. And fifth, Oracle support cost reduction strategies, because the annuity you are trading away deserves to be valued properly before you spend it. That's session twenty, and that's module four: Oracle SaaS, bought properly, from the first metric definition to the estate scale migration. Next week, module five opens with the initial deal, the concessions that exist only before the first signature, sequenced the way professionals sequence them. Halfway through the lifecycle, and the best negotiating material is still ahead. See you there.