Oracle WebCenter Content repository to OCI: the field migration plan

Who this is for

You run Oracle WebCenter Content (WCC, still "UCM" to most of the people who operate it), probably clustered, probably with WebCenter Portal, Inbound Refinery and SOA alongside, on hardware you would like to stop owning. Moving the repository to Oracle Cloud Infrastructure is one of the cleaner modernization moves available: the content model, security model, custom components and integrations all carry forward, and only the platform underneath changes. This is the plan for doing it without discovering at go-live that your metadata and your files no longer agree.

The plan below was written for a state government agency's clustered, multi-terabyte WCC estate: production and test, Portal on top, Inbound Refinery, SOA, custom components, and roughly 15 TB of content on NFS. The sequence transfers to smaller estates unchanged; only the clock times shrink.

Inventory what "the repository" actually is

WCC spreads itself across more places than people expect. Before sequencing anything, write down every part. On the estate this plan was built for, the real inventory was:

• The database schema. WCC metadata, the security model, the content records. The system of record for what content exists.
• The file store. The bytes themselves, split into the Vault (native files) and the WebLayout (web-viewable renditions), on an NFS share alongside the shared cluster configuration. Around 15 TB in production on this estate.
• The search collection. The full-text index that makes content findable. It comes across intact or it gets rebuilt; either way it is a separate item.
• Custom components. Server-side customizations: home-page and browse-results changes, a configuration component, and a handful of others.
• Custom Java deployments. WebLogic-deployed EARs reading content through RIDC.
• Integrations. Inbound Refinery for PDF conversion, WebCenter Portal pulling HTML and images out of WCC, a capture front end, batch loaders, SMTP.

Whichever of these is missing from your list is the one that breaks the migration. The security model in particular (roles, security groups, accounts) has to be captured explicitly, because the schema enforces it and every integration references it. The content-server inspector and the component inventory tool pull most of this out of a running instance.

The core decision: each store moves differently

The whole plan rests on one recognition: the three stores migrate by three mechanisms, and the job is keeping them consistent with each other.

The database moves by backup and restore. On this estate the on-premises database was first upgraded in place to a supported release; then the WCC schemas were backed up and restored on the OCI target. Preserving the schema names exactly is not optional. WCC's configuration references them, and renaming turns a restore into a reconfiguration project.

The file store (Vault, WebLayout and the shared cluster files) moves as a file-system clone of the NFS share. This is where the terabytes are and where the clock runs longest, and that is what forces the sequencing decision in the next section.

The search collection comes across with the file store and is validated after cutover: confirm the collection is intact and that content is searchable before trusting it, and be ready to rebuild it if it is not.

The middleware tier is not migrated. It is rebuilt from scratch on OCI and re-pointed at the restored schemas and the cloned file store. This is deliberate. A clean Fusion Middleware, WebLogic and WCC install configured to connect to migrated data is far more predictable than dragging a domain between environments.

The sequencing problem: a multi-terabyte store and a live system

Here is the decision a generic runbook will not make for you. You have a 15 TB file store and a database that keeps taking checkins until go-live. Back up the database on a Friday and cut over the following Friday, and every document checked in during that week exists on the source and not on the target. The restored schema and the cloned file store are a week out of step.

The answer is a delta migration with the WCC Archiver, and it is the load-bearing part of the plan.

1. Bulk-move the big, slow stores first. Restore the database schemas and clone the file store. This is the expensive operation; do it once, well ahead of go-live.
2. Capture the delta with Archiver. On the source, export the content items checked in since the database backup timestamp, using a custom query on the Archiver. Make the export available on the target host with the correct Oracle user permissions.
3. Import the delta on the target, repeatedly, up to go-live. Configure the Archiver import location on the target and bring the delta across on a regular cadence. Add the ArchiverReplicationExceptions configuration so replication exceptions are handled rather than silently dropped.
4. Validate after each pass. Count content items, sample metadata, confirm the target is converging on the source rather than drifting from it.

This turns an impossible "freeze the business for a week" conversation into a background process. The bulk data moves once; the trickle of new checkins is caught continuously until the switch.

Rebuild and re-point the middleware

With the data in place, the middleware rebuild is methodical Fusion Middleware discipline. Confirm the OS and Java are on releases the target WebLogic and WCC binaries certify against, per Oracle's Fusion Middleware Certification Matrix. Stage the binaries with the right permissions. Open the ports the WCC, Inbound Refinery, SOA, Portal and database tiers need between them.

