Migrate your Oracle EBS CRM data

In EBS CRM, Accounts are stored in the ARHZTARZ base tables and exposed through the APPS schema. The Account object maps directly to standard CRM Company/Account objects in most destination systems. We preserve the operating unit and org_id assignments as custom properties to maintain multi-org context.

Contacts reside in the base HR or AR schemas depending on whether they are employees or external parties. We map contacts to the destination CRM Contact object and preserve relationship links to Accounts, including the primary contact flag and role assignments stored in EBS relationship tables.

Opportunities in EBS are stored in the CZ (Collaborative Selling) or deprecated ASF schemas depending on the CRM module version deployed. We identify the correct schema at discovery time, extract stage definitions and probability rules, and map them to the destination pipeline stages — accepting that custom probability curves require manual alignment post-migration.

Custom objects in EBS CRM are stored in user-defined tables within the base product schemas. They often reference FK columns pointing to core tables like RA_CUSTOMERS or OE_HEADERS. We extract the DDL to understand the schema, then apply a generic mapping strategy that flattens custom object relationships into destination CRM custom objects or linked records.

Attachments in EBS CRM are stored as LOB data in the database (BFILE or CLOB columns) or on the file system, depending on the attachment configuration. We extract them as binary or BASE64-encoded blobs and reattach them to the corresponding records in the destination system, with naming conventions that preserve the original category and context.

Oracle Workflow (WF) is a proprietary process automation engine tightly coupled to the EBS application layer. It encodes routing rules, notifications, and approval chains in PL/SQL packages and WF tables that have no equivalent representation in cloud CRMs. We do not migrate Workflow definitions as functional artifacts; we document the existing workflow logic so it can be re-implemented declaratively in the destination platform.

Territory definitions in EBS CRM are stored in the AS_TERRITORIES base tables and reference hierarchical org structures. We extract the territory hierarchy and assignment rules and map them to the destination CRM's territory or team assignment model, noting that the hierarchical depth may exceed the destination's native nesting limits.

Activities and tasks are stored across multiple EBS CRM schemas (the deprecated Teleservice tables or the modern Interaction Center tables) depending on which CRM module is installed. We identify the active schema, extract activity type, date, owner, and outcome fields, and map them to the destination CRM's Activity or Engagement objects, preserving the timestamp and status.

Forecasting in EBS CRM is implemented through the Collaborative Selling module and stores forecast data in versioned CZ tables with tight coupling to Opportunity and Territory objects. There is no standard export mechanism and the data model varies significantly by EBS release. We preserve the last forecast snapshot as a static historical record and flag it as reference data for manual entry in the destination system.

Notes and audit history in EBS CRM are stored in generic note tables (FZ_NOTES or equivalent) or in the application-level audit trail. We extract them as text blobs with timestamps and owner references and import them as Note objects in the destination CRM, attaching them to the corresponding parent record by customer ID.

Users in EBS CRM are employees sourced from the HR schema (PER_ALL_ASSIGNMENTS_F) with CRM-specific responsibilities assigned via FND_RESPONSIBILITIES. We extract the user mapping table and the responsibility hierarchy, then map to Owner/User records in the destination CRM, flagging inactive EBS users who should not be provisioned in the new system.