Running Oracle Applications on Azure with Oracle Database@Azure
Oracle Database@Azure for Mission-Critical Applications
Article Overview
Most large Oracle shops do not run just a database — they run big Oracle applications on top of it: E-Business Suite for ERP, JD Edwards or PeopleSoft for their own mix of business functions, Hyperion for financial planning, and a long tail of custom apps built over the years. Oracle now supports running these applications on Azure with the database on Oracle Database@Azure, and the good news is that they all follow the same simple shape. The application runs on Azure virtual machines, the database runs on Exadata, and a fast private link joins them. This article explains that shared pattern in plain language, shows it in one high-level diagram, and then walks through what is specific to each application family — EBS, JD Edwards, PeopleSoft, Hyperion, and custom apps — so you can see both the common backbone and the per-app details. Where the E-Business Suite post on this blog goes deep on one application, this one gives you the whole portfolio view.
1.The Shared Shape: Split-Tier
Before we look at each application, it helps to see the one idea they all share. Every one of these Oracle applications is built in tiers: a web tier that users reach, an application tier that runs the business logic, and a database tier that holds the data. On this platform, you split those tiers across two places. The web and application tiers run on Azure virtual machines. The database tier runs on Exadata through Oracle Database@Azure. A fast, private link connects the two.
This is called a split-tier design, and it is the heart of every architecture in this article. You keep the application exactly as it is built — the same web and application servers, the same file systems, the same tools — and you simply run them on Azure VMs. The database moves onto Exadata, where it gets the performance and availability that Exadata is known for. Nothing about the application has to be rewritten; the tiers just live in the right home for each.
The rule is simple: run the application on Azure VMs, run the database on Exadata, and join them with a fast private link. Every Oracle app in this article is a variation on that one idea.
Why split the tiers at all?
Because each tier wants a different home. The web and application tiers are ordinary servers that run happily on Azure VMs, where they sit close to the rest of your Azure world — identity, networking, and other apps. The database wants Exadata, which is built for heavy Oracle workloads. Splitting them lets each tier run where it is strongest, while the fast link keeps them working together as one system.
2.The High-Level Architecture
Here is the shared design in one picture. Read it left to right: users come in, reach the application tiers on Azure VMs, and those tiers talk to the database on Exadata over the private link. This is the same drawing for EBS, JD Edwards, PeopleSoft, Hyperion, and custom apps — only the boxes inside the application tier change from one app to the next.
Learn this one drawing and you understand them all
The reason this article can cover five very different applications without getting long is that they share this drawing. Once you understand the split-tier shape — app on Azure VMs, database on Exadata, private link between — each application below is just a small set of changes to the middle box. Learn the shape once, and every Oracle app becomes a variation you already half-understand.
3.Why This Pattern Works Well
Splitting the tiers this way is not just tidy — it gives you real benefits. Oracle and Microsoft built the platform so that the database runs in the same Azure data center as your application VMs, joined by a fast private link. That closeness matters a lot for these applications, because the app tier and the database talk to each other constantly, and short distances mean quick answers.
Low latency
The database sits in the same data center as the app VMs, so the constant back-and-forth between them stays fast. For chatty Oracle apps, this is the difference between snappy and sluggish.
No rewrite needed
The application runs the same way it always has. You move where the tiers live, not how the app is built, so the risk and effort are far lower than a rebuild.
Exadata for the data
The database gets Exadata's performance and availability — RAC, Data Guard, smart storage — which is exactly what a busy ERP or planning system needs underneath it.
Azure for everything else
The app tier sits next to your Azure identity, network, monitoring, and other apps, so it fits naturally into the rest of your cloud estate.
Officially supported, not just possible
This is not a clever workaround. Oracle has published support policies for running E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, Enterprise Performance Management (Hyperion), and Oracle Retail on Azure with Oracle Database@Azure. That means you can run these applications this way with proper backing, not as an unsupported experiment — though you should always check the current support details for your exact versions before you build.
4.E-Business Suite
E-Business Suite (EBS) is Oracle's big ERP application — finance, supply chain, HR, and more, all sharing one large database. It is the classic split-tier app: a web tier, an application tier with the concurrent processing and forms services, and a heavy database underneath. On this platform, that database is an excellent fit for Exadata, while the EBS application tier runs on Azure VMs.
| EBS tier | Where it runs |
|---|---|
| Web / forms tier | Azure VMs |
| Application tier (concurrent managers, services) | Azure VMs, with shared file system |
| Database tier | Exadata on Oracle Database@Azure |
The one EBS-specific detail worth knowing is that after moving the database, you point the EBS application tier at its new home — the connection details that EBS keeps in its configuration are updated so the app tier finds the database on Exadata. EBS has its own tools for this, and the full step-by-step is covered in the dedicated E-Business Suite post on this blog. Here, the key point is simply that EBS follows the shared shape cleanly: app tier on Azure, database on Exadata.
Deep-dive on this blog
The "Oracle E-Business Suite on Oracle Database@Azure" post covers EBS in full — the certified database versions, the licensing rule for the application tier, and the exact cutover steps to re-point EBS at the new database. If EBS is your focus, read that next; this section places it in the wider family.
5.JD Edwards EnterpriseOne
JD Edwards EnterpriseOne (JDE) is another full ERP suite, popular in manufacturing, distribution, and construction. Its architecture has a few more named tiers than some apps, but it follows the same split-tier rule: all the JDE server roles run on Azure VMs, and the database runs on Exadata.
Web / HTML servers
The user-facing tier that serves the JDE web interface — runs on Azure VMs behind a load balancer, scaled out for the number of users.
Enterprise / logic servers
The servers that run JDE's business logic and batch work — run on Azure VMs, close to the database for speed.
Database on Exadata
The JDE database runs on Oracle Database@Azure in its delegated subnet — the shared backbone every app here uses.
Because JDE has several server roles that all talk to the database, the low-latency private link is especially valuable here — a lot of small messages move between the logic servers and the database, and keeping them in the same data center keeps the whole system responsive. For disaster recovery, the database uses Active Data Guard, and the JDE application files are kept in step across regions with a file-sync tool, so both halves can recover together.
Keep the chatty tiers close together
JDE's logic servers and database exchange a lot of quick messages. The single most important layout choice is to keep them in the same region and data center, so those messages travel the shortest possible distance. The platform is built for exactly this — app VMs and database side by side — so lean into it and place the JDE tiers close to the database.
6.PeopleSoft
PeopleSoft is Oracle's suite for HR, finance, and campus systems, widely used in large organizations and universities. Its architecture has a distinctive middle layer — the application servers and process scheduler — plus a web tier and the database. As with the others, every PeopleSoft server tier runs on Azure VMs, and the database runs on Exadata.
| PeopleSoft tier | Where it runs |
|---|---|
| Web tier (PIA) | Azure VMs, behind a load balancer |
| Application server tier | Azure VMs |
| Process scheduler (batch) | Azure VMs |
| Database tier | Exadata on Oracle Database@Azure |
PeopleSoft's application server tier does a lot of the heavy lifting and talks to the database constantly, so — like JDE — it benefits strongly from sitting close to the database on the fast private link. A nice extra on this platform is that PeopleSoft can use Microsoft Entra ID for single sign-on, so users sign in with the same company credentials they use for everything else in Azure. The pattern is the same shared shape, with PeopleSoft's own tiers filling the application box.
Single sign-on is a real win here
Because the application tier lives in Azure, connecting PeopleSoft sign-in to Microsoft Entra ID is natural. Users get one login across their Azure world and PeopleSoft, and you get one place to manage access and enforce multi-factor authentication. It is a small piece of the architecture but a noticeable improvement in day-to-day life for users and administrators alike.
7.Hyperion (EPM)
Hyperion — part of Oracle's Enterprise Performance Management (EPM) family — is used for financial planning, budgeting, consolidation, and the financial close. Its architecture includes web and application tiers plus Oracle Essbase, the calculation engine at the heart of planning work. All of these run on Azure VMs, and the supporting database runs on Exadata.
Web tier
Serves the Hyperion interface to finance users — runs on Azure VMs behind a load balancer.
Application tier + Essbase
The application services and the Essbase calculation engine — the core of planning and consolidation — run on Azure VMs, close to the database.
Database on Exadata
The Hyperion repository database runs on Oracle Database@Azure — the same backbone, giving the close and planning cycles a fast, reliable data layer.
Financial close and planning cycles are demanding — lots of heavy calculation and data movement in short, high-pressure windows — so the low-latency link between the Essbase and application tiers and the database matters. Placing the whole Hyperion stack in the same data center as the database keeps those month-end and quarter-end runs quick. For disaster recovery, the database uses Active Data Guard, and the Hyperion application files are synced across regions so the whole environment can be brought up elsewhere if needed.
Plan for the peak, not the average day
Hyperion is quiet for much of the month and then extremely busy at close and planning time. Size the application VMs and design the layout for those peak windows, not the average day — because the peak is exactly when the business is watching and the deadlines are real. The platform's elasticity helps, but plan the busy days deliberately.
8.Custom Oracle Applications
Beyond the packaged suites, most organisations have their own custom Oracle applications — often built on Oracle WebLogic or other middleware, backed by an Oracle database. These follow the same shared shape as the packaged apps, which is the whole point: if your custom app has an application tier and an Oracle database, it fits the split-tier design without special treatment.
But there is a second, increasingly popular way to build custom Oracle apps that deserves its own picture: Oracle APEX. APEX is a low-code tool for building web apps, and its big difference is that the application itself runs inside the Oracle database. There is no separate application-server tier full of business logic — the logic lives in the database, and a light mid-tier called ORDS (Oracle REST Data Services) sits in front to handle web traffic. On this platform, that makes the design even simpler.
APEX changes where the app runs — and simplifies it
With a normal custom app, business logic sits in an application-server tier on Azure VMs. With APEX, that logic lives inside the database on Exadata, and all you run on Azure VMs is the light ORDS mid-tier that passes web requests through. This is a real advantage on this platform: your app runs right where the data is, on Exadata's fast engine, with far fewer moving parts to manage. If you are building something new rather than moving something old, APEX is well worth considering for exactly this reason.
8.1 WebLogic and other custom apps
| Custom app piece | Where it runs |
|---|---|
| Web / presentation tier | Azure VMs |
| WebLogic / middleware / app logic | Azure VMs |
| Oracle database | Exadata on Oracle Database@Azure |
| Integrations and jobs | Azure VMs or Azure services |
The freedom with custom apps is also the responsibility: because they are yours, you own the testing. The architecture is the same — app tier on Azure, database on Exadata, private link between — but you should test your specific app against the moved database carefully, since only you know its quirks. Custom apps also often connect to other systems, and running them in Azure puts them right next to Azure's integration and data services, which can simplify those connections.
8.2 APEX or WebLogic — which shape?
The two custom-app styles sit at different points on the same platform. Here is the quick comparison so you can see which fits what you are building.
| Oracle APEX | WebLogic / middleware | |
|---|---|---|
| Where the app logic runs | Inside the database on Exadata | In an app-server tier on Azure VMs |
| Mid-tier on Azure VMs | Light — ORDS only | Full application servers |
| Moving parts | Fewer — simpler to run | More — the classic split-tier |
| Best for | New, data-centric apps built low-code | Existing custom apps, or heavy custom middleware |
The shared shape is a gift to custom apps
The best thing about custom apps here is that they do not need a special design. The same split-tier pattern that runs EBS or PeopleSoft runs your home-grown WebLogic app just as well. That means the knowledge you build moving one Oracle app transfers directly to the next, packaged or custom — one pattern, applied again and again.
9.High Availability and DR
A packaged Oracle application is only as available as its weakest tier, so a good design protects both halves — the application tier on Azure and the database on Exadata. The nice part is that each half has a clear, well-proven way to stay up, and together they give you an application that survives failures gracefully.
| Level of failure | Application tier | Database tier |
|---|---|---|
| One server fails | Other app VMs keep serving | RAC keeps the database up |
| A zone has a problem | App VMs spread across zones | Local Active Data Guard standby |
| A whole region is lost | Standby app VMs, files synced across | Data Guard standby in the DR region |
Both halves must fail over together
The common mistake is protecting the database beautifully and forgetting the application tier — or the reverse. An app is only usable when both halves are up in the same place, so design them to fail over together: when the database moves to the DR region, the application VMs there must be ready and the file systems already in step. Test the whole app failing over as one, not just the database. The HA/DR and mission-critical posts on this blog go deeper on this.
10.Common Design Points
Across all five application families, a handful of design points come up every time. Get these right and any of these apps runs well; get them wrong and the same problems appear no matter which app it is.
| Design point | What to do |
|---|---|
| Keep the tiers close | Put the app VMs in the same region and data center as the database, so the constant app-to-database chatter stays fast |
| Delegated subnet | The database goes in the delegated subnet Oracle assigns — plan your address space around it, with no overlaps |
| Private, not public | Reach the database over the private link; keep the app and database off the public internet, with a bastion for admin access |
| Single sign-on | Connect the app to Microsoft Entra ID where supported, so users get one login and you get one place to manage access |
| Least-privilege network | Allow SQL*Net to the database only from the app subnets that need it; deny everything else |
| Protect both halves | RAC and Data Guard for the database; multiple VMs and file sync for the app tier — and test them failing over together |
| Right-size the app VMs | Size the application VMs from real usage, with headroom for the busy periods each app has |
| Back up the right things | The database is protected by Oracle's backup service; the app-tier VMs and file systems are protected separately |
The apps are different, but the good decisions are the same: keep the tiers close, stay private, protect both halves, and size for the busy day. Learn them once and they serve every Oracle app you run.
⚠️ Remember what Azure Backup does and does not cover
A point worth repeating from the backup post on this blog: Azure's own backup tools protect the application-tier virtual machines, but the Exadata database itself is protected by Oracle's backup service, not Azure Backup. For a packaged app, you need both — the app-tier VM backups and the database backups — working together. Assuming one covers the other is how a recovery goes wrong at the worst moment.
11.Frequently Asked Questions
Do I have to rewrite my Oracle application to run it this way?
No. The application runs the same as it always has — same web and application servers, same file systems, same tools. You change where the tiers live (app on Azure VMs, database on Exadata), not how the app is built. That is what keeps the risk and effort low.
Which Oracle applications are supported?
Oracle has published support policies for E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, Enterprise Performance Management (Hyperion), and Oracle Retail on Azure with Oracle Database@Azure. Custom Oracle applications follow the same split-tier pattern. Always check the current support details for your exact product versions before building.
Where does the application tier run?
On Azure virtual machines, in your own Azure virtual network. The web tier, the application tier, and any app-specific services all run on Azure VMs, close to the database for speed, with a bastion for secure admin access and no public exposure.
Where does the database run?
On Exadata, through Oracle Database@Azure, in a delegated subnet that Oracle assigns inside your Azure network. The application tier reaches it over a fast private link, so from the app's point of view the database behaves like a very fast, very reliable local database.
Why keep the app tier and database in the same region?
Because these applications send a lot of small messages between the app tier and the database. Keeping them in the same region and data center makes each message trip short, which keeps the whole application fast. Splitting them across distant locations would add delay to every one of those trips.
Can users sign in with their normal company login?
In many cases yes — because the app tier is in Azure, you can connect the application to Microsoft Entra ID for single sign-on where the product supports it. Users then sign in with the same credentials they use elsewhere, and you manage access and multi-factor authentication in one place.
How do I protect the whole application, not just the database?
Protect both halves. Use RAC and Data Guard for the database, and multiple VMs plus file sync for the application tier, so both can survive failures and recover in the DR region together. The key is testing the whole application failing over as one, not just the database.
Is this different from running the app entirely on Azure VMs?
Yes, in where the database lives. You can run both the app and an Oracle database on Azure VMs, but here the database runs on Exadata through Oracle Database@Azure instead — giving the data layer Exadata's performance and availability while the app tier still runs on Azure VMs.
12.Key Takeaways
The short version
• One shape fits all. EBS, JD Edwards, PeopleSoft, Hyperion, and custom apps all use the same split-tier design: app on Azure VMs, database on Exadata, private link between.
• No rewrite. The application runs as built; you change where the tiers live, not how the app works — so risk and effort stay low.
• Keep the tiers close. App VMs and database in the same region and data center keep the constant app-to-database chatter fast.
• Officially supported. Oracle publishes support policies for EBS, PeopleSoft, JD Edwards, Hyperion (EPM), and Retail on this platform — check the current details for your versions.
• Protect both halves. RAC and Data Guard for the database, multiple VMs and file sync for the app tier — and test them failing over together.
• Learn the pattern once. The knowledge transfers straight from one Oracle app to the next, packaged or custom.
Running Oracle applications on Azure with Oracle Database@Azure comes down to one friendly idea: keep the application where it is happy and give the database the best home you can. The application — whether it is E-Business Suite, JD Edwards, PeopleSoft, Hyperion, or something your team built — runs on Azure virtual machines, right next to the rest of your Azure world. The database runs on Exadata, where it gets the speed and reliability a serious Oracle workload needs. A fast private link joins them, and the whole thing behaves like one system.
The real gift of this pattern is that it is the same for every app. Once you understand the split-tier shape and the handful of common design points — keep the tiers close, stay private, use single sign-on, protect both halves, size for the busy day — you can run any Oracle application this way with confidence. Learn it on one app, and you are ready for the next. That is what makes moving a whole Oracle portfolio to this platform far less daunting than it first sounds: underneath the different names and tiers, it is one simple, repeatable design.
Application support policies, certified versions, supported database services, and platform features reflect Oracle and Microsoft documentation available at the time of writing and change often — check the current support policies and reference architectures for your exact application and database versions against Oracle and Microsoft documentation before designing or building. The diagrams are high-level and conceptual, not deployment templates, and each application has its own detailed setup steps. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments