JD Edwards on cloud. What travels, what gets re metered.

A JD Edwards cloud migration is a licensing event before it is a technical one. Some entitlements walk across untouched, some are re metered on arrival, and a few are quietly traded away in the paperwork that makes the move possible.

Which JD Edwards entitlements travel to the cloud unchanged?

The ones that count people and things rather than hardware. A JD Edwards estate is three licensing layers stacked on top of each other, and only the middle one is really affected by where the servers live.

What does bring your own license actually do?

It lets you run entitlement you already own on infrastructure you do not own. It does not change the metric, it does not create new rights, and it does not suspend the counting rules of the platform you land on.

Oracle describes the mechanism on its bring your own license page. Everything commercially interesting sits in the conversion arithmetic underneath it.

What does not move, and catches people out

• Territory and entity restrictions. If your order limits use to named legal entities or regions, hosting somewhere else does not widen it.
• 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.

What gets re metered when the workload moves?

The processor based layer, and it is re metered by a document Oracle writes alone. Oracle's cloud licensing policy names Amazon Elastic Compute Cloud, Amazon Relational Database Service, the Microsoft Azure Platform and Google Cloud Platform as Authorized Cloud Environments and sets out how it intends to count there.

The counting rule is simple and expensive. Two virtual processors equal one Processor license where hyperthreading is enabled, one equals one where it is not, and the Processor Core Factor Table does not apply at all.

Why Oracle Cloud Infrastructure is a different conversation

Because it is not an Authorized Cloud Environment. It is Oracle's own service, sold under Oracle's cloud service terms, with the entitlement conversion published in the service descriptions rather than in the third party cloud policy.

That usually helps the buyer, and it should still be modelled rather than assumed. Take the conversion for your exact shape and edition from the current service description, and put the number in the business case rather than a rule of thumb somebody remembered from a webinar.

The arithmetic that surprises finance

The same workload, unchanged in every respect, can require twice the processor entitlement after a lift to a named third party cloud. Nothing about the application changed. The counting rule changed.

• Sixteen physical cores on your own Intel hardware conventionally count as eight Processor licenses after the core factor.
• The equivalent thirty two virtual processors on an Authorized Cloud Environment count as sixteen, because the core factor is out of play.
• The gap is the cost nobody budgeted, and it lands on the database line rather than on the JD Edwards line.

Provider documentation will not settle this for you. Amazon describes its managed Oracle service on the RDS for Oracle page, and the licensing count still comes from Oracle's policy rather than from the provider.

Our page on the Oracle cloud licensing policy works through the counting rules, the edition caps and the fact that Oracle can revise the whole document without asking anybody.

Which documents decide the number?

Three, and only one of them carries your signature. Rank them in that 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, stated on its face to be for educational purposes and subject to change without notice. It describes how Oracle intends to apply your agreement to infrastructure it does not own.
• Cloud service descriptions and price lists. They govern Oracle's own services and they bind you at the moment your order references them.

Read the policy in the original rather than in a summary, including 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.

What about the managed multicloud routes?

They change the basis from something you count to something you buy. Where Oracle operates the database estate inside another provider's region, the commercial terms come from the service description rather than from a processor calculation you perform yourself.

Oracle documents one of these routes on its Oracle Database at Azure page, and equivalents exist for other providers. For a JD Edwards estate the attraction is operational rather than licensing, and the licensing consequence still needs pricing before anyone commits.

Two cautions are worth stating plainly, because both cost real money.

• Managed routes consume cloud spend rather than owned entitlement. An estate that moves and keeps paying support on licenses it no longer runs is paying for the same capability twice.
• Nothing will tell you that an entitlement went idle. Oracle documents the application on the JD Edwards EnterpriseOne page, and no report anywhere flags a license you quietly stopped needing.

Which re meters do migration teams miss?

The three that live outside the compute sizing spreadsheet. Each one is invisible in a technical design review and each one has changed the economics of a move we have sat in.

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 for exactly that reason, and its narrowness is a term rather than a technicality.

• It restricts what may use the database, so a reporting tool or a second application sharing that instance is a breach, on premises or anywhere else.
• Its portability is not automatic. Whether a narrowed grant may be deployed on a specific cloud service is a question for 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.

Development, test, training and the environments nobody 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 anybody's model. In the cloud they get their own instances, sized properly, running continuously.

Size the non production estate as a licensing question before it becomes an infrastructure ticket. We have seen the surrounding environments add more to the target position than the production database did.

