Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Projects Planning in EPBCS - What you need to know before you kick start. | Main | Analytics and the APP! »

Instance Planning/deployment options for migrating Oracle E-Business Suite and other packaged applications on to Oracle Cloud (IaaS and PaaS)

The advent of cloud has thrown open a wide array of options for deployment of applications and databases. Coming to Oracle cloud, it has thrown open so many additional options and so many different permutations and combinations that it is easy to choose sub-optimal options and end up with increased costs, maintenance and lack of control. This blog will try to clear the air around the various options that are available in Oracle Cloud (IaaS and PaaS) for deployment of packaged Oracle E-Business Suite (EBS) application and database. A similar yardstick may be used for deployment models for other Oracle packaged applications like JDE, PeopleSoft, Siebel, etc. which need to deployed using IaaS/PaaS.


The Basics:

The basic building blocks of any packaged application (or any application for that matter) are the application tier, database tier (utilizing CPU, Memory, Storage supported by OS) and the network connectivity (within and outside the tiers). The architecture given below depicts a very simple deployment of Oracle EBS with a single node (server), one each for application and database making it a 3 tier deployment. Technically speaking it is possible to have the application and database tiers deployed on a single node as well but for representation purposes, these have been considered separate. Pl. note that individual tiers (DB and App can be spread across multiple nodes as well).

Fig 1

Available Options in Cloud:

To summarize, Oracle IaaS has below available options (from

Compute Shapes

RAC for HA not available - more suitable for application tier and DR


General Purpose (Oracle Public Cloud - OPC*)


General Purpose

High Memory Shapes

High IO Shapes

GPU Shapes

CPU and Memory Range

1-32 OCPU's

7.5-240 GB

1-32 OCPU's

15-480 GB

1-16 OCPU's

15-240 GB

*used for specialized scenario hence not discussed here


Dedicated Compute


Model 500, 1000, 1500, 2000

SPARC Model 300

CPU and Memory Range

500-2000 OCPU's*

*(assume 7.5 GB to 15GB Memory available per OCPU)

300 OCPU's (SPARC)*



Bare Metal

More robust and performance intensive and with flexibility of bringing your own VM but with usage commitment of 12 month period for pre-determined committed monthly usage amount.


Compute-Bare Metal

Compute-Virtual Machine

CPU and Memory Range

36 OCPU's

256-512 GB

(with High and Dense I/O options for storage)

1-16 OCPU's

7-240 GB

(with Block and Dense I/O options for storage)


Database Cloud Service (DBCS with high or dense I/O capacity)

DBCS with 2 node RAC

CPU and Memory Range

2-36 OCPU's

512 GB

(with High and Dense I/O options for storage)

4-72 OCPU's

2 DB nodes with 512 GB each

(with raw SSD storage)





Comes with and without RAC for HA. DB software license needs to be purchased (BYOL cannot be used)


High Performance Package (HPP*)

Extreme Performance Package

CPU and Memory Range

1-32 OCPU's

7.5-240 GB (General purpose) and 15-480 GB (High Memory)

Same as HPP* except that it includes RAC, Active Guard and In memory options.




Exadata on Cloud

Has all latest Oracle DB features along with highly performant storage (BYOL cannot be used)


Oracle Database Exadata Cloud Machine (ExaCM)

Oracle Database Exadata Cloud Service (ExaCS)

CPU and Memory Range

16-248 OCPU's and 720 GB per DB node. Can be scaled up to 8 DB nodes with 336TB usable storage. Hosted in customer Datacenter

Same as ExaCM* except that this is hosted in Oracle Datacenter


Please note that there are other options also like standard edition, enterprise edition, schema service, standard package, etc. but these have not been mentioned as these are not suitable for packaged applications like EBS.

Typical requirements:

Customers may typically seek below options during various phases/cycles of EBS implementation/development viz., DEV, PATCH, STAGE, GOLD, UAT, SIT, CRP, Pre-PROD, PROD, DR, etc.

Fig 2

How it all fits:

As can be seen from the above matrix (Fig 2.), DB HA (i.e., RAC) is typically not something which would be needed until the SIT instance which means that DBCS is not needed until SIT, which in turn means that all instances prior to SIT could be potentially be built "on demand" on Oracle public cloud (using general purpose shapes like high memory and high I/O shapes).

Building on the above data and 'typical requirements', below matrix shows which EBS implementation phase can typically utilize what type of cloud infrastructure deployment options. E.g., if migration of existing EBS infrastructure needs to be done on to Oracle cloud (IaaS + PaaS) (this assumes that current DB and app licenses will be moved on to cloud), below deployment matrix can be used.

Typical deployment options for moving Oracle EBS to Oracle cloud (with already existing implementations)

In case it is a new deployment altogether (where no previous EBS implementation exists) the above matrix will change as below. Note the usage of DBCS and ExaCS which includes DB software license as well.

Typical deployment options for implementing Oracle EBS on Oracle cloud (green field implementations)

*If HA is not a requirement (which should not be the case except in case of very small enterprise architectures) then DBCS/ExaCS may be replaced with OPC/Bare Metal as needed.

There will be cases where customers with multiple instances of Oracle EBS/packaged applications might look to migrate their entire set of instances to cloud (the number of instances might range from 20 to a few hundred utilizing more than 100 CPU's and more than 500GB of memory). In such cases a more optimal solution might be to go with options like dedicated compute (DC), Bare Metal (BM) and/or ExaCS which offer homogeneity and simplicity of architecture and maintenance. Another case of large deployments might be when customer is moving their entire data center infrastructure to Oracle cloud with multiple instances of Oracle EBS and other applications. Such deployments also would benefit from DC, BM or ExaCS options. Below matrix demonstrates the same.

Typical deployment options for large Oracle EBS implementations on Oracle cloud

Final Words:

The above options for deployment are 'typical ones' which one would encounter and can be used as a standard from which tailored/custom deployment options can be picked. E.g., Oracle cloud also offer private cloud at customer data center which might be useful for cases where regulations prevent customers from hosting outside their own premises/region/country.

From the above description, it is evident that unless an enterprise is completely moving its data center to cloud (and/or has a usage requirement of more than 100 CPU's and 500GB memory) it makes sense to leverage the various features and options like OPC/Bare Metal/DBCS/ExaCS in order to optimize cost and maintenance, rather than going for a big bang approach like dedicated compute, bare metal or a cloud enabled on premise ExaCS.

One caveat though, the world of cloud is changing very fast so it makes sense to frequently check on the Oracle website (would recommend every 2 weeks) for any announcements related to any new option that has been announced by the vendor so that the above models could be optimized further. Now that didn't look too complex - did it?


Very aptly put in Rohit.
Gives out easy to refer template kind document


Thanks Girish!

Very Well written article and very informative and gives good insight on setting up instance on cloud.

Like!! Great article post.Really thank you! Really informative.

Please post some best practice services for migrating EBS to Cloud.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles