JD Edwards on cloud. The licensing shift.

Moving JD Edwards to OCI, AWS, or Azure changes how the licenses count and move. This guide covers the three cloud routes, the metric mapping, the mobility rules, and the route decision.

What are the three cloud routes for JD Edwards?

JD Edwards runs on three main cloud routes, and each treats licensing differently. The application metric travels in all three. The database underneath follows the rules of the target platform. Oracle describes the product on its JD Edwards EnterpriseOne page.

Oracle Cloud Infrastructure

On OCI, owned licenses move with full mobility, and the core factor still applies on dedicated shapes. This route usually carries the lowest database license count for the same workload.

Amazon Web Services

On AWS, the Oracle cloud policy counts vCPUs and the core factor does not apply. The database count can rise against an on premises baseline. AWS documents the database service on its RDS for Oracle page.

Microsoft Azure

Azure is an authorized cloud environment, so the vCPU rule applies as it does on AWS. A managed path also exists through Oracle Database at Azure.

How does the metric map by route?

The application stays on its user or module metric. The database moves to the counting rule of the platform. Map both layers before you choose a route. The cloud counting rule sits in the Oracle cloud licensing policy.

The on premises to cloud move

Moving owned licenses to the cloud uses bring your own license. Oracle supports this through bring your own license. The count then follows the target platform rule.

What mobility rules apply when JD Edwards moves?

License mobility decides whether you can move owned licenses to a platform and back. OCI offers the most generous mobility. AWS and Azure apply the vCPU rule and reassignment limits.

The cloud to on premises return

A return from cloud to on premises can trigger reassignment limits. Oracle restricts how often a license can move between hosts, which the 90 day rule governs for many programs.

• 90 day rule. Many programs limit reassignment between servers more than once every 90 days.
• Dedicated host. A dedicated host on AWS can preserve more favorable counting.
• Baseline first. Establish the on premises position before any move.

Where the common advice on JD Edwards cloud migration is wrong

The standard advice is to focus the migration plan on the application metric because that is what users see. We disagree. In roughly 6 of 10 moves we advised on, the application metric was handled well while the database layer drove a 20 to 35 percent cost surprise under the cloud vCPU rule. The database, not the application, is where the value leaks. The buyer side move is to model the database count on each route, compare OCI mobility against the AWS and Azure vCPU rule, and baseline the on premises position before committing to a target.

30

JD Edwards cloud moves 2024 to 2025

6 in 10

Moves where the database drove the surprise

27%

Median database overspend we avoided

Source: Redress Compliance advisory engagement file, 2024 to 2025.

In a JD Edwards cloud move, the application metric travels quietly. The database is where the licensing bill changes.

How should a buyer choose the JD Edwards cloud route?

The route decision turns on database cost, mobility, and operational fit.

• OCI. Lowest database count for the same workload, with mobility and core factor.
• AWS. Broad ecosystem, vCPU counting, dedicated host option for tighter control.
• Azure virtual machines. vCPU counting, strong fit for Microsoft heavy estates.
• Oracle Database at Azure. Managed Oracle inside Azure for low operational effort.
• Baseline. Compare every route against a clean on premises license position.

What should a buyer do next?

1. Baseline the current JD Edwards license position on premises before any move.
2. Separate the application metric from the database count in the plan.
3. Model the database count on OCI, AWS, and Azure for the same workload.
4. Compare OCI mobility and core factor against the AWS and Azure vCPU rule.
5. Check reassignment and 90 day rule limits for any planned move back.
6. Choose the route on total database cost and operational fit, not application metric alone.
7. Engage independent Oracle advisory before signing a JD Edwards cloud move.

Frequently asked questions

Do JD Edwards licenses change when moving to the cloud?

The application user and module metrics travel unchanged. The database underneath moves to the counting rule of the target platform, which is where most of the cost change happens.

Which cloud route is cheapest for JD Edwards licensing?

OCI usually carries the lowest database license count for the same workload because owned licenses move with mobility and the core factor still applies on dedicated shapes.

How does the database count change on AWS and Azure?

On AWS and Azure the Oracle cloud policy counts vCPUs and the core factor does not apply. The database license count can rise by 20 to 35 percent against an on premises baseline.

What is the 90 day rule?

Many Oracle programs limit how often a license can be reassigned between servers to once every 90 days. It matters when you plan to move workloads between hosts or back from cloud.

Can I bring my own JD Edwards database licenses to the cloud?

Yes. Bring your own license moves owned licenses to OCI, AWS, or Azure. The count then follows the rule of the target platform, with OCI offering the most generous mobility.

What is Oracle Database at Azure?

Oracle Database at Azure is a managed service that runs Oracle database hardware inside Azure data centers. It lowers operational effort and follows the service terms rather than self managed counting.

What is the most common JD Edwards cloud migration mistake?

Planning the application metric carefully while underestimating the database layer. On non OCI routes the lost core factor and the vCPU rule drive a cost surprise that a baseline would have caught.

How do I choose a JD Edwards cloud route?

Model the database count on each route, compare OCI mobility against the AWS and Azure vCPU rule, and weigh operational fit. Always measure each route against a clean on premises baseline.