JD Edwards cloud migration and your Oracle licenses. What travels, and what gets re metered.

JD Edwards application licenses count people and devices, so they survive a cloud migration intact. The Oracle database and middleware underneath are counted again by the target platform's rules, and the commercial paper signed alongside the plan is where rights get lost.

A JD Edwards cloud migration is a licensing event before it is a technical one. Infrastructure teams size the compute, and the licensing consequence usually arrives later, on the database line of the budget, after the architecture is fixed.

A second exposure sits in the paperwork. Oracle usually attaches commercial requests to a migration, and some of them trade away rights you cannot buy back later. Below we price one database on three routes and list what to agree with Oracle before your target platform is announced.

What have we seen in JD Edwards cloud migrations in 2024 and 2025?

Across roughly 20 to 30 JD Edwards migrations I advised on in 2024 and 2025, teams planned the application layer carefully and assumed the layer beneath it. Four patterns came up again and again.

• Core factor left in the model. The database requirement was calculated with the on premises core factor still applied, which understated the cloud position by roughly half on hyperthreaded shapes.
• Non production sized as always on. Development, test and training moved to dedicated cloud instances running around the clock, after years on one lightly used shared server.
• Disaster recovery drifted warm. A cold standby became a warm replica during design. The license on paper stayed the same, and the licensing answer changed anyway.
• No baseline. In about one project in three, no one recorded the on premises position before cutover, so there was no reference point for any later disagreement with Oracle.

None of these showed up in a technical design review. Each one surfaced later as a cost on the database line of the budget, usually after the architecture was frozen and the alternatives had gone.

Which JD Edwards licenses move to the cloud unchanged?

The JD Edwards application licenses travel unchanged, because they count people, employees, devices and transactions, and a new hosting platform does not change that population. Everything counted against compute behaves differently.

It helps to treat a JD Edwards deployment as four licensing layers stacked on each other. Only two of them respond to where the servers live.

What does bring your own license actually do?

It allows you to run entitlement you already own on infrastructure you do not own. It leaves the metric as it is, creates no new rights and does not suspend the counting rules of the platform you land on.

Oracle describes the mechanism on its bring your own license page. The commercially interesting part is the conversion arithmetic underneath, which the next section works through.

Which restrictions follow the workload to the cloud?

• Territory and entity restrictions. If your order limits use to named legal entities or regions, hosting somewhere else does not widen it. A cloud region in another country can put you outside a territory clause even though the users stayed where they were.
• Restricted use grants. Technology bundled with JD Edwards to run JD Edwards stays restricted to that purpose wherever it runs.
• Support obligations. Decommissioning an on premises server does not reduce the support line. Only a termination at the renewal date does that.

How is the Oracle database re metered on AWS, Azure and Google Cloud?

On the named third party clouds, Oracle counts virtual processors and drops the core factor. The rule comes from Oracle's cloud licensing policy, a document Oracle writes alone. It names Amazon Elastic Compute Cloud, Amazon Relational Database Service, the Microsoft Azure Platform and Google Cloud Platform as Authorized Cloud Environments.

Where hyperthreading is enabled, two virtual processors equal one Processor license. Where it is not, one virtual processor equals one. The Processor Core Factor Table does not apply at all, so the 0.5 factor that halves an Intel or AMD count on your own hardware is gone. Our note on the core factor explains how that table works on premises.

Why is Oracle Cloud Infrastructure a different conversation?

OCI is not an Authorized Cloud Environment. It is Oracle's own service, sold under Oracle's cloud service terms, and its entitlement conversion is published in the service descriptions instead of the third party cloud policy.

At a high level, Oracle's BYOL FAQ maps one Processor license to two OCPUs, and one OCPU on Intel or AMD shapes is one physical core running two threads. That usually helps the buyer.

Still take the conversion for your exact shape and edition from the current Universal Credits service description. Arm shapes define an OCPU differently, and ECPU based services use another unit again.

Worked example: one JD Edwards database on three routes

