Upgrading Oracle WebCenter Content 12c to 14c: the out-of-place upgrade runbook

Most of what's written about the WebCenter Content 12c→14c upgrade answers whether to do it. This post answers how — the actual sequence, the tools that do the work, and the handful of things that don't show up in the standard flow but decide whether your cutover weekend is quiet or long.

The short version: the 12.2.1.4 → 14c upgrade is a supported, well-trodden path. Your Content Server, your metadata model, your security model, and your stored documents all carry forward. It is a platform upgrade, not a re-implementation. But WebCenter Content has more moving parts than a plain WebLogic application — a file store that lives half in the database and half on disk, a search index that has to be reasoned about, custom components, and an OPSS security store that migrates on its own schedule. The Upgrade Assistant handles the schemas. It does not hand you the rest. That's the gap this runbook fills.

Everything below is drawn from real WebCenter Content upgrade projects — a US state government agency moving a benefits/records document repository across 12c, and a US federal legislative body running the same Fusion Middleware toolchain on a clustered estate. The version numbers in those projects were earlier (11.1.1.9 and 12.2.1.0 as source, 12.2.1.2 as target), but the tools, the sequence, and the failure modes are identical to what a 12.2.1.4 → 14c move throws at you. The shape of the problem doesn't change; only the release labels do.

Before you touch anything: the certification gate

The upgrade path lands cleanly from 12.2.1.4. If you're on an earlier 12c patch set, getting current on 12.2.1.4 is the staging step before the 14c move — do that first, on its own change window, so you're not debugging two upgrades at once.

Three things to confirm as certified before you schedule anything, because each one can quietly move your timeline. On a real WebCenter Content upgrade the compliance check is the very first pre-upgrade task, and it's where I've watched estates lose a week:

• Database — your repository database version has to be on the target certification matrix, and the character set matters. Confirm AL32UTF8 and that the database parameters are set correctly; WebCenter Content is a database-heavy product. On one of these projects the database itself had to move (an 11.2.0.3 → 11.2.0.4 step) as a prerequisite — that's a different, larger change and should almost never share a window with the middleware upgrade.
• JDK — 14c moves to a newer JDK baseline than 12c. Confirm the exact certified JDK and get it installed and pathed on every node before upgrade day. On these projects the JDK moved with the upgrade (e.g. a jump to a newer 1.8.0 build on the 12.2.1.x work), the new Java home was laid down first, and the .bash_profile was validated to point at it before anything else ran. The 14c baseline is higher again — confirm the exact certified build.
• Operating system — long-lived WebCenter estates are often on an OS release that's itself near end of life. Check the version, the open-file limits, the /tmp requirements, and the SHMMAX kernel parameter now, not during cutover. Confirm the installation user owns the Fusion Middleware home and that the hosts file lists servers by FQDN. These are boring lines on a checklist right up until one of them fails the prerequisite check on upgrade night.

Note: the certification matrix is where this gate quietly moves your timeline. The three constraints above aren't independent — the certified DB, JDK, and OS combination for your target 14c release is a specific intersection Oracle publishes, and a stack that's fine for 12c can miss it on one axis. The trap is confirming each in isolation, passing all three, and still landing on a combination that isn't jointly certified. Read the matrix for your exact target release and check the combination, not the pieces — this is estate-specific and it's the kind of thing a generic checklist can't resolve for you.

First size the repository — then choose in-place vs out-of-place

Here's where I'd push back on how this is usually written. The advice you'll read everywhere is "always go out-of-place." I lean out-of-place for production too — but the honest answer is that the approach is an output of the assessment, not an input to it. You don't recommend a path before you know what you're moving. Size the repository first.

What you measure, and why each one moves the decision:

• Document count and repository size — the number of items, the database size, and the vault + weblayout footprint on disk. This drives your downtime window and your reindex time, and on a very large vault it decides what's even feasible to duplicate.
• Downtime tolerance — can the repository go offline for a weekend, or does the business need near-continuous availability? A tight window pushes you toward a staged, side-by-side cutover.
• Rollback SLA — how fast must you be able to revert if the upgrade goes sideways? The tighter the requirement, the more out-of-place earns its keep.
• File store location — is content stored in the database or on the filesystem via FileStoreProvider, and how large is it? A multi-terabyte vault is not something you casually copy, which shapes what "side-by-side" actually means in practice.
• Topology — single node or a cluster, and how high availability is configured. This one is load-bearing: on a clustered estate the upgrade sequence grows a whole pack-and-unpack workstream (more on that below) that a single-node repository never sees.
• Customization and integration depth — the more custom components and integrations (EBS, a capture/scan feed, and the rest), the more you want a full testing window against the new Home before you commit.