Then the configuration migration, which is where the file store and the middleware are reconnected:

• Install binaries and configure the domain (Fusion Middleware, WCC, SOA), with the WCC, IBR and SOA clusters connected to the restored schemas under their preserved names.
• Re-point the WCC shared configuration. In intradoc.cfg, the IntradocDir, VaultDir and WeblayoutDir entries must point at the cloned NFS paths on the target. This is the literal line where metadata meets bytes. Right, and content resolves; wrong, and every document is a broken link.
• Update host- and environment-specific settings. The server's HTTP address and the mail server in the shared configuration, so the migrated instance stops referring to the old environment.
• Migrate custom deployments. Download the WebLogic-deployed EARs from the source, edit each deployment plan's hostname for the target, install and start them from the target console.
• Migrate custom components. Export each component ZIP from the source WCC, install and enable it on the target, restart, and validate it individually.
• Move the rest of the configuration with a CMU bundle. Create a Configuration Migration Utility bundle on the source with every section selected and Add Dependencies on; export it; import it on the target. The dependency capture is what prevents importing configuration that references something that did not come along.

Two decisions that quietly remove most of the pain

Two choices on this plan did more to reduce risk than anything else, and both are the kind of thing you only appreciate after a migration done the hard way.

Keep the hostnames the same between source and target wherever you can. WCC and its integrations bake hostnames into configuration in more places than you will enumerate up front. Every hostname preserved is a class of reconfiguration, and a class of "we missed one" go-live bug, that never happens.

Keep the install user, group and file permissions identical. The file store arrives as a clone with ownership and permissions intact. Match the Oracle user, group and permissions on the target and there is no permissions-remediation pass over a multi-terabyte tree, which at that size is a real saving and a real source of avoided errors.

Neither is glamorous. Both are the difference between a migration that validates cleanly and one that becomes a week of chasing broken references.

Validate against the real failure modes

The migration is done when it has been proven, and the validation follows the same three-store shape as the plan.

• Content and file store agree. Vault, WebLayout and the cluster shared files are present; check-in, full-text search and check-out work end to end; the search collection is intact.
• Every integration point works. The capture front end, WebCenter Portal, Inbound Refinery conversions, batch loaders, SMTP.
• Every customization works. Each custom component and each RIDC-based Java deployment, individually, because these are the pieces most likely to be quietly depending on something environment-specific.

The upgrade validation checklist is the working document for this pass; most of it applies to a platform migration unchanged.

One sizing note that belongs in every plan: size the OCI target for growth, not for today's footprint. This estate's target was sized for two years of storage growth. A repository that is 15 TB now is not 15 TB in eighteen months, and resizing under a live content system is a project you would rather not schedule. The content-server sizing guide covers the method.

Why this is on your desk now

If the WCC estate is on Fusion Middleware 12c, the timing has a reason attached. 12c (12.2.1.4) leaves Premier Support in December 2026 and Extended Support in December 2027. WCC rarely lives alone: the same clock governs the WebLogic underneath it and, usually, the SOA, Inbound Refinery and Portal beside it. That makes a repository move to OCI less a standalone infrastructure task and more the natural moment to bring the whole stack onto a platform, and a release, with a real support runway ahead of it.

The work itself is well understood. The database restores, the file store clones, the Archiver catches the delta, the middleware rebuilds clean, and the content model and customizations carry forward untouched. The hard part is never a single step. It is the sequencing: keeping three stores consistent while the business keeps working. That is the part worth planning rather than improvising.

How ECMWorks does this

We have planned and run this migration on clustered, multi-terabyte WCC estates, and the plan moves from one estate to the next with very little change.

• Migration read. A fixed-scope read of the running estate: the three stores and their sizes, the custom components and Java deployments, the integrations, the security model, the hostname and permissions dependencies, and the 12c versus 14c question for the rebuilt tier. Output: the sequenced plan above, with your numbers in it, and a go-live shape the business can accept.
• Delivery. The bulk moves, the Archiver delta cadence, the domain rebuild (on 12c or 14c), the configuration and component migration, and the three-store validation, run by the people who wrote the plan.
• After cutover. A support retainer for the OCI estate, so the next change (an Object Storage tier, a Portal upgrade, a 14c step if it was deferred) starts from a documented position.

The AP-to-OCI note covers the Imaging, Capture and Forms Recognition components that usually move alongside the repository.