Separate the platform change from the application change
Use the exact-release SOA upgrade guide for the platform procedure. Separately identify any required changes to custom composites or an accelerator baseline. Do not assume that every process needs to be rewritten or that a successful runtime upgrade proves the customized workflow.
Preserve a versioned baseline of the deployed source, dependencies and configuration. If a replacement baseline exists, compare it with the original and customized versions. A difference is evidence to review, not an instruction to accept either side wholesale.
Check schema ownership and resolution
Oracle’s composite documentation describes shared artifacts accessed through SOA-MDS references prefixed with oramds. Inventory which dependencies are shared and which are local to the application.
For each reference, verify the expected artifact version, deployment location and design-time and runtime resolution. Include project configuration and deployment packaging. Do not replace every local schemaLocation with an MDS path merely because the runtime is changing.
Review namespace bindings and transforms
A namespace prefix is an alias; its meaning comes from the namespace URI bound to it. When merging BPEL, XSD, WSDL or XSLT, check that every use still resolves to the intended vocabulary. Renaming a prefix requires updating its references within the applicable scope.
Compare transforms by behavior: input and output structures, optional values, empty collections, repeated items and error handling. A newer file with the same name is not proof that it preserves a customization. Avoid copying historical task-comment or account-distribution blocks into another release without confirming their dependencies.
Prove the business result
Build and deploy the candidate to an isolated test environment. Exercise representative normal and exception paths and compare task data, document links, notifications and external transactions with the agreed baseline. Make sure test destinations cannot create production financial activity.
For cutover, first assess whether existing SOA work can finish and intake can pause. If active instances must continue, their compatibility and state handling require explicit planning beyond a source-code merge. Open ERP invoices should be reconciled separately.
Keep a change record linking each modification to its reason, dependency and test result. The SOA upgrade planning page and invoice process validation guide place this review within the wider acceptance plan.