Cloning Oracle WebCenter Content for a safe test upgrade

Who this is for

The engineer who will run the WebCenter Content (WCC/UCM) 12c-to-14c upgrade and wants to see it break somewhere safe first. Fusion Middleware 12c Premier Support ends in December 2026; the first thing to do before touching production is rehearse the whole upgrade on a true copy of the instance.

Why a true copy and not a sample

WebCenter Content is three things bolted together: a content repository on the filesystem (the vault and weblayout directories), a metadata schema in the database (revisions, documents, docmeta and dozens of supporting tables), and the application that indexes and serves them. A test upgrade is only worth trusting if all three come along. A fresh install with a handful of test documents rehearses against a fiction. A clone that carries your real content, your real hundred custom metadata columns, your real folder tree and your in-flight workflow throws your errors on your data while production sits untouched.

The approach below moves content-bearing data from a cloned copy of production into a freshly provisioned target-version schema, over a database link, table by table. Working table by table rather than as a blind full-schema import is deliberate: it lets you filter out system content, reconcile schema differences between source and target releases, and understand what you are carrying.

Step 1 — Link the target schema to the cloned production database

Everything downstream runs over a database link from the target (new-release) schema to the cloned-production schema.

CREATE DATABASE LINK DBLINK_WCC_PROD_CLONED
  CONNECT TO STG_OCS IDENTIFIED BY ********
  USING '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<cloned-db-host>)(PORT=1521))
          (CONNECT_DATA=(SERVICE_NAME=<cloned-service>)))';

Point the link at a clone of production, never at production itself. A long-running insert ... select pulling millions of rows across a link into the live system defeats the purpose of the exercise.

Step 2 — Copy the content tables, filtering system content

The core content lives in a small set of related tables. Copy them in dependency order and filter out the System document type: you want the customer's content, not the internal machinery the fresh target already has its own copy of.

-- Revisions: every content item version
insert into TARGET_OCS.revisions
  select * from revisions@DBLINK_WCC_PROD_CLONED
  where ddoctype <> 'System';

-- Revclasses: revision-class rows for those items
insert into TARGET_OCS.revclasses
  select * from revclasses@DBLINK_WCC_PROD_CLONED
  where ddocname in (
    select ddocname from revisions@DBLINK_WCC_PROD_CLONED
    where ddoctype <> 'System');

-- Documents: the file-level rows tied to those revisions
insert into TARGET_OCS.documents
  select * from documents@DBLINK_WCC_PROD_CLONED
  where did in (
    select did from revisions@DBLINK_WCC_PROD_CLONED
    where ddoctype <> 'System');

Then documenthistory, filtered the same way on did. Count on both sides first and reconcile: history rows can reference IDs outside your filtered revision set, and it is better to decide consciously whether to carry them than to discover the mismatch later.

select count(*) from documenthistory@DBLINK_WCC_PROD_CLONED
  where did in (select did from revisions@DBLINK_WCC_PROD_CLONED
                where ddoctype <> 'System');

Step 3 — Reconcile docmeta

docmeta holds every custom metadata field on your content. In a real estate that is not five columns; it is a hundred-plus x-prefixed fields. Two things bite here, and both are why a naive copy fails.

Column-width drift. Between releases, metadata columns that were narrower on the source can need to be 4000 characters on the target — and if the target column is shorter, the insert throws on the first over-length value. List the wide columns on the source, widen their counterparts on the target before copying, then re-run the query against the target and confirm the counts match.

SELECT column_name, data_type, char_length
  FROM USER_TAB_COLUMNS@DBLINK_WCC_PROD_CLONED
  WHERE table_name = 'DOCMETA' and char_length = 4000;

ALTER TABLE TARGET_OCS.docmeta MODIFY xComments        VARCHAR2(4000);
ALTER TABLE TARGET_OCS.docmeta MODIFY xKeywords        VARCHAR2(4000);
ALTER TABLE TARGET_OCS.docmeta MODIFY xProductCategory VARCHAR2(4000);
-- one ALTER per wide column

Columns that exist on one side only. The target release can introduce metadata columns the source never had. You cannot insert ... select * across that gap; the column lists do not line up. Name every column explicitly on both sides and supply a default (NULL, or 0 for a boolean-style flag) for the target-only columns.

insert into TARGET_OCS.docmeta
  (xComments, xKeywords, /* ...all columns... */, xTemplateType, xIsAclReadOnlyOnUI, DID)
  select xComments, xKeywords, /* ...matching source columns... */, NULL, 0, DID
  from docmeta@DBLINK_WCC_PROD_CLONED
  where did in (select did from revisions@DBLINK_WCC_PROD_CLONED
                where ddoctype <> 'System');

