Oracle Fusion Middleware to the Cloud

More and more often, we are contacted to assess, challenge, and advise on the migration of Oracle Fusion Middleware platforms to the cloud.

These discussions usually involve critical environments based on Oracle WebLogic Server, Oracle Forms, and sometimes Oracle Reports. The objective is rarely just to “move to the cloud”. It is about understanding what can realistically be migrated, what should be modernized, what must be validated, and where the main technical, operational, and licensing risks are.

Based on these discussions, I would like to share a few practical considerations that may be useful when evaluating a cloud migration strategy for Oracle Fusion Middleware workloads.

Lift and shift is not a shortcut, it is a controlled migration strategy

For Oracle WebLogic, Forms and Reports platforms, a cloud migration should not automatically be presented as an application modernization project.

In many cases, the first realistic step is a lift-and-shift migration. The goal is not to rewrite Forms modules, redesign the full application, or replace every legacy component immediately. The goal is to rebuild a controlled target platform in the cloud while preserving the application behavior as much as possible.

However, lift and shift does not mean copying virtual machines and hoping that everything will work.

A serious migration requires a detailed comparison between the existing platform and the target one: WebLogic domain configuration, Managed Servers, Datasources, Wallets, Certificates, JVM version, Patch level, Forms runtime configuration, Reports configuration, File system dependencies, Fonts, Printers, Batch jobs, Monitoring, Backup, Restart procedures, and Operational scripts.

Oracle documents several WebLogic migration approaches to OCI, including manual deployment, WebLogic Deploy Tooling, and WLST-based deployment scripts targeted to a new domain. Oracle also describes WebLogic Server for OCI as a way to provision a WebLogic domain in OCI more quickly than a traditional on-premises setup.

This is why lift and shift should be seen as an engineering exercise, not as a low-effort infrastructure move.

Why OCI is naturally aligned with Oracle Fusion Middleware

It would not be accurate to say that Oracle Fusion Middleware can only run on OCI. Oracle’s own cloud licensing policy lists AWS, Azure, and Google Cloud Platform as “Authorized Cloud Environments” for specific Oracle software licensing rules. The same policy also explains how vCPUs must be counted in these environments and states that the Oracle Processor Core Factor Table is not applicable there.

So the real point is not that other clouds are impossible. The point is that OCI is naturally aligned with Oracle Fusion Middleware workloads.

For WebLogic, Oracle provides OCI-specific deployment models, Marketplace-based options, and documented migration patterns. For Kubernetes-based deployments, Oracle also documents WebLogic Server for OKE using a Marketplace stack, including lifecycle-management components such as Jenkins and the WebLogic Kubernetes Operator.

From an operational and licensing perspective, OCI also gives Oracle customers options such as BYOL and Universal Credits-based models. Oracle’s Support Rewards FAQ states that BYOL services on the Universal Credits Model rate card are eligible for the Support Rewards program.

This does not remove the need for a proper license review. But it does mean that for Oracle middleware workloads, OCI often provides a more Oracle-native discussion: infrastructure, middleware, licensing, support model, and target architecture can be addressed within the same ecosystem.

Oracle Reports must be treated as a specific risk

For Oracle Forms and WebLogic, a structured lift-and-shift approach to OCI can be a realistic option. For Oracle Reports, the discussion must be more careful.

Oracle Reports is still present in many enterprise Forms platforms, but it has technical characteristics that must be validated before any cloud migration. Reports cluster members or clients use multicast to discover other nodes, and that there is no workaround for using multicast in that context.

This is a critical point because multicast is generally not available in all cloud network architectures.

In practical terms, Oracle Reports should not be treated as a simple checkbox in the migration plan. It requires a dedicated technical validation: Reports Server configuration, naming service, generated output, cache behavior, fonts, printers, file paths, batch execution, restart behavior, and integration with the Forms application.

Conclusion

The conclusion is therefore simple: WebLogic and Forms can be good candidates for a controlled lift-and-shift migration to OCI. Oracle Reports must be assessed separately, tested carefully, and challenged architecturally.

OCI can reduce complexity for Oracle Fusion Middleware migrations, but it does not remove the need for deep product expertise. A successful migration is not only a cloud project, it is a WebLogic, Forms, Reports, licensing, operations, and validation project.

If you are planning to migrate an Oracle Fusion Middleware platform to the cloud, or if you simply want to assess whether such a migration is realistic for your environment, feel free to contact me. I would be happy to help you challenge the architecture, identify the risks, and define a pragmatic migration approach.

More related blogs here.