Say you run production Oracle Database Enterprise Edition for JD Edwards on 16 Intel cores, with development, test and training sharing one 8 core host. Disaster recovery is a cold copy that, for this example, needed no license on premises. The table prices the result at the list price of $47,500 per Processor license.

The gap between 12 and 44 licenses is $1,520,000 at list, plus $334,400 a year at the $10,450 annual support price per Processor. Only 8 of those 32 extra licenses come from production losing the core factor. The other 24 come from non production and disaster recovery, the environments that were never in the model.

A negotiated discount lowers every dollar figure in the table and leaves the ratios unchanged. The increase also lands on the database line, which JD Edwards migration budgets rarely examine.

Amazon describes its managed service on the RDS for Oracle page, where license included pricing covers Standard Edition 2 only and Enterprise Edition must be brought under your own license. The count still comes from Oracle's policy.

Which documents decide the number?

Three documents decide it, and only one carries your signature. Rank them in this order before you accept any figure in a migration business case, including a figure produced by your own team.

• Your ordering document and master agreement. Signed by both sides. It fixes the metric, the quantity, the territory and the definition of Processor, and Oracle cannot change it alone.
• Oracle's cloud licensing policy. Published unilaterally and stated on its face to be for educational purposes only, not incorporated into any contract, and subject to change without notice. It describes how Oracle intends to apply your agreement to infrastructure it does not own. The current version is dated September 4, 2026, and our page on the Oracle cloud licensing policy covers its counting rules, edition caps and Oracle's right to revise it without asking anybody.
• Cloud service descriptions and price lists. They govern Oracle's own services, and they bind you from the moment your order references them.

Read the policy itself, including when you have read a summary such as this one. Oracle publishes Licensing Oracle Software in the Cloud Computing Environment as a dated document, and the date matters as much as the content. Record the version date in your business case.

What about the managed multicloud routes?

They change the basis from something you count to something you buy. Where Oracle operates the database inside another provider's region, the commercial terms come from the service description, and there is no processor calculation for you to perform.

Oracle documents one of these routes on its Oracle Database@Azure page, and equivalents exist for other providers, including Oracle Database@AWS and Oracle Database@Google Cloud.

The Azure service is bought through the Azure Marketplace, consumption can count toward a Microsoft Azure Consumption Commitment, and bring your own license and Oracle Support Rewards both apply. For JD Edwards the attraction is operational, and the licensing consequence still needs pricing before anyone commits. Three cautions apply.

• Managed routes consume cloud spend instead of owned entitlement. A customer that migrates and keeps paying support on licenses it no longer runs is paying for the same capability twice.
• No report flags an idle entitlement. Oracle documents the application on the JD Edwards EnterpriseOne page, and nothing anywhere tells you when a license stopped being needed.
• Dropping idle licenses has its own cost. Oracle's technical support policies reprice support on the licenses that remain when you terminate part of a license set, so the saving is often smaller than the line item suggests. Our support cost reduction guide explains the repricing rules.

Which licensing costs do JD Edwards migration teams miss?

They miss the three that sit outside the compute sizing spreadsheet: restricted database grants, non production environments and disaster recovery. Each is invisible in a technical design review, and each has changed the economics of a migration we sat in. Customers leaving IBM i face a fourth.

The application specific database grant

JD Edwards is frequently sold with a database entitlement that may only be used with the application. It is cheaper than a full use license because it is narrower, and that narrowness is a contract term.

In most existing JD Edwards contracts this is Oracle Technology Foundation for JD Edwards EnterpriseOne. It grants a restricted use license of Oracle Database Standard Edition 2, installable on unlimited processors and any number of Real Application Clusters nodes.

The bundle also carries restricted middleware such as WebLogic Server Standard Edition and BI Publisher, all for use solely with your licensed JD Edwards programs.

