Migrate from Oracle EBS CRM to Nutshell

Oracle EBS Accounts are stored in the ARHZTARZ base tables and exposed through the APPS schema. We extract AR_CUSTOMERS and HZ_PARTIES with billing address, site use, and classification data. Account maps directly to Nutshell Account. The EBS customer number becomes a custom Account field for audit. We scope extraction to the CRM-relevant party rows and flag any Accounts that exist solely in financial modules so the customer can confirm they are in scope.

Contacts in EBS reside in the HR or AR schemas depending on whether they represent employees or external parties. We extract HZ_CONTACTS and HZ_PARTIES with relationship links preserved. Nutshell People records receive the contact name, email, phone, title, and address fields. The EBS party site address migrates as the Person's address. We resolve the Contact-to-Account link at migration time using the EBS customer account relationship.

Oracle EBS Opportunities are stored in the CZ (Collaborative Selling) schema or the deprecated ASF schema depending on the CRM module version deployed. We identify the correct schema at discovery, extract deal name, amount, stage, probability, close date, and owner. EBS opportunity stages map to Nutshell Deal stages, with stage names and probabilities stored as a configuration document before migration begins. Owner resolution uses the FND_USER email mapping.

Oracle EBS Territory definitions are stored in AS_TERRITORIES and reference hierarchical org structures. We extract the territory hierarchy as a structured document listing parent-child relationships and assignment rules. Nutshell uses Teams (grouped by rep or region) as the equivalent access-control and assignment structure. The migration delivers a written territory-to-team mapping; the customer's admin rebuilds team membership in Nutshell because the two structures are conceptual rather than data-equivalent.

Custom objects in Oracle EBS CRM are stored in user-defined tables within the base product schemas with FK columns pointing to core tables like RA_CUSTOMERS. We extract the DDL for each custom table, document the column-to-column and column-to-parent relationships, and map them to Nutshell custom fields (for scalar attributes) or linked Account/Person records (for one-to-many relationships). Custom object naming and field types are preserved in a schema document that the customer uses to configure Nutshell before migration begins.

Activities and tasks in EBS are stored across the deprecated Teleservice tables or the modern Interaction Center tables depending on the CRM module installed. We identify the correct schema at discovery, extract activity type, subject, date, owner, and the parent Contact or Account reference. Activities migrate to Nutshell Activity records with the original timestamp preserved for timeline ordering.

Notes and audit history in Oracle EBS CRM are stored in FZ_NOTES or the application-level audit trail as text blobs with timestamps and owner references. We extract the note body, creation date, and owner as a Note record linked to the parent Account or Person in Nutshell. Rich text formatting in EBS notes may flatten to plain text depending on the storage format encountered.

Attachments in Oracle EBS CRM are stored as LOB data (BFILE or CLOB columns) or on the file system depending on the attachment configuration. We extract binary or BASE64-encoded blobs, map them to Nutshell file attachments linked to the parent Account or Person record. Very large attachments (over 10 MB per file) are flagged for the customer to handle outside the migration scope due to API payload constraints.

EBS users are employees sourced from the HR schema (PER_ALL_ASSIGNMENTS_F) with CRM-specific responsibilities assigned via FND_RESPONSIBILITIES. We extract FND_USER and FND_RESPONSIBILITY tables during discovery to produce an accurate user count and responsibility matrix. We resolve EBS users to Nutshell users by email. Any EBS user without a matching Nutshell account goes to a reconciliation queue for the customer's admin to provision before the migration runs.