Lift-and-shift WebCenter AP to OCI: a migration playbook

Not every Oracle shop running accounts payable on WebCenter is ready to re-platform onto Fusion. Many have years of invested process in WebCenter Imaging, Forms Recognition and Enterprise Capture, and the immediate goal is simpler: get off ageing on-premises hardware and onto Oracle Cloud Infrastructure without breaking AP.

That move is a lift-and-shift, and it is a legitimate, lower-risk first step. We have run it — a global enterprise moved its critical AP operation from on-premises WebCenter onto OCI and then, once the foundation was stable, went on to consolidate its integrations on Oracle Integration. This note is the playbook for that kind of migration: what maps to what, how to sequence it, and what the move does and does not change.

If the roadmap runs all the way to Fusion, read this beside Migrating AP from WebCenter to Fusion Cloud; the lift-and-shift is often phase one of that larger journey.

Why lift-and-shift before re-platforming

A WebCenter-to-Fusion move changes the system of record, the approvals framework and the integration model in one go. A lift-and-shift to OCI changes none of them. WebCenter keeps running — same Imaging, same Forms Recognition project, same Capture jobs, same EBS underneath — on Oracle's infrastructure instead of yours.

The payoff is immediate and unglamorous:

• Headroom. WebCenter on current OCI compute is more responsive than ten-year-old tin, with room for quarter- and year-end peaks.
• Capital to operating cost. Hardware, on-premises software and the maintenance around it become an operating line.
• A platform for what comes next. Once on OCI, Oracle Integration, the database services and Object Storage lifecycle policies are adjacent rather than a project away.

It de-risks the bigger journey by separating "move to cloud" from "change the application".

What maps to what

Most of the architecture transfers conceptually intact. The mappings to be confident about:

State only the mappings you are sure of and validate the rest against your version and customisations. Estates in the field range across 11g, 12c and 14c, and the path differs by starting point. Oracle's WebCenter for OCI Marketplace images are the packaged route for 12c estates; whether to take them as-is or use the move to modernise is compared in OCI Marketplace vs modernise.

How to sequence the migration

Order matters more than speed. A sequence that has held up in practice:

1. Inventory the WebCenter footprint. Every Imaging, Forms Recognition and Capture customisation — Verifier fields, email import processors, the workflow hooks into EBS. Undocumented customisations are where lift-and-shifts go over budget.
2. Stand up the OCI landing zone. VCN, Object Storage buckets and the database tier, with the security posture right before anything moves. Aim for no public IPs and private connectivity into the Oracle estate.
3. Migrate the document archive first. Move the image store to Object Storage and verify retrieval end to end — including the links back to EBS records — before touching the application tier.
4. Lift the application and database tiers. WebCenter and its schemas onto OCI compute and the database service, behind the load balancer.
5. Reconnect to EBS and validate. Capture, recognition, routing and posting against a representative invoice sample in a non-production environment.
6. Cut over with a rollback plan. Run in parallel where you can, and keep the on-premises environment recoverable until OCI has cleared a real period close.

What the move does not change

A clean lift-and-shift gives you the same WebCenter AP process on better infrastructure. Faster, more stable — and otherwise identical. Two things in particular are unchanged, and both are worth saying out loud to the steering group before the project starts.

The support timeline. The application is still Fusion Middleware 12c. Premier Support still ends December 2026 and Extended Support still ends December 2027. The hosting has moved; the release has not. The 14c upgrade, or a move off the stack, is a separate decision that the lift-and-shift makes easier to execute but does not make for you.

The process. Whatever was manual on-premises is manual on OCI. Verifier touch rates, exception handling and supplier-inbox chasing are exactly what they were. That is fine if the goal was hosting. If the goal was a better AP operation, the design work for that belongs in the plan from the start — the neutral comparison of Oracle's own options is in the 12c end of Premier Support decision.

How ECMWorks does this

We treat a WebCenter-to-OCI move as an inventory problem first and a migration second, because the inventory is where the budget is decided. The shape is a fixed-scope footprint read — customisations, integrations, archive volume and age distribution — followed by the landing zone, the archive migration, the tier lift and a cutover rehearsal against a real invoice sample. The same engineers who read the footprint run the cutover, and the inventory is yours to keep whether the next step is the 14c release, Fusion or nothing further for a while.