Who this is for
Teams upgrading a connected Content, Imaging, Capture and SOA estate, particularly one supporting invoice processing. The plan needs to account for both the individual products and the work that crosses their boundaries.
Draw the dependencies before choosing the order
Inventory each domain, schema, storage location, identity provider and integration endpoint. Identify which components share infrastructure and which are independently deployed. Record the actual starting versions and the compatible target combinations.
Keep WFR in the process map while confirming its own product build, operating system and interoperability requirements. Do not treat it as another application automatically upgraded by the WebCenter domain procedure.
A useful dependency map links an application to the business action it enables: ingest a document, validate a supplier, code an invoice, open a task, import a transaction or retrieve an image from the ERP. This makes it easier to choose meaningful tests.
Give each component its documented procedure
Use the WebCenter domain upgrade guide for the applicable Content estate and the SOA Suite and BPM upgrade guide for the workflow estate. Confirm prerequisites and compatibility before combining those procedures into one change plan.
A sequence used for an earlier release does not establish the correct sequence for 14c. Shared-home assumptions, old administration tools, database changes and custom scripts need their own review. A clean build of a SOA composite is a useful checkpoint, followed by deployment and runtime tests against the target services.
Agree what happens to existing work
Many customers complete their SOA instances before migration. Make that a planned option: define the intake stop, completion criteria, exceptions and ownership of any work that cannot finish.
If the business requires active work to remain, validate the treatment for the particular path. Oracle documents active-instance data migration in specific SOA upgrade procedures; that is not a general instruction to move every running process in every migration.
Keep three reconciliations distinct: workflow instances and tasks, unfinished ERP invoices, and retained documents with their links and permissions. Closing workflow instances does not, by itself, reconcile the other two.
Test the seams between systems
Use representative transactions that exercise the dependencies rather than checking each console separately. Include both successful processing and exceptions that users must resolve.
| Boundary | Example acceptance question |
|---|---|
| Capture to Imaging | Does the expected document arrive with usable metadata? |
| WFR to the integration | Are validated values exported in the expected contract? |
| Coding form to reference data | Can an authorized user select and validate the required account? |
| SOA to the ERP | Is the transaction accepted once and reconciled to its source? |
| ERP to Content | Can the intended user retrieve the correct document? |
| Cluster node to node | Do task actions and document access behave consistently? |
Record expected and observed results. Use controlled test data and distinguish an application failure from an unavailable test dependency.
Plan recovery across the same boundaries
Database, domain and storage recovery must produce a mutually consistent state. External transactions already accepted by an ERP need reconciliation before any retry or replay. Define the change freeze, recovery decision time and owner of each step.
A retained source installation helps only when its data and dependencies can be restored to a compatible state. Test that assumption in the rehearsal rather than relying on a traffic switch.
How ECMWorks does this
We turn the inventory into a coordinated plan with version-specific procedures, clear workflow closeout decisions and business acceptance tests. The handoff includes the dependency map, rehearsal evidence, cutover responsibilities and recovery conditions so the operating team can use the plan after the project.