Best Practices for Combining EBS Upgrades with Platform Migrations

Odds are that you're planning an EBS upgrade soon.  EBS 11i Extended Support runs out in 2013, and EBS 12.0 Premier Support ended in January 2012. You might need to combine your EBS upgrade with a operating system upgrade or hardware migration for your servers, too.

Projects that combine EBS upgrades with migrations pose some interesting questions.  What tools do you use if you're...:

  • ... upgrading to a newer version of your current operating system?
  • ... migrating to a different platform with the same endian format?
  • ... migrating to a different platform with a different endian format?

Diagram showing small endian and big endian platforms

Evaluating the different options

I have published a new whitepaper that provides a comprehensive evaluation of the different mechanisms available in upgrading the Oracle E-Business Suite while considering platform migration. This document is meant as an overview to supplement existing detailed documentation that outlines specific processes to perform the migration:

This whitepaper discusses the use of Transportable Database, Recovery Manager (rman), Export/Import using Datapump, Transportable Tablespaces (TTS), Rapid Install, and Release Update Packs.

Application server vs. database server upgrades

Platform migrations may considered separately for the application and database tiers, or for both tiers together. In either case, it is critical to understand that the migrations are separate processes that can be thought of logically as such. This is especially crucial in light of potentially reducing downtimes by breaking them out into separate discrete events which may have different considerations for users and administrators.

Upgrade your database server before upgrading EBS

We recommend that you migrate your database to a new version and new server platform first.  This allows you to perform this in a separate earlier downtime.

For example, you might wish to migrate your EBS database tier running 11gR2 to Oracle Linux 5 on newer and faster hardware prior to an R12 upgrade. Performing this migration first would leave the your environment in a certified configuration that you can continue using until you wish to perform your EBS R12 upgrade.

Regardless of whether this migration is done in a separate earlier downtime or as part of a single downtime, the newer hardware would allow the EBS upgrade to go faster.

Best practices for combined upgrades

Here are our recommendations when performing EBS upgrades and platform migrations in a single project:

  1. Consider the database and application tier migrations separately and plan to perform the database migration first.

  2. Choose the right migration process for the database while considering the target platform, database size and process complexity.

  3. Migrate and upgrade your EBS application tier from 11i to R12 by laying down the new application tier on the target platform as part of the upgrade.

For more details, see:

Related Articles


Can Oracle please clarify if Oracle will be supporting Firefox 10.0 ESR? I know, Oracle Revenue Recognition rules prevents any dates being mentioned, but so far there's no news from Oracle about support for Firefox ESR.

Posted by guest on February 08, 2012 at 08:42 AM PST #

Hello, Guest,

We're in the final phase of our Firefox 10 ESR certification with the E-Business Suite.

Oracle's Revenue Recognition rules prohibit us from discussing certification and release dates, but you're welcome to monitor or subscribe to this blog for updates, which I'll post as soon as soon as they're available.


Posted by Steven Chan on February 08, 2012 at 09:03 AM PST #

Steve, John

I would be really interested to hear of best practices in migrating between 32bit and 64bit of Linux. We're running RedHat Apps Servers in 32bit for EBS11.5.10 but for R12 would like to take advantage of 64bit R12. I find the migration path a little cloudy.


Posted by Rob on February 08, 2012 at 11:31 AM PST #

Hello Rob -
The basic recommendation for migrating your DB first would also apply to this particular case. If your DB is not already on 64-bit Linux (in a split tier or DB tier only configuration), you should consider implementing this first following the 11i split tier docs (for example, MOS Note 946413.1 for 11i/11gR2). The migration of the DB from 32-bit to 64-bit is covered specifically in Step 5a (copying dbf files, etc.).
Once you're on (running on 32-bit Linux on the app tier) and the DB on 64-bit Linux, you're on a certified configuration from which you can then plan to do an upgrade to R12. Your DB will remain where it's at (and the DB schemas and objects upgraded to R12) as you perform the R12 upgrade. You would lay down the new R12 application tier on a new 64-bit Linux machine using our R12 64-bit Linux media hosting the Rapid Install.

Posted by John Abraham on February 08, 2012 at 01:48 PM PST #

Hello Steve & John,

I would like to ask a question.
My company is planning server migration for EBS suite environment(seperated apps and db tiers). I am very curios whether Oracle EBS release 11i supports multithreaded SPARC processors (e.g T4-2). More clearly, would EBS environment take a T4-2 server (2 CPUs, 8 cores each and each core 8 threaded) as it is running on a 64 core machine or not? Is it possible for us to take advantage of multithreaded processors?

Thank you,

Posted by Onur on January 06, 2013 at 06:42 AM PST #

Hello Onur -
We certify against the Operating System, not specifically the particular vendor system that hosts the OS. EBS will run on multi-threaded systems such as the T4, and we have noted certain caveats specifically for R12 (see the IUN MOS Note: 761568.1) under the Known Issues section, which may be applicable as well for you with 11i.

Posted by John Abraham on January 07, 2013 at 11:29 AM PST #