Then the two patterns, and where each lands once you've sized it:

For most production Content repositories the assessment points to out-of-place — a fresh 14c Oracle Home, 12c binaries left intact, and a full window to validate before you commit the production schema. On the real projects behind this post, the first upgrade task was always the same: create a new Fusion Middleware home, install the new WebLogic and WebCenter Content binaries into it, and leave the old home alone. But that's the conclusion of the sizing exercise, not a substitute for it. A small, well-backed-up repository with room in the maintenance window is a perfectly reasonable in-place candidate.

One thing holds regardless of which you pick: the upgrade rewrites the schemas your documents depend on. Once the Upgrade Assistant has run the schema upgrade against production, "roll back" means "restore the database" unless you've kept 12c intact. That's the single strongest argument for out-of-place on any repository you can't afford to lose.

The sequence

This is the order of operations for an out-of-place WebCenter Content upgrade. It's the standard Fusion Middleware upgrade toolchain — the Repository Creation Utility (rcu), the Upgrade Assistant (ua), and the Reconfiguration Wizard (reconfig) do the heavy lifting — applied to Content's specific schema set. This is the exact spine I've run on real Content upgrades:

1. Create the new Oracle Home and install the 14c binaries on every node. Don't touch the 12c Home. Lay down the newer JDK first and validate the profile points at it.
2. Back up everything, and set the restore point. Full backup of the domain, the Oracle Home, the config, the file store (vault and weblayout — more on this below), and a database restore point on the repository schemas. This backup is the rollback plan. Treat taking it as part of the upgrade, not a formality before it.
3. Disable what shouldn't ride along. Before the schema work, disable obsolete or deprecated components in the source domain. On a real Content upgrade this was an explicit early task — a deprecated component left enabled can fail the reconfigure or the domain upgrade later, and it's far cheaper to turn it off now than to debug it at 2 a.m.
4. Run RCU to create the new-in-14c schemas. Some infrastructure schemas didn't exist in older releases and have to be created, not upgraded — the service table (_STB) and, depending on your source, the security store (_OPSS). On the real 12.2.1.x work this was a discrete step: run RCU, create _STB and _OPSS, then proceed. Skip it 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 tells you what the real pass will hit before you've committed anything. Run it, read it, and clear every warning you can before the real thing. This step is free insurance and people skip it.
6. Stop the 12c servers cleanly. Admin Server, all managed servers, and the node managers down, in order. Confirm nothing is holding the schemas.
7. Run the Upgrade Assistant — schema upgrade. This upgrades the WebCenter Content schema set: the Content Server schema (_OCS), and the shared infrastructure schemas every FMW domain carries — _MDS (metadata services), _OPSS, _IAU (audit), _STB, and the WebLogic schemas. If Imaging (_IPM) and Capture live in the same domain, they upgrade here too. ua reads the source, applies the schema deltas, and reports per-schema. Read that report — a "succeeded with warnings" is not the same as "succeeded." (On a healthy mid-size repository the Content/Portal schema pass ran in roughly 25 minutes in these projects — but that's a function of your data volume, not a promise.)
8. Run the Reconfiguration Wizard on the domain. reconfig points your existing domain at the 14c Oracle Home and reconfigures it. This is where the domain becomes a 14c domain. On a cluster, you reconfigure on the primary node.
9. Run the Upgrade Assistant again — config/domain 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 — this is how the upgraded, reconfigured domain propagates across the cluster. On the federal-estate project this pack/unpack of the managed domain was its own labeled workstream, and it's exactly the step a single-node runbook doesn't warn you exists.
11. Start the 14c domain and validate. Node manager, Admin Server, then managed servers. Then the checklist at the end of this post — because "the server started" is the beginning of validation, not the end of it.

That's the spine. Every step above is documented and supported. The next section is the part that isn't in the numbered list — the things that are technically your configuration, not the upgrade's, and that the Upgrade Assistant has no reason to warn you about.

The things the Upgrade Assistant won't warn you about

1. The file store: your documents are references, not rows

This is the one that surprises teams new to Content. WebCenter Content doesn't necessarily keep your documents in the database. With the FileStoreProvider, the database holds the metadata and a pointer, and the actual bytes live on disk in the vault (originals) and weblayout (web-viewable renditions) directories. The schema upgrade migrates the pointers. It does not move, validate, or reconnect the files those pointers reference.

So if the file store paths aren't identical on the 14c side — a different mount, a changed path, a permissions difference on the service account — the metadata upgrades perfectly and every document 404s. On these projects the content lived on a network share, and the storage-and-access validation was an explicit checklist item: confirm the mounts resolve (cat /proc/mounts, df), confirm the service account can read and write them, before starting servers. One real gotcha from a Content estate that moved its storage layer during an upgrade: the share technology changed underneath (an NFS-to-CIFS migration), which meant file locking and user-permission semantics changed too — the pointers were fine, the permissions model on the underlying share was not. Verify the paths resolve and the account can read them before a user reports a missing document, not after.

2. Search: the index has to be reasoned about, not assumed

WebCenter Content search in 12c is commonly OracleTextSearch — full-text indexing backed by Oracle Text in the repository database. The upgrade carries your search configuration forward. Whether the index comes across usable, or needs a rebuild, depends on your search engine and how the collection is defined. (Older estates may be on a Lucene-based index instead — on one pre-upgrade checklist, copying the Lucene configuration and disabling the indexes ahead of the move was an explicit step, precisely because that index doesn't survive untouched.)

On a large repository, a full collection rebuild is not a five-minute operation — it's a planned window sized to your document count, and search results are incomplete until it finishes. The mistake is discovering this on Monday when users report that search "isn't finding anything." Decide up front: does your configuration need a rebuild, and if so, is that rebuild inside your cutover window or a fast-follow with a communicated "search is reindexing" banner? Whether the index survives the move usable at all, or has to be rebuilt from scratch, hinges on your search engine and how the collection was defined — which is a per-estate fact, not a general answer, and it's the difference between a rebuild that fits your window and one that doesn't.

3. Custom components don't come along for free

Anything under /custom — the components you added through the Component Wizard, the ones a previous integrator wrote, the ones nobody documented — is your code, and the upgrade treats it as such. Components have to be reviewed for target-release compatibility, re-enabled, and in some cases recompiled or reworked. A component that quietly stops loading can take a workflow, a UI customization, or a security behavior down with it, and the domain will start up looking healthy.

This is not hypothetical. On the government-agency upgrade, custom-component compatibility was budgeted as its own day of effort, and the production validation script named every single one that had to be re-verified after the move — a set of custom browse-results, home-page, and configuration components, plus a "zero results" handler and an access-control component. One of those load-bearing components did something security-relevant: it enforced that a regular, non-privileged user could not reach the Content Server administration menu. If that component silently fails to load after the upgrade, the domain comes up "green" and every ordinary user can suddenly see admin functions. That's the class of thing "the server started" hides. The step people skip: inventory the custom components before the upgrade — list every enabled component, know what each one does, and know which are load-bearing — because the undocumented ones are exactly where WebCenter's reverse-engineering problem lives, and where an upgrade run by someone who can read the component, not just toggle it, earns its keep.

4. The security store migrates on its own order

WebCenter Content's authorization runs through OPSS — the policy store, the credential store (the cwallet), and jps-config. These migrate as part of the upgrade, but they have their own sequencing and their own failure modes, and they're independent of where your users live (embedded LDAP, OID, OUD, OAM, or an external directory). Get the order wrong and you get a domain that starts but can't authorize — every request lands, nobody's allowed in.

Two concrete traps from the real projects. First, credential maps have to be migrated deliberately — on the government-agency estate, migrating the WebCenter Content OVD credential maps into the new environment was a named task and a named validation check, because a credential store that doesn't come across leaves the domain up but unable to bind to the services it depends on. Second, if your identity or access layer is external (OAM in front of WebLogic, an LDAP/OVD directory behind it), confirm explicitly whether it's moving — it often isn't, but "we assumed it stayed put" is how you find out at login. Back up and verify the cwallet as its own artifact; a lost or unmigrated credential store is a bad afternoon.

5. Managed Attachments / capture: the EBS and scan integrations are their own workstream

If this Content repository is the document store behind Oracle E-Business Suite — Managed Attachments, or an AXF-driven imaging flow — or the back end for a capture/scan pipeline (a capture/scanning front end such as Kofax), then the integration is a first-class part of the upgrade, not an afterthought. On these projects the scan-to-Content integration test was an explicit line item, separate from the Content Server smoke test, precisely because the middleware coming up cleanly tells you nothing about whether an inbound document still lands where it should. The adapter, the integration configuration, and the Content-side solution all have to line up after the upgrade, and this is exactly the kind of integration that "started fine" hides until a real document tries to flow through it.

If you run either pattern, add an end-to-end test to your smoke run: from EBS, attach and retrieve a document; from the scan station, capture one and confirm it commits into the repository. Don't assume the middleware coming up means the integration came up with it.

6. Config deltas and pre-upgrade data cleanup: what's environment-specific doesn't carry itself

config.cfg, intradoc.cfg, and the environment-specific settings you've accumulated over years — connection pools, custom metadata fields, environment URLs, tuning, JDBC test-query settings — are exactly the settings that are easy to assume "just come across." Most do. On the real upgrades, app-specific configuration files were explicitly backed up before the reconfigure and restored after it, because the Reconfiguration Wizard resets things it has no way of knowing you customized. Two categories bite: environment-specific values that shouldn't be copied verbatim (a prod URL or hostname that followed you from a test upgrade), and tuning that mattered and got lost. Diff the pre- and post-upgrade config deliberately.

There's also a pre-upgrade data cleanup that catches people out: some source rows will fail the schema upgrade if left in place. On the federal estate, specific rows had to be deleted from the source schema before running the schema upgrade — a MIME-type row and a handful of orphaned reference records — or the upgrade would stop on them. Run the Upgrade Assistant in readiness mode (step 5) specifically to surface this class of problem while it's still a five-minute DELETE and not a failed production run.

The rollback checkpoint, stated plainly

Because the schema upgrade is the point of no easy return, the whole rollback plan hinges on one thing: a verified database restore point taken immediately before the schema pass, plus the untouched 12c Oracle Home from the out-of-place approach. If the schema upgrade goes wrong, rollback is: stop 14c, restore the schemas to the restore point, restart 12c from its original Home. That only works if the restore point is real and tested. "We have backups" is not a rollback plan; "we restored this backup into a scratch environment last week and it came up" is. On these projects a fresh backup of the upgraded environment was also taken the moment validation passed — so you're never more than one restore away from a known-good state in either direction.

Cutover smoke test: what "it works" actually means

Server-started is not upgrade-complete. This checklist is lifted almost directly from the production validation script on a real Content upgrade — before you hand it back to users, walk it:

• Check in a new document. Confirm it lands in the vault and gets a weblayout rendition. (This was a named validation step: "validate that you can perform a WCC check-in.")
• Update an existing document and confirm the revision behaves. (Also a named step — check-in and content-update were validated separately.)
• Retrieve an old document — one from before the upgrade — and confirm the bytes come back, not just the metadata. This is the file-store test.
• Run a search that you know should return known results, and confirm the index is answering (or that your reindex banner is up if it's a fast-follow).
• Confirm the migrated content is actually there — on a folders-based repository, verify the expected folder trees and their content survived the move (the real script checked named content sets folder-by-folder).
• Log in as a real, non-privileged user role, not just the admin, and confirm authorization works — and confirm that user cannot reach the administration menu. This is the OPSS-plus-custom-component test, and it's the one that catches a silently-unloaded security component.
• Exercise every custom component that matters by name, especially UI, workflow, and access-control ones.
• If EBS- or capture-integrated, attach and retrieve from EBS and run a scan end-to-end.
• Confirm the required ports are open to communicate with Content Server through the firewall, and check the audit and the logs for the quiet warnings — the things that didn't fail loudly but will tomorrow.

Clear all of these and you've validated the parts that actually break. Skip them and you've validated that WebLogic can start.

Where this sits in the wider stack

WebCenter Content rarely upgrades alone. It rides on WebLogic, it usually shares a domain or a lifecycle with Imaging, Capture, and sometimes Portal and Sites, and the same December 2026 Premier Support date governs the neighbors. On the real projects behind this post, Content, Portal, and Sites were upgraded as a coordinated sequence on the same estate — which is exactly why the pack/unpack, the shared certificate imports, and the per-component readiness checks all landed in one plan rather than three. The WebCenter 14c upgrade page covers the product-family view, WebLogic 14c covers the foundation every component runs on, and the Fusion Middleware 12c end-of-support guide lays out the dates for the whole estate so you can sequence the components rather than upgrade them one panicked weekend at a time.

If your repository is heavily customized, undocumented, or the people who built it have moved on, that's the situation we're built for — reading a WebCenter estate directly, knowing which of its custom components are load-bearing, and carrying it to 14c without depending on documentation that may not exist. If that's where you are, a scoping conversation is the right first step.

This is a field runbook grounded in real WebCenter Content upgrade projects, not a substitute for the Oracle upgrade documentation for your specific component versions and topology. Confirm the certified database, JDK, and OS combination for your target release before you plan the window, and always validate against a non-production copy first.