Your Oracle E-Business Suite R12 Upgrade – Point Upgrades or Big Bang

There are lots of companies that offer a route to a Oracle E-Business Suite R12 upgrade, but have you considered how many upgrade routes there are and how many options you have within a particular upgrade path?

What do we mean by this?

Any R12 upgrade will involve the same key aspects typically Physical or Virtual, OS upgrade implications, Hardware requirements, Database version and point release. The decision around this is if to tackle all of these areas under one ‘Go Live’ or split them out into component pieces. We will first look at each of these items and then summarise.

Physical or Virtual

You may already be using E-Business Suite in a Virtual environment and as such you will already be aware of the licensing pitfalls using certain VM platforms - a word of caution before you virtualize your E-Business Suite estate which is to ensure you are not breaching your licensing agreement.

With licensing out of the way and from a project perspective do you go virtual at the same time as going live with you R12 upgrade? Whilst virtual environments give a wide range of benefits you should ensure that E-Business Suite performs in the same manner as it would hosted on a physical server. This would typically involve load testing, point testing, backup/recovery and OS performance monitoring.

It would be the advice here to virtualize the existing environments ahead of the upgrade allowing you live 11i environment a de-risked upgrade route also ensuring all project environments are using the same underlying technology. This activity, if it goes to plan, should be transparent to the end user.

OS version

Customers are very unlikely to upgrade an existing Operating system if it is currently in support, stable and proven. A R12 upgrade is a good opportunity to upgrade the operating system and bring it in line with the latest supported release for E-Business Suite.

The key question here is if to perform this upgrade ahead of time or at the same time as the R12 Go Live. The advice here would be to create a matrix to determine the risk. Factors that should be take into account are:

• Is it 32 to 64 bit change?

• Is it the same flavour of OS? i.e. sticking with Red hat

• Is it a simple point release change?

• Is your current version of E-Business Suite supported by the target OS?

Based on the answers to the above questions a decision can be taken in terms of the correct and least risky option. For example if the outcome is No/Yes/Yes then this is something that should be done ahead of the R12 upgrade allowing some more risk to be removed.

RAM, storage and CPU (Hardware)

This question is probably the easiest to answer but coupled with the above two points it’s not always a straight forward process.

Initially a review of the current physical or virtual environment needs to be undertaken and then compare this recommended sizing created for R12. This will be based on number of users, daily increase in data volume, E-Business Suite footprint, peak user load and performance/other criteria.

Storage is generally easy to extend in today’s environments and this is something that should be done ahead of the upgrade.
In a physical or virtual environment RAM is very easy to add with a minimal amount of downtime and very little testing. This is another item that can be done well in advance of the main upgrade.

Assessing your CPU requirement can be slightly more costly as depending on footprint and products used it may come with an Oracle licensing implication.

Database Version

Initially we will need to establish your target database version for your R12 upgrade. If your R11 environment is on a very new database version then you have very little, if any work to do. In most instances over the last 4-5 years Oracle have certified R11 and R12 up-to the same database level. An example of this is R11, R12.1 and R12.2 are all certified with database version 11.2.0.4 and 12.1.0.1.

Database upgrades usually comprise of a set of technical patches and as such requirement very little business or end user involvement. Whilst the upgrade may give performance increase and bug fixes but by and large the E-Business Suite end user would notice very little difference and this upgrade should be transparent to the end user.

Performing this database upgrade ahead of the main R12 upgrade will significantly reduce the downtime window of the R12 upgrade.

Point Release

The advantages / dis-advantages of upgrading to R12.1.3 or R12.2.x will be addressed in a separate blog as either option results in a R12 upgrade with the determining factor being the customer having a clear view of both options. These views can only really come from a company such as dsp who have performed both upgrades and have first-hand experience of both upgrade routes.

There is always a flip side to breaking down the upgrade into smaller chunks and this is typically more downtime windows, more test phases and probably slighter higher overall cost.

However the result is a reduction to risk, a smaller R12 upgrade downtime window and a smoother delivery of the upgraded R12 environment.