This document discusses the differences between an in-place upgrade and a side-by-side upgrade when migrating from Oracle SOA 11g to 12c. An in-place upgrade installs 12c in a new Oracle home but upgrades the domain and database in the current location. A side-by-side installs 12c in a new home and creates a new domain and database. The document outlines advantages of in-place such as no new configuration required and long-running instances continue seamlessly, but also disadvantages like potential downtime and limitations on the starting 11g version. It recommends considering a side-by-side approach if needing to take advantage of new 12c features or to avoid risks of issues during an

1. Oracle SOA 12c
In-place & Side by Side upgrade-Overview
Kranti Kumar Guduru

2. Agenda
• Types of Upgrades available with SOA12c
• Advantages of in-place upgrade over side by side (11g to 12c)
• Disadvantages of in-place upgrade over side by side upgrade (11G to
12c)
• Important note

3. Types of Upgrades available with SOA12c
• Inplace Upgrade : In-place upgrade, we install SOA 12c in a new oracle
home and upgrade the domain and DB in-place
• Side by side upgrade : In side by side upgrade, we install SOA 12c in a new
oracle home and create a new SOA 12c domain and DB. Then deploy all
the composites and configure the 12c domain fully. Next step is, cut over
from 11g to 12c

4. Disadvantages of in-place upgrade over
side by side upgrade (11G to 12c)
• There are limitations and prerequisites as per oracle for in-place upgrade. For
example the starting version must be 11.1.1.6 or 11.1.1.7. If you are not meeting
these requirements, you have to fix it (for example upgrade to 11.1.1.7 first) before
you start the 12c upgrade or not do the in-place upgrade since it is not supported
with your current. For side by side, you can create the 12c domain and migrate
your composites without this problem. If you are migrating from a version before
11.1.1.6, first migrate your jdeveloper projects to 11.1.1.7 then migrate the
jdeveloper projects to 12c

5. Disadvantages of in-place upgrade over
side by side upgrade (11G to 12c)
• The down time during upgrade could be quite long. Please shut down 11g system,
take a complete backup, perform the upgrade, and then test and tune your
upgraded domain, before making it live. Cutting over to 12c for side by side could
be fast with minimum down time since everything in 12c has been tested and
tuned while the 11g system was live
• Dealing with BAM - BAM does not support in-place upgrade and you have a
much more complex in-place upgrade path. In side by side, creating a new 12c
domain with SOA and BAM is straight forward

6. Disadvantages of in-place upgrade over
side by side upgrade (11G to 12c)
• Even though Oracle tested in-place upgrade thoroughly to provide smooth experience, However
there is a possibility that your particular special deployment encounters issues. This may cause
delays in your testing of in-place upgrade. Issues are much less likely if you create a new domain as
in side by side
• The focus of in-place upgrade is backwards compatibility and a silent automatic upgrade.
Sometimes this means new 12c features may be disabled after upgrade and you may have to enable
these gradually some time after going live on 12c. For example the key store technology has
changed from JKS to KSS. However after upgrade you are still left with JKS since it is not possible
to auto migrate to KSS. Another example is the XML XDK is configured for backwards
compatibility after upgrade disabling new features. This is not a problem with side by side. With
side by side, you have plenty of time to modify your composites if you want to, to take advantage
of new features

7. Disadvantages of in-place upgrade over
side by side upgrade (11G to 12c)
• Rolling back the upgrade if you encounter problems during or after upgrade
requires you to restore from full backup. With side by side, you would have had
plenty of time to thoroughly test so it is very unlikely you have to go back to 11g

8. Advantages of in-place upgrade over side by side (11G to 12c)
• We do not have to take the effort of configuring a new enterprise deployment which
could take a long time
• We do not have to replicate the SOA configuration after the upgrade
• We do not have to configure our custom adapters, adapter configurations, JMS
queues/topics, datasources, non SOA J2EE Apps, etc. All the configurations and
deployments carries over. In side by side, all this configurations have to be done from
scratch. It is basically a new deployment plan
• Long running instances continue after upgrade where they left off. As mentioned in side
by side, long running instances do not move over to the new deployment

9. Advantages of in-place upgrade over side by side (11G to 12c)
• We can retain the history of completed instances after upgrade. In side by side, the history
of completed instances do not over to the new deployment
• we don't need new licenses. we should check with Oracle if new licenses are needed if we
don't put the 12c domain on the same CPUs as the 11g domain in a side by side upgrade.
if your 11g production system does not have a lot of spare capacity to collocate the 12c
deployment, you will probably have to buy new hardware for the 12c deployment
• All inbound addresses are the same so clients don't need to be modified. This includes
JMS queues/topics, file directories, etc. For side by side, inbound HTTP traffic can be
redirected without impacting clients by switching at the load balancer, but others may
require changes to the clients

10. Important note
• Side by Side upgrade does not apply if you have long running instances and you
cannot guarantee that all inbound messages have been drained and there are no
active instances when you cut over to 12c. Even if this is not true, you could still
keep the 11g system up (with no new messages) until all messages are drained and
all active instances complete. We will briefly cover this option at the end but ignore
it for the rest of the article
• If you continue running the 11g system after the 12c system goes live then things
like Human Workflow approvals and EM management have to be done in two
places, and clients sending messages to a running process may not work