SOA Suite on Docker, Part 2: Upgrading 12c to 14c, Composite by Composite

An in-place upgrade of SOA Suite is a sizeable, all-or-nothing exercise. You upgrade the binaries, run the schema upgrade against the existing repository with the Upgrade Assistant, reconfigure the domain, and then hope the whole estate comes back up cleanly on the new version. Everything moves at once, and if something misbehaves after cutover, your rollback story is a database restore and a lot of stress.

For a customer running production integrations, that is a hard sell. The risky part is rarely the WebLogic side; it is the composites. They have to be revalidated on 14.1.2 regardless, and in practice we found that a fair number of them needed small changes, either for 14c compatibility or to take advantage of new 14c capabilities such as the improved REST and multipart handling. Touching a composite means rebuilding and redeploying it, so a redeployment of the composites was going to happen as part of this upgrade no matter what. Once you accept that you are rebuilding and redeploying composite by composite anyway, doing it into a fresh, parallel 14.1.2 environment is the natural and far less risky way to go about it.

A second property of the workload made the cutover itself clean: the processes are short-running. There are no multi-day human workflows and no long-lived correlations sitting in the dehydration store waiting for a callback hours or days later. An instance starts, does its work, and finishes, usually within seconds.

That matters because it removes the hardest part of any cutover. With long-running instances, switching versions has to preserve in-flight state, which is where in-place upgrades earn their reputation. When everything is short-running you do not migrate instance state at all: you let the running instances on 12c drain to completion, and once they are done, that process has nothing left to carry over. The same logic is what let us validate calmly in the test environment, one process at a time, before doing the equivalent in production.

So instead of upgrading, we built a parallel 14.1.2 environment from scratch. The old 12c system ran the traditional way, installed directly on its existing hosts, with no containers involved. For 14c we provisioned fresh OCI compute with a current operating system and right-sized shapes, and built the containerized stack described in Part 1 on top of it. That gave us two independent systems running at the same time: the established 12c production environment, and a fully prepared 14.1.2 one sitting next to it with the composites already deployed and tested. From there it became a matter of retiring each process on 12c while bringing the matching process up on 14c.

With both environments live, the migration became a sequence of small, boring steps rather than one big event. For each composite we would:

1. Deploy and test it on 14.1.2 against the real downstream systems.

2. Let any in-flight 12c instances of that composite finish.

3. Move the inbound traffic for that composite over to 14.1.2.

4. Watch it for a while, then move on to the next one.

For composites that are called over HTTP, moving one is a rewiring at the load balancer or the OHS tier in front of the managed server, not a redeployment of everything. For the adapter-driven flows, an inbound email or a file drop for example, the switch is just as contained: you enable the adapter on 14.1.2 and disable it on 12c, so exactly one environment picks up each message and nothing gets processed twice.

Each step is independently verifiable, and nothing else on either system is touched while you do it. That turns a frightening one-shot upgrade into a controlled rollout you can pause at any point. If a composite needs more work on 14.1.2, it stays on 12c until it is ready, and the rest of the migration carries on without it.

The side-by-side model also gives you the rollback that an in-place upgrade cannot. For as long as you keep the 12c environment running, backing out a composite is simply a matter of sending its traffic to the old system again. No restore, no reinstall, no maintenance window. We kept 12c around until every composite had run cleanly on 14.1.2 in production for long enough that we trusted it, and only then decommissioned it.

None of this is exotic. It works because the workload is short-running and because containers make a second, disposable environment cheap to run. Those two things together let us replace a high-risk upgrade with a low-risk, reversible migration.

With the workload happily running on 14.1.2, the operational payoff begins. In Part 3 I will get into the part I am most pleased with: building a fully patched image and reacting to an Oracle CPU, or one of the new monthly security patches, in minutes rather than during a long maintenance window.

This is Part 2 of a four-part series on running and upgrading Oracle SOA Suite 14c in Docker.