All posts · OIC Integrations

OIC Integration Versioning and Lifecycle Management

OIC supports multiple active versions of the same integration — understanding when and how to use versioning prevents breaking changes from disrupting production.

Anurag Jangra · March 18, 2026 · 5 min read · ... views

How OIC versioning works

Every OIC integration has a version number (1.0, 1.1, 2.0, etc.). Multiple versions of the same integration can coexist in OIC — some active, some deactivated. This lets you roll out new versions gradually and roll back quickly if problems arise.

When to create a new version vs modify in place

Modify in place (minor changes): fixing a bug, updating a mapping field, changing a lookup value. These don’t affect the integration’s external contract (inputs/outputs remain the same).

Create a new version (breaking changes): changing request/response schemas, adding new required fields, changing the trigger endpoint URL. Callers of the integration need time to update.

Create a new major version: architectural changes, migrating to a new adapter type, significant performance restructuring.

Creating a new version

In OIC Designer: open the integration → Actions → Create New Version. Choose the new version number. OIC creates a copy — the old version remains active. You work on the new version independently until it’s ready.

Running versions in parallel

During transition, both v1.0 and v2.0 can be active simultaneously. Callers who have already updated point to v2.0. Legacy callers continue on v1.0. This prevents a forced cutover that breaks everyone at once.

The REST trigger URL includes the version: .../ic/api/integration/v1/flows/rest/MY_INTEGRATION/1.0/...

Deprecation workflow

  1. Activate v2.0 in production
  2. Notify all callers of v1.0 with a migration deadline
  3. Monitor v1.0 instance count in OIC monitoring — when it drops to zero, deactivate
  4. After a buffer period, delete the old version to keep the console clean

Versioning lookup tables

Lookup tables are shared across versions. If a new version needs different lookup values, create a new lookup table with a version suffix (CURRENCY_MAP_V2) rather than modifying the shared one — the old version is still using it.

Tags and documentation

OIC lets you add tags and descriptions to integrations. Use them. A description that says “v2.0 — migrated from SOAP to REST adapter, added support for multi-currency” is invaluable six months later when someone asks why there are two active versions.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp