Running Oracle Applications on OCI: EBS, JDE and PeopleSoft

Most large Oracle applications were architected for a data center, not a cloud. E Business Suite, JD Edwards, PeopleSoft, Siebel and the middleware that surrounds them grew up on fixed servers, hand built environments, and tightly coupled tiers. Moving them to Oracle Cloud Infrastructure is not a lift and forget exercise, it is an opportunity to rebuild them on a platform that can finally give them elastic capacity, real disaster recovery, and a sane operating model. But only if it is done deliberately.

This guide is the pillar for our Oracle applications on OCI series. It covers the shared architecture that all these applications need, the workload specific considerations for each major product, the migration approaches, and the operating model that keeps them healthy after go live. The detailed articles in the series go deeper on each application; this guide ties them together.

Why move Oracle applications to OCI at all

The case for running Oracle applications on OCI rests on a few concrete advantages rather than cloud for its own sake. The first is capacity that matches demand. On premises, these applications run on hardware sized for peak load, such as year end or a quarterly close, and that capacity sits idle the rest of the time. On OCI you scale the application tier to the load and pay for what you use, which changes the economics of seasonal workloads substantially.

The second is disaster recovery that is actually achievable. Building a real second site for an on premises EBS or PeopleSoft estate is expensive and rarely done well. On OCI, a standby region with Data Guard for the database and infrastructure as code for the application tier turns disaster recovery from an aspiration into a tested capability. The third is the operating model: managed database services, infrastructure as code, and built in monitoring replace the hand built, undocumented environments that on premises estates accumulate. We cover the DR side in depth in our disaster recovery and high availability on OCI series.

The shared architecture every Oracle application needs

Although each application differs, they share a common architecture on OCI that is worth understanding before looking at any one product. Almost all of them follow a multi tier model: a database tier, an application or middle tier, and a presentation or web tier, with users reaching the application through a load balancer.

On OCI, that maps cleanly to a landing zone with a clear network design. The database runs on a Base Database service, a VM cluster, or Exadata Cloud Service depending on size and performance needs. The application tier runs on compute instances, often behind a flexible load balancer that spreads traffic and provides a stable entry point. The tiers sit in separate subnets with security lists or network security groups controlling traffic between them, and the whole environment lives inside a compartment structure that keeps it isolated and governable.

Getting this foundation right matters more than any application specific tuning, because every application inherits the network, identity, and security design of the landing zone it sits in. A weak landing zone undermines every application on it. This is why our application migrations always start with the landing zone, and why we treat the architecture as shared infrastructure rather than rebuilding it per application.

Choosing the database platform

The database tier is the most consequential choice for any Oracle application on OCI, because it drives performance, cost, and licensing. The main options are the Base Database service for smaller and mid sized workloads, VM clusters for larger ones, and Exadata Cloud Service for the most demanding databases that need extreme performance or already run on Exadata on premises. The choice depends on the size of the database, the performance the application demands, and the licensing model you bring.

Licensing is where this decision becomes genuinely complex, because how you license Oracle Database on OCI, including whether you bring your own licenses or use license included pricing, materially changes both the cost and the available platforms. This is a question where independent licensing advice is worth seeking before the architecture is fixed, because an architecture chosen without understanding the licensing implications can be expensive to unwind.

The major Oracle applications on OCI

Each major Oracle application has its own characteristics on OCI. The sections below summarize the key considerations for each; the dedicated articles in this series go deeper.

E Business Suite

E Business Suite is the most common Oracle application we see moving to OCI, and Oracle provides tooling specifically to support it on the platform. EBS has a particular multi tier architecture with a database tier and one or more application tiers, and it benefits significantly from OCI's ability to scale the application tier and to provide a real DR standby. The migration is well trodden but still requires care around the database move, the application tier rebuild, and the cutover. Our detailed guides cover E Business Suite on OCI architecture and migrating EBS to OCI.

JD Edwards

JD Edwards EnterpriseOne runs well on OCI and benefits from the platform's flexible compute for its enterprise and logic server tiers. The architecture involves several server roles, and the migration focuses on rebuilding these on OCI compute, moving the database, and validating the integrations that JD Edwards estates typically accumulate. Our guide to JD Edwards on OCI setup covers the specifics.

PeopleSoft

PeopleSoft has a distinctive architecture built around its application server, process scheduler, and web tiers, all coordinated through its own tooling. On OCI this maps to compute instances for each tier with the database on a managed service, and PeopleSoft's own deployment tooling can be used to provision environments. The migration pays particular attention to the process scheduler and integration broker. See our guide to PeopleSoft on OCI architecture.

Siebel, WebLogic, Hyperion and SOA Suite

Beyond the big three, OCI hosts the rest of the Oracle application and middleware estate. Siebel runs as a multi tier CRM application with its own gateway and server architecture. WebLogic is the application server underneath much of this estate and has specific clustering and high availability patterns on OCI. Hyperion EPM brings financial planning and consolidation workloads with their own performance profiles. SOA Suite provides the integration backbone that connects these applications. Each has a dedicated guide in this series covering its OCI specifics, including WebLogic on OCI best practices.

Migration approaches compared

For most Oracle applications, replatform is the right balance. A pure lift and shift is fast but carries every on premises limitation into the cloud, where it costs you in efficiency and missed DR opportunity. A full re architecture is rarely justified for packaged applications you do not control the code of. Replatform, where you keep the application but adopt OCI managed services, infrastructure as code, and a proper landing zone, captures most of the benefit at moderate risk. Our service for OCI implementation and migration follows this approach by default.

The migration sequence

Whatever the application, the migration follows a recognizable sequence, and skipping steps is where projects go wrong.

1. Assess. Map the current architecture, integrations, customizations, and dependencies. Oracle applications accumulate undocumented integrations, and finding them now is far cheaper than finding them at cutover.
2. Design the landing zone. Build the network, identity, security, and compartment structure the application will live in, as code.
3. Build the target environment. Provision the database and application tiers on OCI, from infrastructure as code, so the environment is reproducible.
4. Migrate the database. Move the data using the method that fits the size and downtime tolerance, often Data Guard for a low downtime cutover.
5. Rebuild and test the application tier. Stand up the application tiers, point them at the migrated database, and test thoroughly including the integrations.
6. Cut over. Execute the planned cutover, validate, and keep the old environment available for a defined fallback window.
7. Operate. Hand over to a documented operating model with monitoring, patching, and DR in place.

The assessment step is the one most often shortchanged and the one that most determines success. Oracle application estates are full of customizations and integrations that are not documented, and a migration that discovers these at cutover instead of at assessment is a migration in trouble.

Operating Oracle applications on OCI after go live

Migration is the beginning, not the end. Oracle applications on OCI need an operating model that covers database patching, application tier patching, backup and recovery, monitoring, and continuous cost management. On premises, these were often handled by hand and undocumented; the move to OCI is the moment to put them on a proper footing.

Database patching benefits from OCI's managed database services, which automate much of the work that was manual on premises. Application tier patching remains application specific but is made repeatable by infrastructure as code and proper environments for testing patches before production. Monitoring through OCI's observability services gives you alarms and dashboards across the tiers, so problems are caught before users report them. And because these applications can scale, continuous cost management keeps the application tier sized to real demand rather than to peak. Our implementation and managed services connect the build to the run so the operating model is in place from day one.

Cost and licensing realities

Two cost realities shape every Oracle application move to OCI. The first is that the application tier can be scaled, which means the standing cost can be far lower than the on premises equivalent if the estate is managed actively rather than left at peak size. The second is database licensing, which is the largest and most complex cost item and the one most likely to surprise teams that did not plan for it.

The licensing question, including how existing licenses transfer to OCI under bring your own license terms and how the choice of database platform interacts with licensing, can move the total cost of an application estate substantially. This is precisely the area where independent licensing expertise pays for itself, because the rules are intricate and the assumptions an infrastructure team makes can be costly if wrong. We work alongside independent licensing specialists on this exact question so that the architecture and the licensing decision are made together rather than in isolation.

Where to go from here

Running Oracle applications on OCI well comes down to a few principles: build a strong shared landing zone before any application, choose the database platform and licensing model deliberately, replatform rather than blindly lifting and shifting, assess thoroughly before migrating, and put a real operating model in place at go live. The dedicated articles in this series take each application and each phase deeper. Start with the application you are moving, whether that is E Business Suite, PeopleSoft, or JD Edwards, and follow the migration and operations guides from there.

The landing zone comes first

The single most important decision in any Oracle application migration is to build the landing zone before any application touches the platform. The landing zone is the shared foundation of network, identity, security, and compartment structure that every application inherits. Build it well once, and every application that lands on it benefits. Build it poorly, or skip it and let each application improvise its own, and you accumulate inconsistency, security gaps, and a governance problem that grows with every workload.

A proper landing zone defines how compartments isolate environments and applications, how identity and access are managed, how networks are segmented and connected back to on premises, and how security baselines are applied uniformly. For an estate that will eventually hold several Oracle applications, this foundation is what keeps the estate coherent as it grows. Treating it as the first deliverable, rather than something assembled around the first application, is one of the clearest markers of a migration that will age well.

Integrations are where the risk lives

Oracle application estates are rarely standalone. E Business Suite talks to reporting tools, PeopleSoft integrates with downstream systems, JD Edwards connects to logistics and finance feeds, and SOA Suite often sits in the middle wiring them together. These integrations are where migration risk concentrates, because they are frequently undocumented, built up over years, and known only to a few long serving staff. A migration that maps the application tiers carefully but overlooks the integrations discovers them at cutover, when an interface that nobody remembered silently stops working.

The defense is a thorough integration discovery during assessment, before any migration work begins. Every inbound and outbound interface, every batch feed, every external connection has to be catalogued, understood, and included in the test plan. This work is unglamorous and it is exactly the work that separates a smooth cutover from a painful one. Our migration guides for each application, including migrating EBS to OCI, treat integration discovery as a first class phase.

Environments and the path to production

Oracle applications need a set of environments beyond production: development, test, and often one or more staging or training environments that mirror production. On premises, these were expensive to maintain and often diverged from production or were shared in ways that caused conflict. On OCI, the ability to define environments as infrastructure as code and to scale or stop them when not in use changes this picture entirely.

The right practice is to define each environment from the same code, parameterized for its purpose and size, so that a test environment is a true smaller mirror of production rather than a hand built approximation. Non production environments can be scaled down or stopped outside working hours to control cost, which is one of the clearest savings OCI offers for application estates that traditionally ran their non production fleet around the clock. This discipline also underpins reliable patching and upgrades, because changes can be proven in an environment that genuinely resembles production before they reach it.

Performance and sizing on OCI

Sizing an Oracle application on OCI is different from sizing it on premises, and carrying over the on premises sizing directly usually leads to over provisioning. On premises, hardware was bought for peak and for several years of growth, so it was deliberately oversized. On OCI, you size to current demand and scale as needed, which means the right starting point is often smaller than the on premises footprint, with headroom added through scaling rather than through permanent excess capacity.

The database tier sizing depends on the workload's real performance profile, which the assessment should measure rather than assume. The application tier sizing depends on concurrent user load and batch processing demand, both of which vary through the day and the period, which is exactly why the application tier benefits from being scalable. Getting sizing right at the start, and then managing it continuously, is the difference between an application estate that costs what it should and one that quietly runs at twice the necessary size. This continuous sizing is a core part of the operating model and of our cost optimization work.

Security and compliance for application estates

Oracle applications hold some of the most sensitive data a business has: financials, employee records, customer information. Their security on OCI is inherited largely from the landing zone, which is another reason the landing zone matters so much, but it also requires application specific attention. Network isolation keeps the database tier unreachable except from the application tier. Identity and access controls govern who can administer the environment. Encryption protects data at rest and in transit. And audit logging records what happens for compliance.

For regulated industries, the compliance requirements may also shape where the estate runs, which is where OCI's range of region options, including dedicated and sovereign deployments, becomes relevant. The security design should be part of the architecture from the start, not added afterward, because retrofitting security into a running application estate is far harder than building it in. This connects to the licensing and compliance side of any Oracle move, where independent expertise is valuable.

Phasing a multi application migration

Most organizations moving Oracle applications to OCI are not moving one application, they are moving an estate, and the order in which they move matters. The instinct to start with the most critical application is usually wrong, because it puts the highest stakes workload on a platform the team is still learning. A better approach is to start with a workload that is meaningful enough to prove the landing zone and the operating model, but not so critical that early mistakes are catastrophic.

This lets the team build confidence, refine the landing zone, and mature the operating model on a forgiving workload before the critical ones move. The landing zone built for the first application then serves the rest, and each subsequent migration is faster and lower risk because the foundation and the team's experience are already in place. Phasing the estate this way, foundation first, then a proving workload, then the critical ones, is how large Oracle estates move to OCI without betting the business on the first cutover.

Measuring success after go live

A migration is successful not when the cutover completes but when the application runs well, recovers reliably, and costs what it should over the months that follow. Defining what success looks like before the migration, in terms of performance, recovery capability, and cost, gives you something to measure against afterward. Performance is measured against the user experience and the batch windows the business depends on. Recovery is measured by rehearsed failover times against the agreed targets. Cost is measured against the budget the business approved, with continuous management keeping it there.

Tracking these after go live closes the loop on the migration and turns the estate into something that is managed rather than merely moved. It also surfaces the optimization opportunities that almost always exist once an application has been running on OCI for a while and its real usage patterns are visible. This is where the operating model and continuous cost management earn their place, and where the move from a data center mindset to a cloud one is finally complete.