Migrate from Oracle Siebel to Twenty CRM

Siebel's S_PARTY is the shared root table for both Contacts and Organizations. Every S_CONTACT and S_ORG_EXT record holds a PARTY_ID foreign key referencing its parent S_PARTY ROW_ID. We extract S_PARTY as the first migration pass, split the rows by PARTY_TYPE_CD ('Person' vs 'Organization'), and create the corresponding Twenty Contact and Company records. The original S_PARTY ROW_ID is preserved as a cross-reference field siebel_party_id__c on both record types for audit and reconciliation.

Siebel's S_CONTACT stores Contact-specific fields (job title, birth date, assistant details) that extend the S_PARTY Person row. We import S_CONTACT as a second pass after S_PARTY, using the PARTY_ID foreign key to link each extension row to the correct Twenty Contact. All standard contact fields (name components, email, phone, address) are mapped to Twenty's Contact fields. Custom S_CONTACT extension columns (S_CONTACT_X) map to Twenty Contact custom fields created during schema design.

Siebel's S_ORG_EXT stores Organization/Account fields that extend the S_PARTY Organization row. We import S_ORG_EXT in the second migration pass alongside S_CONTACT, after S_PARTY rows are committed. The primary S_PARTY ROW_ID becomes the siebel_party_id__c cross-reference. Siebel's multi-level Account hierarchy (parent-org-to-child-org) is mapped to Twenty's Company primary key lookup to self, which we flatten during import if the hierarchy depth exceeds Twenty's single-level parent-Company model.

Siebel Opportunities map directly to Twenty Opportunities. We extract the opportunity name, revenue amount, close date, stage (S_STAGE), probability, next step, and primary Contact and Organization links. Siebel's pipeline stage history is preserved as a JSON attachment or as timeline Activities against the Opportunity. The S_OPTY primary key is stored as siebel_opty_id__c for reconciliation.

Siebel's S_DOC_QUOTE and S_QUOTE_ITEM have no direct Twenty CRM equivalent. Twenty does not ship a native Quote object. During scoping, the customer selects one of three strategies: (1) migrate quotes as Opportunities with line items and a quote value field, (2) store quote PDFs as Twenty Attachments linked to the Opportunity, or (3) create a custom Quote custom object in Twenty matching the S_DOC_QUOTE schema. A Conemis case study of Siebel-to-Microsoft Dynamics migration (21 million records, 40 objects) documents that quote line items and quote-to-order relationships require careful HTML cleanup and conditional transformation rules.

Siebel Orders (S_ORDER, S_ORDER_ITEM) represent the fulfillment stage of the quote-to-cash cycle. If the customer selects the custom Quote object strategy, Orders are tracked as a status field on Quote. Otherwise, Orders migrate as Opportunities with a Closed Won stage and Order-type designation. The S_ORDER.SERVER_ID becomes siebel_order_id__c for cross-reference.

Siebel Service Requests (Cases) map to Twenty Cases. We extract the SR number, status, priority, resolution description, assigned Contact, and Organization link. Siebel's internal status workflow (New, Pending, In Progress, Resolved, Closed) maps to Twenty Case status values. Custom escalation fields in Siebel's industry packs (e.g., S_SRV_REQ_X) require corresponding custom fields in Twenty Cases before migration.

Siebel Activities (S_EVT_ACT) represent the full engagement timeline: calls, emails, meetings, and tasks. We map them to Twenty Tasks by type (call, email, meeting), preserving the activity date, owner, description, and the parent Contact or Organization link. Siebel's activity type codes (EVT_MTG, EVT_CALL, EVT_TASK) map to Twenty's task type enumeration. Custom activity extension fields (S_EVT_ACTX) require corresponding custom fields in Twenty before import.

Siebel Assets (S_ASSET) represent installed products and financial holdings linked to an Account. For standard product asset tracking, we migrate S_ASSET to Twenty Opportunities with a custom asset-type designation. For financial services customers with S_FN_HLDNG records, we create a custom Holdings custom object in Twenty with fields for product, quantity, account, and portfolio. The customer defines the custom object name during scoping.

Siebel Literature (S_LIT) stores document metadata and a file system path to the binary. The database export contains only S_LIT metadata (name, type, URL). We extract the file path list, package the corresponding files from the Siebel File System, and deliver them alongside the database export for re-upload as Twenty Attachments or external file references. Literature does not migrate as code or as embedded binary content.

Siebel Positions (S_POSTN) represent organizational job roles and drive record-level visibility through the Position-Employee assignment model. Twenty CRM does not have a Position or Organization hierarchy object. We extract Position records as reference data and document the Position-Employee assignments as a CSV for the customer's admin to re-establish in Twenty's workspace member management. S_POSTN does not map to a live Twenty object.

Siebel extension tables (tables prefixed S_ with TYPE='EXTENSION') hold custom fields for industry-specific data models (telecom, financial services, life sciences). We migrate each extension table as a Twenty Custom Object. Schema creation happens in Twenty's admin UI before data import. We map foreign keys to parent S_PARTY, S_CONTACT, or S_ORG_EXT rows, and preserve the original Siebel extension table name in the custom object name. Any S_EVT_ACTX custom activity extension fields require corresponding custom fields on Twenty Tasks before activity migration.