Post-upgrade validation checklist for Oracle WebCenter Content 14c

Who this is for

You have just finished, or are about to finish, a WebCenter Content upgrade — most likely 12c to 14c ahead of the December 2026 end of Premier Support for Fusion Middleware 12c — and somebody has to decide whether it is safe to tell users to log back in. This is the checklist we run before we make that call.

Why a checklist and not a look around

There is a moment on every WebCenter Content upgrade that the platform documentation does not prepare you for. The servers are up. The console is green. The domain started without a stack trace. "It started" is not the same as "it works".

Two reasons for a written checklist.

First, WebCenter Content is a stack. Under the UCM and IBR servers sit an operating system, a JDK, a WebLogic domain, a database schema, an identity provider and — on any real installation — custom components someone wrote to make WCC do this organisation's specific job. An upgrade touches every layer; a green console proves one of them.

Second, the failures are quiet. A missing custom component does not crash the server; it makes a button disappear. A database restored at the wrong patch level or character set does not fail on startup; it corrupts multibyte content later. A security regression announces nothing. The checklist exists to go looking for the failures that will not come looking for you — because they surface three days later as a help-desk ticket, after the change window has closed and the rollback plan has gone stale.

We work six layers, bottom to top, each with a pass condition and a named sign-off.

Layer 1: platform — OS and JDK

Everything above inherits these settings, so start here.

• JDK version and vendor. WebCenter Content 14c is certified against specific JDK builds (Java 17 or 21 on the 14.1.2 release). Confirm the exact certified build is the one running the domain, not merely that a Java is installed somewhere. The wrong build produces intermittent behaviour rather than a clean refusal.
• Open-file and process limits. WCC opens many file handles. On Linux, check the soft and hard nofile and nproc values in /etc/security/limits.conf against what the install requires, and confirm the running processes actually inherited them. A limit set in the file but not picked up by the service account is the classic "fine in test, falls over under load".
• Service-account umask. Content files landing with the wrong permissions make replication and reindex jobs fail in ways that look like content problems.
• CPU, memory and mounts. Confirm the managed servers have the heap they were sized for, the vault and weblayout mounts are present and writable, and free space on the content filesystem is what you expect. An upgrade that moved hosts is where a mount most often goes quietly missing.

Layer 2: the database

A database problem masquerades as a content problem for weeks, which makes this the most consequential layer to get right.

• Patch level. Confirm the WCC schema database is at the exact version certified for 14.1.2, whether it was upgraded in place or restored. "The database is up" is not the check; "up at the version we certified against" is.
• Character set is AL32UTF8. Non-negotiable and easy to miss. A restore onto a non-Unicode character set corrupts accented names, non-Latin scripts and currency symbols on the way in.
• Schema users exist, are unlocked, and connect from WebLogic. Bounce the JDBC datasource from the WebLogic console, not only from a SQL client; they do not always use the same path or credentials.
• Sizing parameters. Spot-check processes, open_cursors, session_cached_cursors, db_files and shared_pool_size. A fresh instance or a restore can reset these to defaults, and WCC under real concurrency exhausts them.

Layer 3: content integrity

Now confirm the migrated content is all there and reachable.

• Walk the folder hierarchy, not just the document count. Counts match while an entire folder tree is missing or mis-parented. Confirm the major content sets are present and organised the way production was, in every environment you promoted through.
• Spot-check each major library. Real installations hold several distinct sets — a staff portal, a knowledge base, departmental libraries. Open a known document from each and confirm it renders. If one library migrated and another did not, this is where you catch it.
• Confirm downstream copies match. If QA is meant to be a copy of production, verify a sample actually matches rather than trusting the copy job finished.

Layer 4: custom components

This is the layer that separates people who have run WebCenter Content upgrades from people who have read about them. Every meaningful WCC installation carries custom components — server-side extensions that alter search results, provide custom home pages, hold configuration logic or hook integrations. They are the reason the system does its specific job, and they are exactly what a platform upgrade is most likely to leave behind.

• Enumerate what was enabled on the source and confirm each is enabled and initialising without error on the target. Component Manager shows what is registered; the log shows what failed to load. The component inventory tool produces the source-side list.
• Test function, not presence. A component can be enabled and still broken — pointing at a moved resource, depending on a config variable that did not migrate, or calling a service that changed. Exercise the feature each one provides.
• Search-result and result-count components first. In our experience these are the most fragile across releases because they hook internals that shift. Test both the empty-result and populated-result cases.

Layer 5: security and access

Identity integration is among the fiddliest things to reproduce, so an upgrade is a common place for security to regress.

• Identity integration round-trips. Confirm the SSO or OAM configuration and the LDAP or OVD credential maps in WebLogic, then log in as a real directory user — not the WebLogic admin account — and prove the login travels through the identity provider.
• Credential maps migrated. WCC stores mappings that let it talk to other systems. They do not always come across in a domain move, and their absence shows up as a broken integration rather than a login error.
• The negative case. Log in as an ordinary, non-privileged user and confirm they cannot reach the Administration menu. Prove the boundary holds; do not assume it.
• Ports and firewall rules. Validate the ports between UCM, IBR and the web tier are open on the new hosts. A re-IP'd or re-hosted environment frequently loses a rule the old one had.

Layer 6: functional smoke tests

Only now do end-user tests mean anything. Keep them simple and boring — they are the core content lifecycle, and if one fails the environment is not ready regardless of how good the layers below looked.

1. Check in a document. New content, through the real UI, as a real user. Confirm it lands, gets an ID and is retrievable.
2. Search. A query that should return known results; confirm the set and the counts. This re-exercises the search components from the outside.
3. Update. Open an existing item, revise it, and confirm the new revision is stored and the old one preserved. Check-in and search can pass while update quietly fails.

If all three work as a real user on a stack validated bottom to top, you can hand the environment back with a straight face.

Why this matters more on the 12c-to-14c move

A lot of WebCenter Content estates are about to run exactly this upgrade. WebCenter Content 14c (14.1.2) is the supported destination that keeps the platform current while content, folders, the metadata model and custom components carry forward. It is the low-surface-area move — but "the platform carries forward" is a promise about the platform, not about the six layers of your installation stacked on it. The upgrade guide validates the platform. This checklist validates your system. The upgrade mechanics themselves are in the out-of-place upgrade guide, and the clone-for-test approach is how we get a rehearsal environment to run this checklist against before the production window.

The custom components are where we keep a nervous eye. The runtime moves cleanly; the extensions written against it years ago are the part most likely to need attention, and the person who wrote them has usually moved on with the documentation.

How ECMWorks does this

When we run a WebCenter Content upgrade the validation pass is part of the delivery, not an option — each layer above has a pass condition written before the change window and a sign-off recorded after it. When you run the upgrade yourselves, we can take two smaller roles: a review of your validation plan against your actual component list before the window, or a read of the custom components you are no longer sure you fully understand, so that the load-bearing ones are known before rather than after the move.