Hello John,
Trust you are doing well. Quick question on this topic:

Here is what we are trying to do:
Apps OS/bit-size: RHEL 5.5/32-bit
DB OS/bit-size: RHEL 5.5/64-bit

Apps: 12.1.3
Apps OS/bit-size: OEL 5.5/64-bit
DB OS/bit-size: OEL 5.5/64-bit

The process is pretty straight forward.
However, I am little confused about RHEL to OEL for the DB.

Is it a straight copy of DB files of from RHEL to OEL (the graphic in this blog post seems to say that)? Then upgrade on OEL to

Or do we have to follow steps given in:

I got to the above link from 1377213.1 -> 729309.1

As always, your work is much appreciated.

Posted by Anil on March 13, 2013 at 06:57 PM PDT #

hi Anil -
Yes, copying files over to the Oracle Linux system is one option as it is considered binary equivalent to RH - this is essentially a subset of the Option A in the Database Migrations section of the MOS Note 'Oracle E-Business Suite Upgrades and Platform Migration' [ID 1377213.1] where one would use Rapid Clone on the DB tier to do this. This would then be followed by an upgrade to 11gR2 as you point out.
The Transportable Database migration technique is for migrating across different platforms of the same endian format which is not the case here.
Also, you should be aware that any existing server can also be switched to Oracle Linux - please see:

Posted by John Abraham on March 14, 2013 at 10:35 AM PDT #

Hi John Abraham,

We have a question that need your guideline for migrating EBS from AIX 5L to ExaStack OEL 5.x

Apps OS/bit-size: AIX 5L / 64-bit
DB OS/bit-size: AIX 5L / 64-bit

Apps: 12.1.3
Apps OS/bit-size: ExaStack OEL 5.5/64-bit
DB OS/bit-size: ExaStack OEL 5.5/64-bit

Is there any technical references for migrating EBS from AIX 5L to ExaStack OEL 5.x both APPS-tier and DB-tier (Two Tier) ?

Thanks and Best Regards,

Posted by Ssgcle on October 29, 2013 at 10:08 PM PDT #

Hello Sigcle,
With regards to the Database, since you're on 9i, you'll have to first upgrade to 11g on AIX using the 11i/11g interoperability Note 1585577.1 ( for now, as is not yet certified for AIX). This DB upgrade is necessary first because the modern standard database migration tools (datapump export/import, transportable tablespaces) require that you be at least on 10gR2.
Once you've upgraded your DB, you can follow the recommendations in the above blog article to do your DB migration to Exadata, and also review the Exa papers on this subject:
The app tier upgrade to R12 and migration to Exa hardware is achieved in one step as noted in the 3rd item above in the 'Best practices for combined upgrades' section of the blog article.

Posted by John Abraham on October 31, 2013 at 11:04 AM PDT #

We are planning server migration as well as R12 upgrade, here are the details-

OS - Sun Solaris 5.10
Apps Tier - 5 node 11.5.10
Db tier - 1 node non-RAC, DB size 4 TB

OS - Sun Solaris 5.11
Apps Tier - 5 node R 12.2.5
Db tier - 1 node non-RAC

Can you please confirm if we can use Golden Gate 12c for migration as well as R12 upgrade with minimum downtime , if not what can be best tool for least downtime.

Best Regards
Saransh Soni

Posted by saransh soni on February 25, 2016 at 02:09 AM PST #

Hi Saransh -
As you're going to a later version of the OS on the *same* platform, this is technically not a platform migration the way we've defined it..
As noted in the MOS Note 1377213.1 (Option A under the 'Database Migrations and Upgrades' section), you would simply use Rapid Clone to move over your data files to the new OS with 11gR2 on the target, and then upgrade to 12cR1.
This database tier migration should be done first, and could be done in a separate shorter downtime before proceeding with the R12 upgrade at a later time - the R12 upgrade is where you'd use Rapid Install to lay down the new application tier on the target Solaris platform, prepare your DB for 12.2, upgrade EBS db schemas to R12, etc. (see Upgrade Guide and other documents as outlined in MOS Note 1583158.1).

Posted by guest on February 25, 2016 at 04:09 PM PST #

Thank John for quick response!!,Can you please also confirm if we can use Golden Gate 12c to reduce downtime as our DB size is 4 TB traditional methods(Transportable Tablspace, exp/imp, DB pump) will take lot of time. Our concern is if we can upgrade clone of Production on target machine while production is up & later on can apply delta changes on Target which happen on Production while upgrade. Thus downtime will be minimal.

Saransh Soni

Posted by Saransh Soni on February 25, 2016 at 08:50 PM PST #


Golden Gate cannot currently be used for platform migrations or upgrades for EBS databases. It does not support all of the datatypes used by the E-Business Suite.

As John noted, a platform migration is not required since you're going from Solaris to Solaris. You can follow the process John has described, above, to move your database to your new server.


Posted by Steven Chan on February 26, 2016 at 09:37 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed


« August 2016