Best Practices for SOA Suite 11g to 12c Upgrade

A lot of effort has been put in by Oracle to make this major
upgrade as smooth and easy as possible. The basic approach is to install SOA
Suite 12c in a new oracle home and upgrade the domain and schemas in place.
Customers undertaking the upgrade are primarily interested in a smooth upgrade,
minimizing the number of manual steps in the upgrade, reduce the down time to a
minimum, and minimize or eliminate any changes to client apps that use SOA APIs
or web interfaces.

The key to a successful and smooth upgrade experience are
the preupgrade preparations that you perform. The upgrade must be planned
carefully. If the preupgrade preparations are not performed, there is a
possibility that upgrade will fail in the middle or the system does not behave
properly post upgrade. The only recourse to a failed production system upgrade
is to roll it back from a full backup.

If your SOA domain includes BAM, then the upgrade is more
complex because BAM does not support inplace upgrade. Please read the
documentation carefully. The basic idea is to migrate the whole BAM
deployment to a seperate domain using export/import, remove BAM from the soa
domain during upgrade, and upgrade your soa domain to interop with the bam 11g
domain. Later slowly and carefully migrate to BAM 12c from BAM 11g.

There are six top steps that should be performed before
upgrade of your production system as a best practice.

• Carefully
  review the prerequisites for upgrade in the documentation. Some of the
  prerequisites are checked upfront before we upgrade the schema in Upgrade
  Assistant but not all. Read all relevant upgrade documentation before
  starting on upgrade. Some of the key prerequisites are:

• Can only upgrade a
  domain that is 11.1.1.6 or 11.1.1.7. Migrate to a supported starting point
  before upgrade.

• Can only
  upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.

• Can only
  upgrade a production domain not using XE DB and is not an admin server only domain.

• Can only upgrade a domain using LDAP or DB OPSS policy store. Migrate file based policy store to DB or LDAP
  based policy store before upgrade.

• Can only upgrade a domain using a oracle DB of a version supported by the SOA Suite 12c certification matrix. Migrate to a
  supported DB version before upgrade.

• Can only upgrade a domain based on weblogic server.

• Can
  only upgrade a domain at this time with products deployed that were released in
  12c. Example of products not released are OER, OSR, Webcenter, and SOA task UI exposed as portlets (which
  uses webcenter libraries).

• Cannot
  upgrade a domain at this time created with T2P or pack/unpack before SOA Suite
  11.1.1.6.

• Cannot
  upgrade a domain at this time with multiple products in 12c in separate
  unclustered managed servers using UMS. Examples are BAM, OSB and SOA. The
  reason is because after upgrade UMS configuration is at the domain level or the
  cluster level, but not at a unclustered managed server level.

• Only JDK 7 is supported. 

• Always test upgrade first before actually upgrading your
  production system. Test with a clone of your production system either created
  with T2P or test with a existing test environment which mirrors your production
  environment. T2P does not clone the transactional store. It only creates an
  environment that is identical in configuration to the source. If you create an environment by doing T2P of
  production, you will first need to populate
  that environment with sufficiently representative transactions. Documentation
  for T2P can be found here:

Oracle Fusion Middleware Administrator's Guide 11g
Release 1 (11.1.1)
Chapter 21 Moving from a Test to a Production Environment

• Use
  the upgraded test environment to test all the composites without redeploying,
  and to determine the performance tuning to be done to your production system
  post upgrade. Tuning in SOA Suite 12c is different than 11g. For example work
  managers are used extensively for threads in SOA Suite 12c.

• Always
  backup everything before upgrading your production system and test restoring
  from the backup in your test system. If the upgrade fails in the middle, you
  might have to restore the backup.

• Before
  upgrade of your production system, purge as many instances as possible that are
  not essential to keep to make the upgrade faster. Upgrade will upgrade all the
  open instances when running the Upgrade assistant and closed instances are
  upgraded lazily post schema upgrade in the
  background. This can take significant time and disk space. There is currently
  no estimation tool for amount of disk space or time, so be conservative so
  upgrade does not run out of disk space.

• Upgrade
  all your SOA projects in JDeveloper and test them on your upgraded test system.
  This is so there is no surprises later when you need to change the project to
  add a new feature or fix a bug. Currently though there is no tool to bulk
  upgrade a lot of JDeveloper projects in a script. We are exploring
  such a tool. However compile and deployment can be scripted.

Upgrade documentation and videos can be found at the
following URLs.

Docs Link

Videos Link