Oracle EBS to Cloud Migration: Coexistence Patterns With REST and OIC

The Long Migration Reality

Migrating from Oracle EBS to Oracle Cloud ERP is a multi-year journey for most organizations. During the transition, both systems run simultaneously, and data must flow between them. This coexistence period requires robust integration patterns that keep both systems synchronized while business operations continue uninterrupted.

Common Coexistence Scenarios

Financials migrates first while procurement stays on EBS: purchase orders created in EBS must generate invoices in Cloud ERP. HR moves to Cloud HCM while payroll stays on EBS: employee master data syncs from Cloud to EBS nightly. Order management stays on EBS while financials move to Cloud: revenue recognition data flows from EBS to Cloud GL.

Integration Architecture

Oracle Integration Cloud (OIC) is the recommended middleware for EBS-to-Cloud coexistence. OIC has pre-built adapters for both EBS (database adapter with connectivity agent) and ERP Cloud (native adapter), plus built-in transformation, error handling, and monitoring:

EBS publishes data changes through database triggers or concurrent programs that write to a staging table. OIC polls the staging table on a schedule, transforms the data to match Cloud ERP’s format, and calls the Cloud REST API or FBDI import. OIC logs every transaction and alerts on failures.

Master Data Synchronization

The hardest part of coexistence is master data: customers, suppliers, items, and employees. Decide which system is the master for each data domain. The master system owns creates and updates, and changes flow one-way to the secondary system. Cross-reference tables that map EBS IDs to Cloud IDs are essential and must be maintained by every integration.

CREATE TABLE ebs_cloud_xref (
    entity_type   VARCHAR2(50),   -- 'CUSTOMER', 'SUPPLIER', 'ITEM'
    ebs_id        NUMBER,
    cloud_id      NUMBER,
    sync_status   VARCHAR2(20),
    last_sync_dt  DATE
);

CREATE UNIQUE INDEX uk_xref ON ebs_cloud_xref(entity_type, ebs_id);

Error Recovery

Integration failures are inevitable. Build a reprocessing mechanism that allows failed records to be corrected and resubmitted without duplicating successfully processed records. Store the integration payload with each transaction so that support teams can diagnose failures by examining exactly what was sent and what the target system returned.