Migrate from Oracle EBS CRM to Twenty CRM

Oracle EBS Accounts are stored in the ARHZTARZ base tables and exposed through the APPS schema. We query RA_CUSTOMERS and AR_CUSTOMER_ACCOUNTS for active account records, extracting account name, address, primary contact, and account type. The mapping resolves to Twenty Company records using the account name as the dedupe key. Multi-org EBS deployments require scoping the query to the relevant Operating Unit by filtering on ORG_ID in the AR tables. We preserve the original EBS account number as a custom field eb_legacy_account_number__c for audit and reconciliation.

EBS Contacts reside in base HR or AR schemas depending on whether they are employees or external parties — typically HZ_PARTIES joined to HZ_CONTACT_POINTS. We extract name, email, phone, job title, and relationship to Account (the HZ_CUST_ACCOUNT_ROLES link table). The mapping preserves the link to the parent Company in Twenty via the Person-Company relationship. We flag any contact record that exists in EBS without a corresponding Account as a standalone Person in Twenty.

Opportunities in EBS are stored in the CZ (Collaborative Selling) or deprecated ASF schemas depending on the CRM module version. We identify the correct schema at discovery time by querying DBA_TABLES for CZ_ tables and extract stage, amount, close date, owner, and pipeline. Stage names map to Twenty Opportunity stage values and probability percentages. Owner resolution happens by email match against the FND_USER table extracted during user discovery.

Territory definitions in EBS CRM are stored in AS_TERRITORIES with hierarchical org structures and per-OU assignment rules. Twenty does not have a native multi-org model — it uses workspaces and team-based access control. We map EBS territories to Twenty Workspaces, with the territory hierarchy flattened into workspace-child relationships. Each EBS territory assignment (which salesperson owns which account) becomes a team membership record in Twenty. The customer configures the workspace layout during migration scoping.

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 correct source table at discovery, extract subject, description, status, due date, owner, and the relationship to the parent Contact or Account. The original EBS activity timestamp becomes the ActivityDate in Twenty. Call disposition and duration map to custom task fields in Twenty.

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 with timestamps and owner references. Each note is linked to the parent Person, Company, or Opportunity in Twenty via the Note's target relationship. We flag any note record that references a deleted or unmigrated parent as orphaned and include it in the reconciliation report.

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 attachments as BASE64-encoded blobs with the original filename and MIME type preserved, and attach them to the corresponding migrated record in Twenty. We flag any attachment that exceeds the target system's file size limits for customer resolution before import.

Users in EBS CRM are employees sourced from PER_ALL_ASSIGNMENTS_F in the HR schema with CRM-specific responsibilities assigned via FND_RESPONSIBILITIES. We extract the FND_USER and FND_RESPONSIBILITY tables to get the user mapping matrix. Owner resolution in Twenty uses the email address as the dedupe key. Users present in EBS with no email address go to a reconciliation queue. The customer provisions matching Twenty users before the migration phase begins.

Custom objects in EBS CRM are stored in user-defined tables within the base product schemas and often reference FK columns pointing to core tables like RA_CUSTOMERS or OE_HEADERS. We extract the DDL for each custom table, create the equivalent Twenty Custom Object schema (including custom field definitions, field types, and lookup relationships) before importing any data, and then import the custom records with their relationship references resolved to the migrated parent records in Twenty. Custom object naming follows the customer's established convention.

Oracle EBS CRM does not have a native standalone Lead object separate from Account and Contact. Pre-sales prospect data typically lives as incomplete Account or Contact records. We identify these during discovery by querying for records with no revenue, no closed date, and early-stage status. These records become Persons in Twenty with a lead_qualification_status__c custom field set to Pending. The customer defines the qualification criteria during scoping.

Oracle Workflows (stored in WF_ tables and implemented via PL/SQL packages) encode routing, approval, and notification logic specific to EBS. These definitions cannot be exported as structured data and have no equivalent construct in Twenty CRM, which uses a different automation model. We document every active Workflow at discovery — capturing triggering event, routing conditions, and approver assignments — in a structured report delivered to the customer's admin for rebuild in Twenty's automation tools.

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. We do not migrate forecast data. We preserve the Opportunity records that feed the forecast so that Twenty's native pipeline and reporting capabilities can be used to rebuild the forecast view post-migration.