Oracle E-Business Suite can run effectively on Oracle Cloud Infrastructure, but moving EBS into OCI is not simply a hosting exercise. A good architecture has to consider the application tier, database tier, network, integrations, security, resilience, recovery and day-to-day operations as one design.
The objective is not to reproduce an on-premises environment resource for resource. It is to understand what EBS needs and use OCI services in a way that improves supportability without introducing unnecessary complexity.
Start with the EBS workload, not the cloud services
Architecture should begin with the actual EBS workload. Review the current application topology, database platform, concurrent processing, integrations, batch activity, storage growth, user volumes and availability requirements.
This provides a baseline for deciding which OCI services, instance shapes and resilience patterns are appropriate.
DNC’s Oracle and E-Business Suite services support architecture assessment, upgrades and modernisation planning for Oracle environments.
Design clear application and database tiers
EBS normally includes several distinct technical roles. These can include web and forms services, concurrent processing, application file systems, database services and supporting integration components.
The OCI design should make those roles clear and avoid unnecessary mixing of responsibilities. This helps with scaling, patching, troubleshooting and recovery.
The database tier should be designed around the required Oracle version, support model, performance profile and recovery strategy rather than being treated as another generic virtual machine.
Build the network around trust boundaries
The EBS environment should sit within a network design that clearly separates application, database, management and external connectivity where appropriate.
Subnets, route tables, network security groups, security lists and gateways should reflect genuine communication requirements.
Database systems should not be publicly exposed. Administrative access should also use controlled paths rather than broad inbound rules.
Plan connectivity before migration
EBS rarely operates alone. It may depend on identity platforms, email, file transfers, reporting systems, middleware, payment systems, HR platforms, on-premises services and third-party applications.
Those dependencies need to be mapped before the migration design is finalised.
Connectivity through VPN, FastConnect, private peering or other routes should be sized and tested against both normal and recovery scenarios.
Design for availability at each layer
High availability should be considered across the complete service chain.
Application servers may need to be distributed across fault domains or availability domains. Load balancing should remove failed application nodes from service. Database availability should be matched to the business requirement and the Oracle technology in use.
The architecture should also consider DNS, network paths, file systems and external dependencies because resilience is only as strong as the weakest critical component.
Separate high availability from disaster recovery
Local availability and disaster recovery solve different problems.
An EBS environment may remain available during the loss of one server but still be vulnerable to a regional outage, corruption event or major operational error.
Where the business requires regional recovery, the architecture should define how the application tier, database, storage, configuration and supporting services are recovered in the secondary region.
Make backup and restore part of the design
Backups should cover the full EBS service, not only the database.
The organisation needs to understand how database backups, application file systems, configuration, custom code and infrastructure definitions are protected.
Retention, encryption and access controls matter, but restore testing matters more. A backup strategy is only useful when the environment can be recovered within the required time.
Protect privileged access
EBS on OCI introduces several layers of privileged administration, including OCI administrators, operating system administrators, Oracle DBAs and EBS application administrators.
Those privileges should be separated where possible, protected with strong authentication and reviewed regularly.
Service accounts, SSH keys, API credentials and automation identities should also be managed as part of the IAM design.
DNC’s Cyber Security services can complement EBS architecture work with identity, configuration and security control reviews.
Encrypt and manage secrets properly
Data encryption should be considered for storage, database connections, backups and external integrations.
Passwords, wallet files, private keys and application secrets should not be stored casually in scripts or shared directories.
Where appropriate, OCI Vault and controlled secrets-management processes can reduce the dependence on long-lived credentials.
Design storage for EBS behaviour
EBS storage requirements are not limited to capacity. Performance, latency, sharing, backup and growth all matter.
Application file systems may need to be accessible across multiple application nodes. Database storage must support the expected I/O profile. Archive logs, interface files and temporary data can also grow significantly.
Storage should therefore be sized using measured workload behaviour rather than simple capacity estimates.
Include monitoring from the beginning
Monitoring should cover OCI resources, operating systems, database health and EBS application behaviour.
Key signals can include instance availability, CPU, memory, filesystem capacity, database waits, listener status, concurrent manager health, application response and failed backup jobs.
Alerts should have clear ownership so that an event results in action rather than becoming another ignored notification.
Use automation where it reduces risk
Infrastructure as Code can help make network, compute and supporting services repeatable.
Automation should also be considered for patching, backup operations, monitoring configuration and environment provisioning where appropriate.
The aim is not to automate every task. It is to remove avoidable manual variation from processes that need to be repeated reliably.
Document ownership and support responsibilities
EBS environments often involve several teams and suppliers. OCI infrastructure, firewall management, operating systems, Oracle database, EBS application support, backups and monitoring may all have different owners.
The architecture should record those responsibilities clearly, particularly for incidents and disaster recovery.
What good looks like
A strong EBS on OCI architecture has clear tier separation, controlled network paths, appropriate database resilience, tested backup and recovery, secure privileged access and monitoring across the full service.
It also has an operating model that explains who manages each layer and how changes are controlled.
Conclusion
OCI can provide a strong platform for Oracle E-Business Suite, but the value comes from thoughtful architecture rather than simply relocating servers.
The best designs start with the EBS workload, map its dependencies and build security, resilience and operations into the platform from the beginning.
If you need help assessing or designing an Oracle E-Business Suite environment on OCI, see DNC’s Oracle and E-Business Suite services or contact DNC.