The mature Oracle applications, E-Business Suite, JD Edwards, PeopleSoft, and Siebel, are decades old, deeply customized, and still core to the business, which makes them stable, expensive to move, and easy to overpay for. This session reads the application user and business metrics that price each suite module by module, why they are harder to count than a database and drift from reality over years, and how customization complicates every upgrade, audit, and migration. It closes on the support fork every mature estate faces, staying on Oracle support, moving to third party support, migrating to Fusion, or holding a deliberate steady state, matched to each module's trajectory, with drift, full price support on a frozen estate, named as the one universal mistake.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the PeopleSoft estate licensed for 2,000 users with only 1,100 active, ripe for a support reduction; the heavily customized EBS estate Oracle is pressing to migrate, decided on the business case not the sales pressure; and the frozen, customized JD Edwards estate entering Sustaining Support, the textbook case for third party support. It closes with one suite decided four ways, a different road per module.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirty seven of forty, module eight continuing. Last session was Java. Today, the big legacy applications, the on premises suites that many organizations still run at the core of the business: E Business Suite, JD Edwards, PeopleSoft, and Siebel. Here's what makes these different from everything else in the course. They're decades old, they're deeply customized, and they usually don't grow, they just run, quietly, doing finance and HR and supply chain and sales, often better fitted to the business than anything that could replace them. Mature, in other words, doesn't mean unimportant. It means stable, customized, and expensive to move, which is precisely the leverage problem, because a system you can't easily leave is a system Oracle can price with confidence. And every one of these estates faces the same fork: keep paying Oracle support, move to third party support, migrate to Fusion, or hold a deliberate steady state. Today: the four suites and how each came to Oracle. The application metrics, and why they're harder to count than a database. The customization problem, the hidden variable in every decision. The support lifecycle, Premier, Extended, Sustaining. And the four roads forward, matched to each module's trajectory. This is the bridge between the perpetual world of modules one to five and the SaaS future of module seven. Let's cross it.
Five takeaways. One, you'll know the suites: tell E Business Suite, JD Edwards, PeopleSoft, and Siebel apart, and how each came to Oracle, three of the four by acquisition. Two, you'll read the metrics: understand application user and custom business metrics, and why they're harder to count than a processor. Three, you'll see the customization risk: know how years of customization complicate every upgrade, every audit, and any move off the platform. Four, you'll weigh the support fork: understand Premier, Extended, and Sustaining support, and what each does to a mature estate's economics. And five, you'll choose the road: compare staying on Oracle support, third party support, migrating to Fusion, and deliberate steady state, on real cost and risk. One sentence to carry: there's no single right answer for a mature suite, only the right road for each module's trajectory, and the one universal mistake is drift, full price Oracle support on a system that has stopped changing. The mature estate, next.
Four things that frame the mature estate. Four: the major on premises suites, E Business Suite, JD Edwards, PeopleSoft, and Siebel, and three of the four Oracle acquired, so each kept its own metrics and its own quirks, they don't match each other and they don't match the database. Core: what they run, finance, HR, supply chain, sales, the operational heart of the business, so mature doesn't mean unimportant, it means stable, customized, and expensive to move, which is exactly the leverage problem for the buyer. Custom: the defining trait, years of customization that make every upgrade a project, every audit a puzzle, and every migration a genuine cost rather than a copy. And fork: the decision every mature estate faces, keep paying Oracle support, move to third party support, migrate to Fusion, or hold a deliberate steady state, and this session's job is to frame that fork clearly. Here's where this session sits in the course. The on premises applications are exactly where the perpetual licensing of modules one to five meets the SaaS future of module seven. They're the bridge between the two worlds, and the decision that connects them. So we'll treat them as both, a perpetual estate to count and reduce, and a candidate for the SaaS road. The four suites, first.
The four on premises suites, four distinct products, each with its own history, metrics, and profile. E Business Suite, EBS: Oracle's own ERP, the broadest of the four, spanning finance, supply chain, HR, and more, licensed on a mix of application user and module specific metrics, and very widely deployed, the default Oracle ERP for a generation. JD Edwards, JDE: acquired via the PeopleSoft deal, a strong mid market and manufacturing ERP with its own metrics and a notably loyal base that often runs it stable for many years, sometimes decades. PeopleSoft: acquired in two thousand five, strong in HR and finance, especially in large enterprises and the public sector, where application user metrics and deep customization are the norm. And Siebel: acquired in two thousand six, the classic on premises CRM, licensed on application user metrics, still core in some industries, and one of the most frequent candidates for migration to Fusion CX. Here's the practical consequence of that acquisition history. Three of the four came to Oracle by purchase, which is exactly why their metrics differ from one another and from the database you learned to count in module one. So the rule is simple and strict: read each suite's own definitions, and never assume they match. The metrics, next.
The application metrics, and why they're genuinely hard, harder than the database. Four points. Application User: the most common metric, named individuals authorized to use the application, session two's named user in application form, counted per module, and with the definition varying by product, so a PeopleSoft user and an EBS user aren't defined identically. Custom and business metrics: many modules license on business measures instead, expense report users, invoice lines, revenue, employees, or records processed, each tying the cost to a business quantity rather than a technology one. Module by module: a suite is licensed module by module, each module carrying its own metric and its own count, so the estate is a patchwork of different metrics, not one clean number, which is exactly what makes it hard to total. And the counting difficulty: unlike a processor you can physically inspect and count, application users and business metrics require reading definitions and pulling business data, so miscounting is common, and it happens in both directions, over licensed here, under licensed there. Here's why this session leans so hard on module one's counting discipline. The application estate rewards careful counting more than almost anything else in the course, because the metrics are varied, definition dependent, and, critically, rarely re examined after go live, so the count drifts from reality for years. Knowledge check one shows what that drift is worth.
Knowledge check one. A PeopleSoft estate was licensed for two thousand application users a decade ago. Headcount has since fallen and processes moved elsewhere; only about eleven hundred now use it. At renewal, what is the opportunity? A, nothing, you licensed two thousand, so you keep paying for two thousand. B, recount actual users and reduce support to the real eleven hundred, because support on nine hundred unused licenses is pure shelfware on a shrinking estate. C, buy more users to be safe. Or D, nothing, application user counts can never be reduced. Pause here. How many users does the estate actually have, and what are you paying support on?
The answer is B. Mature estates trend downward, and the licensing rarely follows on its own. A decade ago two thousand application users were licensed; today only about eleven hundred use the system, so nine hundred licenses are shelfware, and their support fee, module four's twenty two percent annuity, is being paid every year for capability nobody touches. B is the opportunity: recount the real users and reduce the supported quantity to roughly eleven hundred. This is module four's support reduction discipline and session eighteen's shelfware, applied to a shrinking application estate, and mature estates are exactly where it pays best, because they only get smaller while the support bill, left alone, only compounds. The mechanics need care, Oracle's support reduction and repricing rules can penalize partial drops, and that's precisely why you plan it deliberately at a renewal rather than hoping for it, but the principle is sound and the saving is real and recurring. A accepts the historical number as permanent, which is how estates pay for a decade of departed users. C adds users to a system that's losing them, manufacturing more shelfware. D is false, supported quantities can be reduced within the contract's repricing rules, and a renewal is the moment to do it. The rule for the mature estate: the license count is a decade old snapshot, so recount against reality and pay support on what you use, because on a shrinking estate the gap between licensed and used only widens. The customization problem, next.
The customization problem, because years of customization is what makes these suites both sticky and expensive, and it shapes every decision in this session. Why they customize: decades of tailoring the suite to exact business processes, custom code, custom reports, integrations, and workflows, and it's what made the system fit the business so well, which is also what now makes it hard to change. Upgrades become projects: every customization has to be retested, and often reworked, on each upgrade, so staying current is a genuine project rather than a patch, which is exactly why so many estates run old, stable versions for years rather than chase the latest release. Audits get harder: customizations can obscure who uses what and how modules are actually deployed, which complicates both your own counting and an Oracle audit, and the ambiguity cuts both ways. And migration is not a copy: moving to Fusion, or anywhere else, means re implementing the customizations as configuration or accepting standard processes instead, so the customization is the migration cost, not the data. Here's the frame to hold across the rest of the session. Customization is the hidden variable in every option: it's the reason staying is easy, upgrading is hard, and migrating is a real project. So before you choose any road, you quantify it, because a decision made without knowing how customized the estate is, is a decision made blind. Knowledge check two.
Knowledge check two. A heavily customized EBS estate is stable and meets the business need, but Oracle is pressing hard to migrate it to Fusion Cloud. What should drive the decision? A, migrate now, on premises is old and Oracle recommends it. B, the business case: weigh the real migration cost, customizations included, against the value of Fusion, and decide on your timeline, not Oracle's sales pressure. C, never migrate, on premises is always cheaper. Or D, migrate only the modules Oracle discounts most. Pause here. Whose need drives this migration, the business's, or the vendor's sales plan?
The answer is B. Oracle has a clear commercial interest in moving you from a perpetual on premises license, which you own, to a Fusion subscription priced on the metrics of module seven, which you rent forever, so the sales pressure to migrate is real, and it is not neutral advice. B keeps the decision where it belongs, on the business case. A migration to Fusion may well be right, the operational relief, the end of upgrade projects, and modern capability are genuine benefits from session thirty one, but it's a major undertaking whose true cost is dominated by re implementing the customizations this session has emphasized, not by moving data. So you weigh that real, customization inclusive cost against the concrete value Fusion delivers, and you decide on your timeline, when the business case closes, not on Oracle's quarter end or its end of support messaging. A migrates on the vendor's recommendation and timing, the least reliable basis, since Oracle benefits from the move whether or not you do. C is equally unthinking in the other direction, on premises isn't always cheaper, and a stable estate can still be worth modernizing when the case is genuinely there. D lets Oracle's discount pattern, rather than your business need, choose which modules move, fragmenting the estate for a pricing reason. The rule: a migration off a perpetual estate you own is a business decision, so make it on the business case and your calendar, and treat vendor pressure as information about the vendor's incentives, not about your best move. The support fork, next.
Premier, Extended, and Sustaining support, because Oracle support runs in phases, and where your version sits in that lifecycle shapes the whole decision for a mature estate. Premier Support: the full support phase, updates, fixes, security patches, and new certifications, for a defined period after a release, full price and full service, the default while a version is current. Extended Support: a time limited extension past Premier, often at a price uplift, to keep full support on an older release, essentially a paid runway for estates not ready to upgrade or move. Sustaining Support: indefinite but limited, no new updates, no new fixes, no new certifications, only what already exists, so it's cheaper but it's a frozen platform, and that freeze is exactly what forces the stay, migrate, or third party decision. And the lifecycle drives the fork: as a version moves from Premier to Extended to Sustaining, the value of Oracle support falls while the cost largely holds, and that widening gap between what you pay and what you get is precisely what makes third party support and migration worth pricing. Here's the practical instruction: know where every application version sits in this lifecycle, with dates. The transition from Extended to Sustaining is the moment the support decision becomes urgent and the alternatives most attractive, because that's when full price Oracle support starts buying the least. The four roads, next.
The four roads for a mature estate, laid side by side, plus the one to avoid. Stay on Oracle support: keep Premier or Extended support and current versions, and it fits when the estate is still evolving and you genuinely value Oracle's updates and certifications. Third party support: move support to a provider like Rimini, per session nineteen, and it fits a stable, customized estate you'll run as is for years, where you need the system supported but not the new Oracle releases. Migrate to Fusion: move to Oracle's SaaS suite, per module seven, and it fits when the business case for modern SaaS closes, customizations and all, on your timeline. Deliberate steady state: Sustaining support or minimal spend, run it flat, and it fits a system near end of life that you're keeping running while a successor is planned. And the wrong road, the one to name so you can avoid it: drift, paying full Oracle support on a frozen estate, which is never right, it's simply the default that quietly overpays for a static system year after year. Here's the honest summary: there's no single right road, only the right road for a given estate's trajectory. A growing system, a frozen one, an aging one, and a dying one each want a different answer, and the whole skill is matching the road to the trajectory. Auditing the estate, next.
Auditing the applications estate, its own discipline, and the customization and metric complexity of these suites makes it distinctive. Four points. User counting is the front line: application user metrics mean the audit centers on who's provisioned and active, so stale accounts, departed users, and duplicate access are the common exposures, and, read the other way, the common savings, because every account you clean up before an audit is a license you don't have to defend. Module boundaries matter: using a feature that belongs to an unlicensed module is a classic application finding, so you need to know which modules you own and which ones your customizations quietly reach into. Customizations cut both ways: they can hide usage from you as well as from Oracle, so your own inventory has to be better than the auditor's, per module five, or the ambiguity gets resolved against you. And module five applies in full: every audit lesson holds, verify the claim, control the scope and the channel, don't volunteer data, and reconcile to your own records first. Here's the through line to module five: the application audit rewards the estate that counts its own users and knows its own module boundaries. On a customized, mature suite, that self knowledge is the whole defense, because the customization creates ambiguity, and ambiguity, in an audit, is expensive unless you're the one who resolves it first. Knowledge check three.
Knowledge check three. A stable, heavily customized JD Edwards estate will run as is for at least five years. Its version is entering Sustaining Support. Oracle support is a large annual bill. What deserves serious evaluation? A, nothing, keep paying full Oracle support out of habit. B, third party support: for a frozen, customized estate with no need for new Oracle updates, it can cut the support bill sharply while keeping the system supported, per session nineteen. C, an immediate Fusion migration, regardless of the business case. Or D, turning off support entirely to save money. Pause here. If Sustaining Support gives no new updates anyway, what is full price Oracle support buying here?
The answer is B. This is the exact estate third party support was built for, and the lifecycle makes the case almost by itself. The version is entering Sustaining Support, so Oracle is no longer providing new updates, fixes, or certifications regardless of what you pay, and the estate is frozen, customized, and staying as is for five years, so you have no need for the updates that Sustaining wouldn't give you anyway. In that situation, full price Oracle support is buying very little, and B is the evaluation that follows: third party support, per session nineteen, can support the customized, stable system, often including the tax and regulatory updates a running estate genuinely needs, at a large discount to Oracle's fee. It's not automatic, you weigh the provider, the security patch approach, and the exit implications, but for a frozen estate it's frequently the strongest value on the table. A keeps paying full price for support that, at Sustaining, has little left to deliver, the pure drift this session warns against. C forces a migration the estate doesn't need, at a cost dominated by its customizations, when the plan is explicitly to run as is for years. D confuses third party support with no support, and going unsupported on a core business system is a risk, not a saving, and it's not what B proposes. The rule, tying module four to module eight: match the support model to the estate's trajectory, and a stable, customized, frozen estate is the textbook case for third party support, not full price Oracle maintenance. One estate, decided, next.
One applications estate, decided, and notice it's not one decision, it's four. PeopleSoft HR: two thousand users licensed, about eleven hundred active, and the system is still evolving, so the decision is recount to eleven hundred and stay on Oracle support, because for an active system you still value the updates. JD Edwards: frozen, customized, a five year horizon, entering Sustaining, so the decision is move to third party support for a large recurring saving, exactly knowledge check three. Siebel CRM: aging, and the business genuinely wants modern CX capability, so the decision is a Fusion CX migration, made on a real business case and a real timeline, not on sales pressure. EBS Financials: stable, near end of life, with a successor already planned, so the decision is deliberate steady state, keep it running flat until the successor is ready. And the estate as a whole, the bottom row: one suite, four trajectories, four different roads, each matched to that module's future. Here's the lesson of the mature estate, and it's the opposite of what a vendor wants you to believe. There's no single answer for the whole suite. Each module has its own trajectory, and the right road, recount, third party, migrate, or steady state, follows from that trajectory, not from a blanket policy and certainly not from a blanket migration. Recap, next.
Session thirty seven in three sentences. One, E Business Suite, JD Edwards, PeopleSoft, and Siebel are licensed module by module on application user and business metrics that are varied and easy to miscount, so a mature estate is recounted against reality, not carried forever on a decade old number. Two, customization is the hidden variable in every decision, it makes staying easy, upgrading a project, and migrating a genuine cost, so you quantify it before you choose any road. Three, the support fork, stay, third party support, migrate to Fusion, or deliberate steady state, is decided by each module's trajectory and where its version sits in the Premier, Extended, Sustaining lifecycle, and the one universal mistake is drift, full price Oracle support on a frozen estate. Next session continues module eight with licensing events, mergers, acquisitions, and divestitures: what acquisitions, carve outs, and restructures actually do to your Oracle agreements, and, crucially, the clauses that decide those outcomes in advance, long before the deal, because in M and A the license terms you negotiated years ago determine what happens when the corporate structure changes. Homework first.
Homework, about an hour, and it builds your applications strategy in draft. One, map the suites: list every on premises Oracle application you run, which suite, which modules, and the metric and quantity for each, because most estates have never had this map in one place. Two, recount one metric: pick one application user module and count the actual active users against the licensed quantity, and note the shelfware, it's usually larger than expected on a mature system. Three, check the lifecycle: for each suite, find where your version sits, Premier, Extended, or Sustaining Support, with the dates, because that placement drives the support decision. Four, size the customization: roughly, how customized is each suite, because that estimate is the hidden cost in any upgrade or migration decision. And five, pick a road per module: for each module name the likely road, stay, third party, migrate, or steady state, and the reason, and that list is your applications strategy in draft. See you in session thirty eight, for licensing events, M and A, and divestiture.
Five reads, all free on redress compliance dot com. First, Oracle E Business Suite licensing: the EBS metrics and modules, at reference depth. Second, Oracle PeopleSoft licensing: application user metrics and the customization reality, for the estates where PeopleSoft runs HR and finance. Third, Oracle third party support: the support alternative for a stable, mature estate, per session nineteen, the road behind knowledge check three. Fourth, Oracle Premier, Extended, and Sustaining Support: the lifecycle that drives the whole support fork, worth knowing precisely for your versions. And fifth, on premises to Fusion migration: the business case and the customization cost, weighed honestly, for when the migration road is the right one. That's session thirty seven. The on premises applications are a patchwork of metrics to recount, a customized estate to quantify, and a support fork to decide module by module, matched to each one's trajectory, never carried on drift. You can now look at a mature Oracle applications estate and see not one bill but four decisions. Next session, what happens to all of it when the company itself changes, mergers, acquisitions, and divestitures. See you there.