• It restricts what may use the database. A reporting tool or a second application sharing that instance is a breach, on premises or anywhere else.
• Its portability is not automatic. Oracle's cloud policy limits Standard Edition 2 to instances of up to eight vCPUs on the named clouds, and neither document says which rule wins for a grant that allows unlimited processors. Put the question to Oracle in writing before the design is signed off.
• A managed database service is a different product. Moving from a database you install to a service Oracle or a cloud provider operates can change the licensing basis entirely. Whether a restricted grant can be applied to a managed service at all is a second written question.

Development, test, training and the environments no one counts

Oracle licenses what is installed and running, and non production environments are installed and running. On premises they often shared a lightly used host and never appeared in anyone's model. In the cloud they get their own instances, sized properly, running continuously.

A standard JD Edwards EnterpriseOne 9.2 build uses four path codes: production (PD920), prototype (PY920), development (DV920) and pristine (PS920). Many customers add training and data conversion environments on top. Stopping those instances overnight lowers the compute bill, but the license count follows the size of each instance where the software is installed.

Disaster recovery, warm and cold

The licensing treatment of a standby depends on what the standby does, whatever it is called. A truly cold copy that is not started is treated differently from a replica that is mounted, open or receiving changes.

Cloud disaster recovery designs drift warm almost by default, because warm is cheap to build and fast to test. Check the current position in Oracle's Licensing Data Recovery Environments document, and have the architect confirm in writing how the standby will run. Then price that design. Our disaster recovery licensing guide covers the cloud cases.

Leaving IBM i adds a database decision

Many JD Edwards customers run on IBM i, where Db2 for i comes with the operating system. Unless you choose a hosted IBM i service, a migration to a hyperscaler usually means a database platform change as well.

The new database needs its own entitlement: Technology Foundation if you own it, a full use Oracle Database license, or Microsoft SQL Server. That is a new purchase decision hidden inside a hosting project, and it should be priced and negotiated as one.

How do you check your own licensing position before migrating?

Take a dated snapshot of every layer from your own systems before any conversation with Oracle starts. These are the places to look.

• Application users. Reconcile active JD Edwards user profiles (P0092) and role assignments in Security Workbench (P00950) against the quantities and metrics on your ordering documents.
• Environments and servers. Use Server Manager for EnterpriseOne to list every managed enterprise, HTML and database server instance, including the ones used only for training or conversions.
• Database options and packs. Query DBA_FEATURE_USAGE_STATISTICS and V$OPTION on each database. Options are licensed on the same metric and count as the database, so every option in use multiplies with the new vCPU count.
• Hardware. Record physical core counts and processor models from each host and from the virtualization layer, with the date you captured them.
• Contracts. List every ordering document with its metric, quantity, territory, restricted use language and support renewal date.

File the output with a date and a sign off. That snapshot is the reference point you argue from if Oracle later disputes what you ran before the migration.

What does Oracle ask for when a JD Edwards migration is announced?

More than a hosting change, in almost every deal we have seen. A migration is the point at which Oracle has something you want, which makes it the point at which Oracle asks for something in return.

The four requests that show up in the paperwork

1. Convert perpetual entitlement into a cloud subscription. Presented as simplification, and it is simpler. It is also permanent, and the perpetual license does not come back.
2. Commit to annual cloud consumption. A credit commitment is a floor on your spend, and floors written during a migration are usually written from optimistic forecasts.
3. Settle the compliance position first. Any gap found during migration planning becomes a bargaining chip for Oracle, and migration planning finds gaps by design.
4. Extend or restructure support. A longer term in exchange for migration help, which removes your next two termination opportunities.

What will the account team say, and how should you reply?

• "Converting to a subscription will make the OCI migration simpler." Reply: show us the OCI cost with our existing licenses under bring your own license first, and price conversion as a separate option we can decline.
• "Your licenses already cover you on AWS." Reply: confirm in writing the Processor count for our target instance types under the current policy version, and whether our Technology Foundation grant may run there.
• "We noticed some compliance gaps and can fold them into the migration deal." Reply: send the findings with the data behind them. We will resolve compliance on its own terms, separately from any cloud commitment.
• "Migration assistance comes with a longer support term." Reply: price the assistance as services. Our support term and termination dates are outside this discussion.