Disaster recovery, warm and cold

The licensing treatment of a standby depends on what the standby does, not on what 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 Oracle position on data recovery environments and price the design you are actually going to run.

What does Oracle ask for at the migration moment?

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 asks that show up in the paperwork

1. Convert perpetual entitlement into a cloud subscription. Presented as simplification, and it is. 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 lever, and migration planning finds gaps by design.
4. Extend or restructure support. A longer term in exchange for the migration help, which quietly removes your next two termination opportunities.

Is there a route back?

Technically yes, 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.

Note that 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 terms in your own agreement instead.

Where the common advice on JD Edwards cloud migration is wrong

The common advice is to pick the cheapest target platform and negotiate the licensing afterwards, because the technical decision is the hard one. We think that is backwards, and the order of operations costs real money.

The moment you announce a target platform, you have told Oracle which lever it holds. If the target is a third party cloud, the re metering conversation starts from Oracle's policy. If the target is Oracle's own cloud, the incentives change and so does the flexibility on everything adjacent, including the estate you are not moving.

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

A migration is the only moment in a decade when Oracle needs your signature more than you need its goodwill. Almost nobody spends it deliberately.

White Paper · Oracle JD Edwards

Oracle JD Edwards Licensing

Keep JD Edwards licensing under control. Read it free.

Read the white paper

What should you negotiate before the move?

Five things, and all five are cheaper to obtain before the migration is announced than after it. The sequence below is the one that has held up across the moves we have advised on.

The sequence that keeps you in control

1. Baseline first, quietly. Establish the current position on your own hardware before any external conversation starts.
2. Cost two routes fully, including non production and disaster recovery, and keep both alive in writing.
3. Ask the restricted use questions early, when they read as diligence rather than as a confession.
4. Agree the commercial frame before the technical design freezes, because a frozen design removes your alternative.
5. Sign the migration paper and the renewal separately, even if that means an inconvenient gap between them.

Where the adjacent questions are answered

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

What should a buyer do next?

1. 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 three layers in the plan, and give the technology layer its own owner and its own number.
3. Model the processor requirement on each candidate route using the counting rule that route actually uses, not the one your on premises estate uses.
4. Identify every restricted use or application specific grant in the estate and get its portability confirmed in writing.
5. Price development, test, training and disaster recovery as licensed environments, at the size they will actually run.
6. Decide in advance which entitlements you are willing to convert permanently, and which you will not convert at any price.
7. Keep two routes costed and open until the paper is agreed, with independent Oracle advisory reviewing the terms before signature.

Frequently asked questions

Do JD Edwards licenses change when the workload moves to the cloud?

The application metrics do not, because they count people, employees and devices rather than hardware. The database and middleware beneath the application are counted against compute, so those are re metered by the rules of the platform you land on.

Which cloud route needs the fewest Oracle licenses?

It depends on the shape and edition, and it should be modelled rather than assumed. Oracle Cloud Infrastructure runs under Oracle's own service terms with its own conversion, while the named third party clouds are counted by virtual processor with no core factor benefit.

Why does the database requirement rise on AWS, Azure or Google Cloud?

Because the Processor Core Factor Table does not apply on an Authorized Cloud Environment. A workload that counted as eight Processor licenses on your own Intel hardware can count as sixteen after the move without a single technical change.

Is there an Oracle 90 day rule for moving licenses between servers?

Not one that Oracle publishes for its on premises programs. That reassignment restriction comes from other vendors' license mobility terms and has been widely and wrongly repeated in Oracle migration guidance. Read the transfer language in your own agreement instead.

Can an application specific database license move to the cloud?

Do not assume so. A grant that may only be used with JD Edwards is narrower than a full use license, and its deployment on a particular cloud service is a question to put to Oracle in writing before the architecture is signed off.

Do development and test environments need licensing in the cloud?

Yes, on the same basis as production unless your agreement says otherwise. The practical change is that cloud environments are sized properly and run continuously, where on premises they often shared a quiet server that nobody ever modelled.

Should I convert perpetual licenses into a cloud subscription during a migration?

Only as a deliberate decision with a price attached, because it cannot be undone. Perpetual entitlement gives you the option to walk away at a future renewal, and that option has real value even when the current plan says you never will.

When is the right time to negotiate a JD Edwards cloud move?

Before the target platform is announced internally. Once the technical decision is public, your alternative disappears and every commercial conversation afterwards is conducted from a weaker position.