WebCenter Content 12c to 14c: the out-of-place upgrade, step by step

Who this is for

You are the administrator or engineer who will actually run the WebCenter Content 12c to 14c upgrade, and you want the order of operations, the tools, and the things outside the standard flow that decide whether the cutover weekend is short or long. The product-family decision is in the WebCenter 14c upgrade guide; this is the runbook.

Everything below is drawn from Content Server upgrades we have run on estates of real size: a state government agency's benefits and records repository, and a federal legislative body's clustered estate on the same toolchain. The release labels were earlier; the tools, the sequence and the failure modes are the ones a 12.2.1.4 to 14c move produces today.

Step 0: clear the certification gate

The path lands cleanly from 12.2.1.4. On an earlier 12c patch set, get current first, in its own window.

Then confirm three things are certified for your target 14c release before you schedule anything, because each can quietly move the timeline:

• Database. The repository database must be on the 14c certification matrix. Confirm the character set is AL32UTF8 and the database parameters are set as the product requires; Content Server is a database-heavy application. If the database itself has to move versions, that is a separate, larger change and should almost never share a window with the middleware upgrade.
• JDK. 14c moves to a newer JDK baseline than 12c. Install the exact certified build on every node, lay down the new Java home, and validate the shell profile points at it before anything else runs.
• Operating system. Long-lived estates often sit on an OS release that is itself near the end of its certification. Check the OS version, the open-file limits, the /tmp requirements, the SHMMAX kernel parameter, that the installation user owns the Fusion Middleware home, and that the hosts file lists servers by FQDN.

Step 1: size the repository, then choose in-place or out-of-place

The usual advice is "always go out-of-place". We lean that way for production too, but the approach is an output of the assessment, not an input. Measure first:

• Document count and repository size: item count, database size, and the vault plus weblayout footprint. This sets the downtime window and the reindex time.
• Downtime tolerance: a weekend offline, or near-continuous availability? A tight window pushes toward a staged, side-by-side cutover.
• Rollback service level: how fast must you be able to revert? The tighter it is, the more out-of-place earns its keep.
• File store location and size: database or filesystem via FileStoreProvider, and how many terabytes. A multi-terabyte vault is not casually copied.
• Topology: single node or cluster. A cluster adds a pack-and-unpack workstream a single node never sees.
• Customization and integration depth: the more custom components and integrations, the more you want a full test window against the new Home.

Whichever you pick, one thing holds: the upgrade rewrites the schemas your documents depend on. Once the Upgrade Assistant has run against production, "roll back" means "restore the database" unless 12c is still intact. That is the strongest argument for out-of-place on any repository you cannot afford to lose. For a rehearsal, clone the instance for a test upgrade.

Step 2: the sequence

This is the spine of an out-of-place Content Server upgrade. The standard Fusion Middleware toolchain does the heavy lifting: the Repository Creation Utility (rcu), the Upgrade Assistant (ua) and the Reconfiguration Wizard (reconfig).

1. Create the new Oracle Home and install the 14c binaries on every node. Leave the 12c Home alone. Lay down the certified JDK first.
2. Back up everything and set the restore point. Full backup of the domain, the Oracle Home, the configuration, and the file store (vault and weblayout), plus a database restore point on the repository schemas. This backup is the rollback plan; treat taking it as part of the upgrade.
3. Disable what should not ride along. Turn off obsolete or deprecated components in the source domain before the schema work. A deprecated component left enabled can fail the reconfigure or the domain upgrade later, and it is far cheaper to disable it now.
4. Run RCU to create the schemas that are new in the target release. Infrastructure schemas that did not exist in the source have to be created, not upgraded: the service table (_STB) and, depending on the source, the security store (_OPSS). Skip this and the Upgrade Assistant has nothing to upgrade those references into.
5. Run the Upgrade Assistant in readiness mode. ua -readiness, domain-based, checking both schema and configuration, is a dry run that reports what the real pass will hit before anything is committed. Clear every warning you can; this is the step people skip.
6. Stop the 12c servers cleanly. Admin Server, managed servers, node managers, in order.
7. Run the Upgrade Assistant: schema upgrade. This upgrades the Content Server schema (_OCS) and the shared infrastructure schemas every FMW domain carries: _MDS, _OPSS, _IAU, _STB and the WebLogic schemas. If Imaging (_IPM) and Capture share the domain, they upgrade here too. Read the per-schema report: "succeeded with warnings" is not "succeeded".
8. Run the Reconfiguration Wizard on the domain. reconfig points the existing domain at the 14c Oracle Home. This is where it becomes a 14c domain. On a cluster, reconfigure on the primary node.
9. Run the Upgrade Assistant again: domain and configuration upgrade. The second ua pass upgrades the domain and component configuration to the target release. Schema first, reconfigure, then domain; that order is not optional.
10. On a cluster, pack and unpack to the other nodes. After the primary node is upgraded and reconfigured, pack the domain into a template and unpack it onto every secondary node. On the clustered legislative estate this was its own labelled workstream, and it is exactly the step a single-node runbook does not tell you exists.
11. Start the 14c domain and validate. Node manager, Admin Server, then managed servers. Then the smoke run in Step 4, because "the server started" is the beginning of validation.

Step 3: the things the Upgrade Assistant will not warn you about

Every step above is documented and supported. This section is the part that is technically your configuration, not the upgrade's, and that the tooling has no reason to flag.

The file store: documents are references, not rows

