Migrate from Oracle EBS CRM to Salesforce Sales Cloud

Oracle EBS Accounts stored in the ARHZTARZ and APPS schemas map to Salesforce Account. The AR_CUSTOMER_NUMBER or RA_CUSTOMERS.CUSTOMER_NUMBER becomes an external ID field in Salesforce for dedupe during import. Oracle Operating Unit (ORG_ID) does not have a direct Salesforce equivalent — we map this to a custom picklist field ebs_operating_unit__c or to a Salesforce Division if the Enterprise org uses Divisions. Account Type (ORGANIZATION, PERSON) maps to Salesforce Account Type.

Contacts in EBS reside in the HR schema (PER_ALL_ASSIGNMENTS_F for employees) or AR schema (HZ_CONTACTS for external parties) depending on party type. We extract from the correct base table identified at discovery and map to Salesforce Contact. The HZ_PARTIES.PARTY_ID becomes a custom field ebs_party_id__c for reconciliation. Contact relationship to Account is preserved via HZ_CUST_ACCOUNT_ROLES linking to RA_CUSTOMERS.

Oracle EBS Opportunities stored in the CZ schema map to Salesforce Opportunity. The CZ_OPPORTUNITIES.CZ_OPPORTUNITY_ID becomes an external ID. Stage, Amount, CloseDate, and Owner map directly. If the EBS CRM uses the deprecated ASF schema instead of CZ, we identify this at discovery and adjust the extraction query — ASF uses different column names and the migration mapping must reflect the actual schema deployed.

EBS CRM custom objects are stored in user-defined tables within the base product schemas, often with FK columns referencing RA_CUSTOMERS (Account) or OE_HEADERS (Order). We extract the DDL for each custom table during discovery, map the column types to Salesforce field types (VARCHAR2 to Text, NUMBER to Number, DATE to Date, CLOB to Long Text Area), pre-create the destination custom object in Salesforce, and import in dependency order so that parent Account lookups are resolved before child custom object records insert.

Oracle EBS attachments are stored as LOB data (BFILE pointing to filesystem or inline CLOB) in FND_ATTACHMENT_FUNCTIONS or the ICM tables. We extract them as binary BLOBs or BASE64-encoded blobs, upload to Salesforce Files (ContentVersion), and link via ContentDocumentLink to the parent Account, Contact, or Opportunity record. The original filename and MIME type are preserved in ContentVersion.

Activities and tasks are stored across deprecated Teleservice tables or modern Interaction Center tables depending on the CRM module version installed. We identify the correct schema at discovery, extract the activity type (call, email, meeting, task), timestamp, owner reference, and free-text body, and map to Salesforce Task with the appropriate TaskSubtype. Activity ordering is preserved by setting ActivityDate to the original EBS timestamp.

Notes and audit history in EBS CRM are stored in FZ_NOTES or the application-level audit trail. We extract them as text blobs with timestamps and owner references and migrate to Salesforce Note records linked via ContentDocumentLink to the parent Account, Contact, or Opportunity. Rich-text formatting is preserved where present; plain-text notes carry over verbatim.

Oracle EBS users are employees sourced from PER_ALL_ASSIGNMENTS_F with CRM responsibilities assigned via FND_RESPONSIBILITIES. We extract FND_USER (username, email, start/end dates) and FND_RESPONSIBILITY (responsibility name, application) during discovery. Salesforce User records must be provisioned manually by the customer's admin before migration because User creation requires active Salesforce licenses. We provide a user mapping table that matches EBS user emails to Salesforce User IDs for OwnerId resolution during record migration.

Oracle EBS Territory definitions stored in AS_TERRITORIES with hierarchical org references map to a combination of Salesforce custom fields or the native Territory Management object (available in Enterprise and above with territory management enabled). We extract the territory hierarchy and assignment rules and document them as a mapping for the customer's Salesforce admin to implement via Territory Management or a custom territory custom object with rollup hierarchy.

Oracle Workflows encode routing, approval, and notification logic in PL/SQL packages with no export mechanism. We document every active Workflow at discovery — triggering event, routing conditions, approver assignments — in a structured report. This report is handed off to the customer's implementation team to rebuild the automation logic in Salesforce Flow. Workflows do not migrate as data or code within standard migration scope.

Forecasting in Oracle EBS CRM is implemented through the Collaborative Selling module with forecast data in versioned CZ tables tightly coupled to Opportunities and Territories. There is no standard export mechanism for forecast data, and forecast records represent point-in-time snapshots that are not meaningful in a new CRM with a different data model. We do not migrate Forecast data. We document the EBS forecast structure (versions, territory rollup, amount vs quantity forecast) and recommend rebuilding in Salesforce Collaborative Forecasting post-migration.

If the source system is Oracle CRM On Demand rather than Oracle EBS (a related but distinct product), Leads are available as a standard object and map directly to Salesforce Lead. Lead Status, Lead Source, and any custom Lead fields migrate with type mapping. This mapping applies only when the source is Oracle CRM On Demand; Oracle EBS CRM does not have a standalone Lead object separate from the Account-Contact model.