The explicit mapping is tedious, and the tedium is the point: every schema difference gets resolved here, on the clone, rather than at two in the morning against production.

Step 4 — Carry workflows, users, folders and profiles

Content without its surrounding state is not a faithful rehearsal. Copy the supporting tables with the same discipline: filter against what the fresh target already has, and name columns explicitly wherever the schema drifted.

• Workflow state — WorkflowDocuments, WorkflowDocAttributes, WorkflowHistory. Items mid-approval on production should be mid-approval on the clone.
• Profile trigger values — ProfileTriggerValues, which drive content-profile behaviour.
• Users and security attributes — Users and UserSecurityAttributes, excluding the built-in platform accounts the fresh target already owns. Name the columns explicitly if the user tables changed between releases.
• Folders — QFL_Folder, FolderFolders, FolderFiles, inserting only folder GUIDs that do not already exist on the target. The fresh instance ships with a root structure you do not want to duplicate.
• Access log — clear the target's SctAccessLog and load the source's if you want access history to match.

Step 5 — Repoint the filesystem

This is the step that makes it a content clone rather than a database clone. The documents rows you copied point at files in vault and weblayout. If those directories are not present and the instance is not told where they are, every item resolves to metadata with a 404 behind it.

Copy production's vault and weblayout trees to the clone host, then point each content server's intradoc.cfg (and per-server variants) at them:

VaultDir=/path/to/cloned/ucm/cs/vault/
WeblayoutDir=/path/to/cloned/ucm/cs/weblayout/

Now a metadata row and its file agree. This is the difference between a rehearsal you can click through and one that looks fine in a query and falls apart when a user opens a document.

Step 6 — Reset the sequences

WCC uses database sequences to allocate the next ID for new content. You have just bulk-loaded rows with IDs the sequences know nothing about, so the next check-in will be handed an ID that already exists. Find the current maximum on each key table and restart the sequence just past it.

select max(dID) from revisions;                 -- e.g. 1292127
alter sequence IDCSEQREVID       restart start with 1292128;

select max(dRevClassID) from revisions;         -- e.g. 1067138
alter sequence IDCSEQREVCLASSID  restart start with 1067139;

select max(dDocID) from documents;              -- e.g. 2464060
alter sequence IDCSEQDOCID       restart start with 2464061;

select last_number from user_sequences where sequence_name = 'IDCSEQREVID';
SELECT IdcSeqRevID.NEXTVAL from DUAL;

The max() values are illustrative; the real ones come from your data, and the sequence names themselves can vary by release and configuration. The ordering is not negotiable: the reset happens after the bulk load and before the first check-in. If it slips, the collision is baked in, and re-running the ALTER afterwards does not un-corrupt the rows that were handed a duplicate ID.

Why this is the essential rehearsal for 12c to 14c

The platform documentation tells you how to move the WebCenter Content runtime from one release to the next. It cannot tell you how your content, your custom metadata, your in-flight workflow and your folder tree will behave when the out-of-place upgrade runs, because that is specific to your estate. A faithful clone is how you find out on a system where the answer costs nothing.

The clone pays twice. First as the test-upgrade target: run the 12c-to-14c upgrade against it, watch what breaks, fix the runbook. Second, because the reconciliation work — the widened columns, the explicit column maps, the sequence resets — is the production runbook. You are not rehearsing a different task; you are doing the real one on a safe copy first.

"It ran without error" is not "the clone is trustworthy". Every failure mode above — uniformly wrong metadata, a supporting table left behind, a sequence that has not collided yet — produces a clone that queries clean and looks live. Proving the clone mirrors production is a separate act: counts reconciled table by table, real documents opened with bytes, metadata and workflow state all agreeing, and the custom components and integrations checked that this pass would not otherwise touch. The post-upgrade validation checklist is the companion piece for the other end of the rehearsal.

How ECMWorks does this

On the last several 12c-to-14c upgrades we ran, standing up the clone was the first deliverable and the reconciliation notes from it became the cutover runbook. We read the running instance — components, profiles, integrations, the custom metadata model — to draw the content-versus-machinery line for that estate, build the clone, run the upgrade against it, and hand over a runbook that has already survived one full pass. Where the instance is heavily customized, lightly documented, or the people who built it have moved on, that read is the part that matters most.