Lifting the application estates to hyperscalers: the user licenses that travel, the tech stack that counts, and the grants that do not stretch. 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 thirteen of thirty. Sessions eleven and twelve gave you the counting rule and the database paths on AWS. Today we climb the stack, because most Oracle estates don't run bare databases, they run applications: JD Edwards, E-Business Suite, PeopleSoft, Siebel, and when those estates lift to a hyperscaler, the licensing questions multiply in a very specific, very learnable way. JDE is today's worked example because it's the estate most often lifted to AWS, but write this down now: everything today generalizes. EBS, PeopleSoft, Siebel, same three layers, same rules, same traps. By the end you'll be able to take any Oracle application migration plan and find its licensing exposure in an hour, which, as our advisor will demonstrate, is an hour that has been worth seven figures to people who spent it. Let's climb.
Five takeaways. One, the layers: every Oracle application estate is three licensing layers, application licenses, technology stack, and infrastructure, and each layer migrates under completely different rules, which is why blanket statements about migrating JDE are always wrong. Two, the travelers: why the application layer's user licenses move to any cloud without a license event, plus the two footnotes that qualify the good news. Three, the counters: the database and middleware underneath, counted by session eleven's rule at whatever size the infrastructure team chose, which is the sentence that should worry you. Four, the grants: restricted use and Technology Foundation licenses, the narrow rights many application estates run on, and exactly where they snap in a migration. And five, the patterns: the four migrated architectures auditors examine first, and the one hour design review that defuses all of them.
The three layers, using JDE as the model. Layer one, the application licenses: JDE EnterpriseOne modules, licensed by user metrics, named users mostly, legacy concurrent metrics in older contracts, module specific measures here and there. The key property: they count people. People don't change when a server moves to Virginia. Layer two, the technology stack: the database JDE runs on, the WebLogic web tier that serves it, the batch and logic servers. This is infrastructure software, counted by where it runs and how big, and a migration changes both of those things, which makes layer two the active layer, licensing wise, of any migration. Layer three, the infrastructure itself: EC2, storage, networking, Amazon's bill, no Oracle entitlements anywhere in it, but, and this is the connection that gets missed, layer three's sizing decisions directly set layer two's license counts. The infrastructure architect who picks sixteen vCPU instances just spent licensing money without knowing it. So here's the migration mistake in one sentence: teams plan layer three carefully, correctly assume layer one is fine, and forget layer two exists. Layer two is where the findings live. The whole session is really about layer two and its boundary with layer one, which is where the grants sit.
Layer one first, the genuine good news, with two footnotes that keep it honest. The headline: user metric application licenses are portable. A named JDE user license counts a human being, that human uses the system the same way whether the server is in your datacenter or in Northern Virginia, and so the application layer migrates with no license event at all. No policy, no conversion ratio, no counting change. Footnote one: the counts still bind. The migration doesn't reset anything, if you had eight hundred licenses and nine hundred users on premises, you have the same gap in the cloud, and, subtle but important, the cloud gives you cleaner, more centralized access logs, which cuts both ways: easier for you to count, easier for an auditor to prove. Footnote two: legacy metrics deserve an actual read. Old JDE paper carries concurrent user metrics, module measures, occasionally language tying use to named sites or servers. Ninety five percent of the time it's fine; the five percent is found by reading the ordering documents, not by assuming. Two practical moves fall out: the migration is a counting opportunity, the inventory touches every user and module anyway, so run the layer one true up alongside for free. And support carries on, the twenty two percent annuity follows the licenses wherever they run, which means session nine's Support Rewards loop can offset it if the estate consumes OCI anywhere. Cross cloud estates, do that math.
First check. A JDE estate with eight hundred named user licenses migrates from the datacenter to AWS. Post migration, nine hundred fifty people use the system. The licensing position: A, fine, user licenses don't apply in the cloud. B, a hundred fifty user shortfall that existed or grew regardless of platform, the migration changed nothing about layer one obligations, and the fresher cloud logs make the gap easier to evidence. C, a violation of the authorized cloud policy. Or D, covered, because AWS infrastructure includes application use rights. Pause here. What does a named user license count, and did the migration change it?
The answer is B. Named user licenses count people, nine hundred fifty people against eight hundred licenses is a hundred fifty user gap, and it's the same gap in Virginia that it was in the datacenter, the migration neither caused it nor cured it. What the migration did change is evidentiary: modern cloud access logging makes the user count trivially provable, in either direction, which is precisely why the smart move is running the true up inside the migration project, on your own terms, at negotiated prices, rather than having an audit run it later at list. C misapplies session eleven: the authorized cloud policy governs processor counting for infrastructure software, layer two, and says nothing about user metrics. And D is session twelve's boundary lesson wearing an application costume: Amazon sells infrastructure, full stop, and no AWS agreement has ever included a single Oracle application right. The layers have different rules. That's the session's whole architecture, and check two moves us down a layer.
Layer two, the tech stack, counted. Walk the table. The JDE database: lands on RDS BYOL or EC2 per session twelve's gates, counted by session eleven's rule on the instance vCPUs, options at count, everything you already know applies. The WebLogic web tier: EC2 instances behind a load balancer, and every vCPU in that tier counts, two per license with hyperthreading, autoscaling at the configured peak. Hold the web tier in your mind, it's the star of the next check and the advisor's story. Batch and logic servers: same rule, with a money note, these are chronically oversized because datacenter sizing habits came along in the lift, and right sizing before counting is free money. Dev, test, and DR: each environment is a full stack of installs, each counts, and a cross region DR mirror doubles the tier it mirrors, session twelve's Multi AZ lesson at estate scale. And the summary row, the one to internalize: the stack is sized by infrastructure and counted by licensing, and if those two teams don't size it together, the estate pays for the gap. The classic miss, one more time because it's the expensive one: application teams look at this architecture and see JDE. Auditors look at it and see WebLogic on every node of an elastic tier, counted at the policy rate. Let's hear that exact story.
Guest analyst A manufacturing client lifted JD Edwards to AWS, textbook project, on time, and eighteen months later an audit letter arrived. The finding was not the database, which they had counted carefully. It was the web tier. On premises, JDE's web layer had run on four fixed servers, sized once, licensed once, forgotten. The migration team rebuilt it properly for the cloud: an autoscaling group, load balanced, scaling from six instances at quiet times to eighteen on month end close. Nobody recounted the WebLogic, because nobody thought of the web tier as an Oracle product, it was just JDE's plumbing. Eighteen instances of eight vCPUs at the policy rate is seventy two licenses of WebLogic exposure, against the twelve they owned from the datacenter days. The opening claim had a seven in front of it, in millions. We negotiated it down hard, on the usual grounds, the peak was rare, the counting theory had gaps, and Oracle wanted a cloud deal more than a war. But here is my point for your design reviews: the correct number was knowable, to the license, on the day the autoscaling group was configured. The maximum size field in that console form is a licensing decision. Treat every scaling parameter on an Oracle bearing tier as a line in a purchase order, because that is what it is.
The maximum size field is a licensing decision, a line in a purchase order someone fills in without reading. Twelve licenses owned, seventy two exposed, and the whole gap was one console form. Check two makes you run exactly that arithmetic.
Check two. A migrated JDE web tier runs WebLogic on six EC2 instances of eight vCPUs each, hyperthreading on, in an autoscaling group capped at ten instances. The WebLogic license requirement: A, twenty four licenses, six instances times eight vCPUs divided by two. B, forty licenses, the group can reach ten instances, eighty vCPUs, and licensing follows the configured peak. C, zero, WebLogic ships free with JDE. Or D, six licenses, one per instance. Pause here. Sessions eleven and twelve: what does an autoscaling group license, and does JDE change WebLogic's rules?
The answer is B, forty licenses. The configured maximum is the exposure: ten instances, eight vCPUs each, eighty vCPUs, divided by two at the policy rate, forty licenses, and it doesn't matter that the group idles at six instances most of the year, the month end peak is real, recorded, and countable. Twenty four is the floor, the running count, and the gap between floor and cap is exactly the advisor's seven figure story at smaller scale. That's why session eleven's discipline caps groups at licensed capacity: if you own twenty four licenses, the cap is six instances, and the month end close gets handled some other way, bigger instances inside the cap, or more licenses bought deliberately at negotiated rates. Now C, the dangerous one: WebLogic is never free with JDE by default. Whether any restricted grant covers this tier depends entirely on the Technology Foundation language in your specific ordering documents, some estates have it, many think they do and don't, and the difference is the next slide. Assuming coverage is how twelve owned became seventy two exposed. And D's per instance counting exists in no Oracle rulebook anywhere. The policy counts vCPUs. Always vCPUs.
The grants, layer one and layer two's shared border, and the most contract archaeology this course will ask of you. What they are: many JDE estates, and EBS and PeopleSoft estates alike, don't own full use database and middleware licenses at all. They own restricted use rights, Technology Foundation style bundles sold with the original application purchase, licensing the database and middleware for the named application's use only. Cheaper at purchase, narrower forever. How they travel: a restricted grant valid on premises is generally valid on AWS for the same restricted purpose. The cloud doesn't void it, and, critically, doesn't widen it by one query either: the boundary is the application, not the location. Where they snap, and migrations manufacture these: a reporting tool reading the JDE database directly. An integration platform writing into it. A consolidated WebLogic domain hosting JDE plus one convenient extra app. Each of those converts restricted use into unlicensed full use, at the whole tier's counted size. Two disciplines follow. Read the paper first: the grant's exact wording, which products, which versions, which purposes, lives in ordering documents that may be twenty years old. Retrieve them before the architecture is drawn, because the wording is a design constraint, not a compliance afterthought. And price the alternative: where the target architecture genuinely needs full use, license it deliberately at negotiated rates, a known cost, instead of discovering it later as a finding with back support attached.
The four architectures auditors examine first, and by now you can derive them yourself, so consider this consolidation. Pattern one, the direct connect: BI tools, data pipelines, integrations touching the application database outside the grant. The audit method is beautifully simple, connection logs, and every estate has more connections than its architecture diagram admits. Pattern two, the shared domain: the WebLogic domain consolidated during migration to host JDE plus something else, converting the entire tier's restricted grant to full use exposure. Consolidation is an infrastructure virtue and a licensing hazard, in the same motion. Pattern three, the elastic tier: the advisor's story, scaling parameters on Oracle bearing tiers, set by infrastructure, never recounted by licensing. And pattern four, environment sprawl: dev, test, training, DR, cloned from production because cloning is free in the cloud. The infrastructure is nearly free; the Oracle installs in every clone count in full, and where on premises environments shared licensed hardware, cloud clones each stand alone. Four patterns, and here's the economical part: one hour in the migration design review checks all four. Connections into the database, listed. Domain contents, listed. Scaling caps, read. Environment inventory, counted. That hour, against the advisor's seven figure letter, is the best rate of return in this module.
Last check, the grant boundary live. Post migration, a data team connects a BI tool directly to the JDE database, which runs under a Technology Foundation restricted grant. The accurate read: A, fine, the data never leaves the company. B, the direct connection is use outside the JDE application, beyond the restricted grant: the database now needs full use licensing, and the fix is either licensing it or routing the BI through a supported interface. C, fine if the BI tool is read only. Or D, a problem for the BI vendor, not the estate. Pause here. What does the grant cover: the database, or the database when used by JDE?
The answer is B, and the grant's grammar is the whole question. A restricted grant licenses the database for the named application's use. The BI tool is a second application using the database, and the moment it connects directly, the use falls outside the grant, making the database's actual requirement full use licensing at its counted size. Now C, read only, deserves a careful burial because it feels so reasonable: SELECT is use. Querying a database is what databases are for, and Oracle's licensing has never distinguished reading from writing, on premises or in any cloud. If read only were free, nobody would ever license a reporting database. A's internality argument is equally irrelevant, the license governs the software's use, not the data's travel. And D, hoping the exposure lands on the BI vendor: the Oracle agreements are yours, the findings are yours. The legitimate paths are two: license the database full use, deliberately, at negotiated rates, if direct analytics access is genuinely worth it; or preserve the grant by routing analytics through extracts, replicas, or interfaces licensed for the purpose. Both are fine. The quiet direct connect is neither, because connection logs are the first thing every audit script reads, and this pattern is the most reliably found finding in application estate audits.
The application migration discipline, five habits, the session as a checklist. One, retrieve the grants first: the original ordering documents with the restricted use language, physically on the table before the target architecture is drawn, because the grant's wording is a design constraint with the same force as a security requirement. Two, true up layer one in flight: the migration inventory already touches every user and module, so reconcile licenses to people inside the project, at your negotiated rates, on your calendar. Three, size layer two deliberately: right size the stack before counting it, cap every scaling group at licensed capacity, and put the tech stack license line in the migration business case where the CFO can see it, because a business case missing layer two is understated by exactly the advisor's story. Four, review the four patterns: connections, domains, caps, environments, one hour, in the design review, with licensing in the room, session eleven's meeting invitation made mandatory for application estates. And five, ledger everything: application licenses, tech stack allocations, and grant boundaries go into the same cross cloud entitlement ledger as the databases from session eight and the instances from session eleven. One shelf, one truth, every cloud, every layer. That ledger is quietly becoming the single most valuable document this course has built, and we're only at session thirteen.
Session thirteen, three sentences. One: application estates are three layers, user licenses that travel freely because they count people, a tech stack counted by the cloud policy at whatever size infrastructure happened to choose, and restricted grants whose boundaries move with them unchanged. Two: the findings live in layer two and at the grant borders, the web tier counted at its scaling cap, the direct connection that converts restricted to unlicensed, the cloned environments each counting in full. Three: the defense is the design review, grants on the table first, four patterns checked in one hour, and the layer one true up run while the project touches everything anyway. Next session, the newest and strangest terrain in this module: Oracle Database at AWS, at Azure, and at Google Cloud. Oracle's own hardware, inside the hyperscalers' datacenters, bought through their marketplaces, burning their commitments, running Oracle's database service. The multicloud constructs that didn't exist three years ago and now change the answer to questions this module has already asked. See you there.
Homework, about an hour, and it's the design review this session kept selling, run on your own estate. One, pick the estate: your largest Oracle application on a hyperscaler, or the one nearest to migrating. JDE, EBS, PeopleSoft, the logic is identical, only the product names change. Two, find the grants: locate the actual restricted use language in the original ordering documents. Set a one week deadline, and if nobody can produce the paper in a week, write that down, because an estate that can't state its own grant boundaries can't defend them. Three, count layer two: database, web tier, batch servers, instances and vCPUs and scaling caps, at the policy rate, against allocated entitlements in the ledger. Four, trace the connections: everything connecting to the application database that isn't the application itself. Every line on that list is either inside the grant or a decision waiting to be made deliberately. And five, inventory the environments: every non production copy of the stack, each counted in full. Sprawl you find this week is a right sizing exercise; sprawl the scripts find next year is a settlement. One hour, four patterns, your estate. The advisor charges considerably more for the same hour.
Five reads before next session, all free on redress compliance dot com. First, JD Edwards licensing explained, user types, metrics, and pitfalls, layer one in the depth your contracts deserve. Second, JD Edwards licensing and cloud migration, today's session in JDE specific reference form. Third, optimizing JD Edwards licensing costs, the negotiation side, what to ask for when the true up becomes a purchase. Fourth, Oracle database licensing on AWS, layer two's database in session twelve's terms, worth rereading now that it sits under an application. And fifth, Oracle database licensing in cloud environments, the counting rule that runs under every layer two number in today's session. That's session thirteen: three layers, four patterns, one hour of design review. Next time, Oracle's cloud moves into Amazon's building, and the map gets genuinely strange. See you there.