Migrating from Oracle SOA Suite to Oracle Integration 3: inventory, equivalences and sequence

Many organizations run integrations on Oracle SOA Suite that work but are increasingly costly to operate: their own servers, patches, WebLogic versions and knowledge concentrated in a few people. Oracle Integration 3 (OIC), a managed service, removes much of that infrastructure burden. The benefit, however, depends on treating the migration as an integration project rather than a copy.

This article proposes a four-phase method: inventory, classification by style, review of technical equivalences and migration in waves. The criteria are general; each SOA Suite installation has particularities that must be verified in the inventory.

Inventory of the current platform

The first phase produces a complete list of what exists: SOA composites, BPEL and Mediator processes, and Oracle Service Bus services. For each element, the record includes which system starts the integration, which ones receive data, how often it runs (online, scheduled or file-based) and which business process depends on it.

The inventory serves a second purpose: identifying integrations nobody uses anymore. Retiring them before migrating reduces scope at no build cost. That is why the list should be checked against recent execution logs and business owners, instead of inferring usage from the code.

For each active integration, its behavior on failure (what happens and how it is reprocessed) and its security dependencies are also documented. Both are the aspects that differ most between platforms and appear least in existing documentation.

Classification by Oracle Integration style

Oracle Integration 3 organizes integrations by what starts their execution: Application, Schedule or Event, according to the integration styles guide. Assigning a style to each inventory item is the basis for estimation, because each style implies a different design and different tests.

Classification allows grouping similar integrations and reusing design, connections and test cases among them. A BPEL process invoked by an application usually maps to an Application integration; a process that queries a database every night, to a Schedule one. Cases that do not fit clearly should be flagged for review, not forced into a category.

Technical equivalences: adapters, network, transformations and security

OIC provides adapters for Oracle and third-party applications, databases, file transfer and REST and SOAP services; the official adapter catalog is the reference. For each integration, it must be confirmed that a suitable adapter exists or an alternative defined, typically a generic REST or SOAP call.

Systems that remain inside the corporate network are reached through the Connectivity Agent, which is installed on a company server and initiates communication with OIC through outbound requests. Its location, internet egress and availability are architecture decisions for the first phase, not construction details.

Existing XSLT transformations are an asset, but they do not carry over automatically: each one must be reviewed, and those that depend on SOA-platform-specific functions require redesign. Security is similar. Oracle Web Services Manager policies have no direct equivalent, so each connection needs an authentication scheme defined in OIC (OAuth, certificates or a technical user) and an owner for its credentials, following the REST Adapter authentication patterns.

Error handling is the most underestimated equivalence. The behavior documented in the inventory phase must be reproduced with the OIC mechanisms described in About Error Management. A migrated integration that works in the normal case but cannot be reprocessed after a failure is not finished.

Migration in waves

A sequence that reduces risk starts with a simple integration whose purpose is to validate connectivity, security and monitoring along the whole path. Groups of integrations with the same style follow and, finally, the critical integrations, each with a parallel-run period and a rollback plan.

The parallel run needs a comparison criterion defined in advance: which results must match between the SOA and OIC versions, and for how long. Without that criterion, the parallel run drags on with no clear cut-over decision.

The migration ends when the last SOA Suite server is shut down. While integrations remain on both platforms, the organization pays to operate both, and the plan should include a target date for that shutdown.

First deliverable and decision criteria

The first useful deliverable of a migration is the classified inventory, with an estimate per group and the equivalences still to be resolved. With that document, order and scope are decided on verifiable information.

• Complete inventory, checked against execution logs and business owners.
• Unused integrations identified and approved for retirement.
• OIC style assigned to each integration, with doubtful cases flagged.
• Adapter or alternative defined per connection, and Connectivity Agent location decided.
• Authentication scheme and credential owner per connection.
• Failure behavior documented and parallel-run criterion defined for critical integrations.

Xterra Engine prepares inventories and migration plans from SOA Suite to Oracle Integration, with classification and equivalences resolved before building.