Migrate your Oracle Siebel data

Accounts map to S_ORG_EXT, S_PARTY, and S_APPLNTGRP_ACC tables. Siebel uses a party-based architecture where Organization is a subclass of Party. We migrate accounts as-is, preserving the S_ORG_EXT row and the S_PARTY link.

Contacts map to S_CONTACT and S_PARTY. Each Contact is a Party record with a corresponding S_CONTACT extension. We preserve the S_PARTY row ID as the primary key and cross-reference any S_CONTACT extension fields.

Opportunities in Siebel track Deals through Pipeline Stages. We extract the opportunity record, its associated Pipeline Stage, Revenue amounts, and the Opportunity-Account link. Stage history is preserved as Activity-type records.

Quotes map to S_DOC_QUOTE and S_DOC_ORDER. Quote Items live in S_QUOTE_ITEM. We migrate the quote header, line items, pricing, and the Quote-to-Order linkage. Quote status transitions are preserved in the record history.

Orders use S_ORDER with Order Items in S_ORDER_ITEM and Order Documents in S_ORDER_DOC and S_ORDR_DOC_LIT. We preserve the order header, all line items, document attachments, and the Account/Quote lineage.

Service Cases in Siebel map to the Case/Service Request tables. We extract the case record, its status, assigned Position/Employee, and any related Activity logs. Custom escalation fields are preserved as extension columns.

Activities represent Engagements and Tasks. We map Activities to their parent Contact or Account record, preserving type, date, owner, and any custom Activity extension fields present in the source.

Literature records (S_LIT) store marketing and sales documents. We extract the Literature metadata including name, type, and URL/path reference. Binary document files require separate file system export coordinated with the database export.

Financial Assets map to S_ASSET and represent holdings or installed products linked to an Account. We migrate the asset record and its relationship to the parent Account.

Holdings in Siebel Financial Services map to S_FN_HLDNG and link to Financial Accounts (S_ASSET). The holding structure varies by financial services industry pack; we map the generic holding fields and flag any industry-specific extensions for review.

Custom data built atop Siebel's extension table pattern (tables starting with S_ with TYPE like 'EXTENSION') are migrated on a per-table basis. We export the extension table data, map its foreign keys to parent S_PARTY or S_ORG_EXT records, and flag any tables that require post-migration Siebel Tools recompilation.

Positions represent organizational job roles and control record visibility. We extract Position records and hierarchy (parent-child relationships) as structural data. User-to-Position assignment requires separate mapping in the destination system.

Siebel's integration layer (EAI adapters, business services, SOAP/REST connectors) is tightly coupled to the Siebel runtime environment and cannot be exported as portable data. Integration endpoints and connector configurations must be rebuilt in the destination platform.

Siebel Workflow Processes define business process automation and are stored in the Siebel repository (SRF). These cannot be migrated across platforms and must be redesigned in the destination system.