With the FileStoreProvider, the database holds metadata and a pointer; the bytes live on disk in the vault (originals) and weblayout (web renditions) directories. The schema upgrade migrates the pointers. It does not move, validate or reconnect the files.

If the paths are not identical on the 14c side, whether a different mount, a changed path or a permissions difference on the service account, the metadata upgrades perfectly and every document fails to retrieve. On the estates behind this runbook the content lived on a network share, and storage validation was an explicit checklist line: confirm the mounts resolve (cat /proc/mounts, df) and the service account can read and write them before starting servers. One real gotcha: a share technology change underneath an upgrade (NFS to CIFS) changed file-locking and permission semantics, so the pointers were fine and the permissions model was not.

Search: reason about the index, do not assume it

Content Server search on 12c is commonly OracleTextSearch, backed by Oracle Text in the repository database. The upgrade carries the search configuration forward. Whether the index comes across usable, or needs a rebuild, depends on the engine and how the collection is defined; older estates on a Lucene-based index should expect to copy the index configuration and disable the indexes ahead of the move.

On a large repository a full rebuild is a planned window sized to the document count, and search is incomplete until it finishes. Decide up front whether it fits inside the cutover window or runs as a fast-follow with a "search is reindexing" notice.

Custom components do not come along for free

Everything under /custom (components added through the Component Wizard, ones a previous integrator wrote, ones nobody documented) is your code, and the upgrade treats it that way. Each has to be reviewed for target-release compatibility, re-enabled, and sometimes recompiled or reworked. A component that quietly stops loading can take a workflow, a UI customization or a security behaviour down with it while the domain reports healthy.

On the state agency upgrade, component compatibility was budgeted as its own day, and the validation script named every component to re-verify: custom browse-results, home-page and configuration components, a zero-results handler, and an access-control component that stopped ordinary users reaching the administration menu. If that one fails to load, the domain comes up green and every user can see admin functions. Inventory the components before the upgrade: the component inventory tool lists what is enabled; knowing what each one does and which are load-bearing is the work.

The security store migrates on its own order

Authorization runs through OPSS: the policy store, the credential store (the cwallet) and jps-config. These migrate with their own sequencing and failure modes, independent of where your users live (embedded LDAP, OID, OUD, OAM or an external directory). Get the order wrong and the domain starts but cannot authorize anyone.

Two concrete traps. Credential maps must be migrated deliberately: on the state agency estate, carrying the virtual-directory credential maps into the new environment was a named task and a named validation check. And if the identity layer is external (OAM in front, an LDAP or OVD directory behind), confirm explicitly whether it is moving. Back up and verify the cwallet as its own artefact.

Managed Attachments and capture are their own workstream

If this repository is the document store behind E-Business Suite (Managed Attachments or an AXF-driven imaging flow) or the back end of a scan or capture pipeline, the integration is a first-class part of the upgrade. On these projects the scan-to-Content test was a separate line item from the Content Server smoke test, because the middleware coming up cleanly says nothing about whether an inbound document still lands where it should. Add an end-to-end test: attach and retrieve from EBS; capture a document at the scan station and confirm it commits.

Configuration deltas and pre-upgrade data cleanup

config.cfg, intradoc.cfg and years of environment-specific settings mostly carry across. Back up the application-specific configuration files before the reconfigure and restore them after, because the Reconfiguration Wizard resets things it cannot know you customized, then diff pre- and post-upgrade configuration deliberately.

There is also a source-data cleanup. Some rows fail the schema upgrade if left in place: on the legislative estate a MIME-type row and a handful of orphaned reference records had to be deleted first. Readiness mode (step 5) surfaces this while it is still a five-minute DELETE.

Step 4: the cutover smoke test

Server-started is not upgrade-complete. Before handing the repository back to users, walk this list, lifted almost directly from a production validation script:

• Check in a new document and confirm it lands in the vault with a weblayout rendition.
• Update an existing document and confirm the revision behaves.
• Retrieve a pre-upgrade document and confirm the bytes come back, not just the metadata. This is the file-store test.
• Run a search with known expected results and confirm the index answers, or that the reindex notice is up.
• Verify the migrated content is present, folder tree by folder tree on a folders-based repository.
• Log in as a non-privileged user, confirm authorization works, and confirm that user cannot reach the administration menu. This is the OPSS-plus-component test.
• Exercise every load-bearing custom component by name.
• If EBS- or capture-integrated, attach and retrieve from EBS and run a scan end to end.
• Confirm the required ports are open through the firewall, and read the audit trail and logs for the quiet warnings.

Then take a fresh backup of the upgraded environment the moment validation passes, so you are never more than one restore from a known-good state. The full post-upgrade validation checklist extends this list.

Where this sits in the wider stack

Content Server rarely upgrades alone. It rides on WebLogic 14c, usually shares a domain or a lifecycle with Imaging and Capture, and the same December 2026 date governs the neighbours. On the estates behind this runbook, Content, Portal and Sites were upgraded as one coordinated sequence, so the pack and unpack, the certificate imports and the per-component readiness checks landed in one plan. The Fusion Middleware 12c end-of-support guide lays out the dates for the whole estate.

How ECMWorks does this

We run the Content Server upgrade in three parts: a readiness read of the running 12c estate (certification gate, repository sizing, component inventory, integration map, readiness-mode findings), a rehearsal on a cloned instance where the full sequence is executed and timed, and the production cutover run with your administrators on the console so the estate is theirs on Monday. EBS and capture integrations are separate test lines in the plan. Our engineers read custom components rather than toggling them, which is what makes an undocumented estate upgradable.