Is there a route back from the cloud?

Technically yes, and commercially it depends entirely on what you signed. Owned entitlement can be redeployed on your own hardware. Entitlement you converted into a subscription cannot, because there is nothing left to redeploy.

Oracle does not publish a 90 day license reassignment restriction for its on premises programs. That rule belongs to other vendors' mobility terms, and it has been repeated into Oracle migration plans often enough to become folklore. Plan around the transfer terms in your own agreement instead.

Why choosing the cheapest platform first and negotiating later costs money

The usual advice is to pick the cheapest target platform and sort out the licensing afterwards, because the technical decision is the hard one. We think that order is backwards, and the cost shows up in the final price.

The moment you announce a target platform, you tell Oracle where its bargaining power lies. If the target is a third party cloud, re metering starts from Oracle's policy. If it is Oracle's own cloud, the incentives change, and so does Oracle's flexibility on everything adjacent, including the systems you are not migrating.

Run the commercial negotiation and the platform selection in parallel, with two costed routes kept live until the paper is agreed. It is more work and it annoys the program manager. In the migrations we have advised on, it has consistently been worth more than the infrastructure saving being argued over in the same meeting.

A migration is the one moment in a decade when Oracle needs your signature more than you need its goodwill. Few customers use it deliberately.

What should you negotiate with Oracle before a JD Edwards migration?

Five terms, and all five are cheaper to obtain before the migration is announced than after it. The order below has held up across the migrations we have advised on.

What contract wording should you request?

• A dated policy reference. Wording that applies the cloud licensing policy version in force at signature to the programs on your order for the life of that order, so a later revision cannot raise your count.
• Named services for restricted grants. A clause listing the cloud services and shapes where your Technology Foundation components may run, which turns an open question into an entitlement.
• A non production allowance. A stated vCPU or OCPU ceiling for development, test and training, so building environments properly does not create a compliance finding.
• Support reduction without repricing. A right to terminate support on licenses retired by the migration without repricing the rest of the license set, which removes the penalty described above.
• A written conversion record. If you do convert anything, a schedule of exactly which licenses are retired and what credit you received, so the next audit starts from agreed facts.

How does the answer change with the size of your footprint?

A smaller customer with one production database on Technology Foundation may fit inside the eight vCPU ceiling for Standard Edition 2 on the named clouds. The main question is then whether the restricted grant may run there at all, and one written answer from Oracle settles most of the risk.

A larger customer on Enterprise Edition with options such as Partitioning or Diagnostics Pack faces the same doubling on every option as on the database itself. Multiple instances, Real Application Clusters and a warm standby multiply it again. At that size the worked example above understates the exposure, and the negotiation deserves its own workstream.

What is the timeline before you sign?

If the renewal date falls in the wrong place, accept an inconvenient gap between the two signatures. It costs less than negotiating both at once.

Where are the related questions answered?

• If you are unsure what your user quantities actually permit, start with JD Edwards licensing metrics.
• If your paper predates the Oracle acquisition, read JD Edwards concurrent licensing before you convert anything during a migration.
• If the goal is total cost, see JD Edwards pricing models and our guide to cutting JD Edwards licensing costs.

What to do next

1. Baseline. Take a dated baseline of the on premises position across application, database and middleware before anyone outside the company hears the word migration.
2. Separate the layers. Split the application, technology and environment layers in the plan, and give the technology layer its own owner and its own number.
3. Model each route. Calculate the processor requirement on each candidate platform using the counting rule that platform actually uses, instead of the one your on premises servers use.
4. Confirm restricted grants. Identify every restricted use or application specific grant you hold and get its portability confirmed in writing.
5. Price the surroundings. Treat development, test, training and disaster recovery as licensed environments, at the size they will actually run.
6. Set your limits. Decide in advance which entitlements you are willing to convert permanently, and which you will not convert at any price.
7. Keep two routes open. Hold both costed routes until the paper is agreed, with independent Oracle advisory reviewing the terms before signature.

Frequently asked questions