Migrate from Oracle Siebel to Microsoft Dynamics 365 Sales

Siebel's party-based architecture requires S_PARTY as the migration root. Every Account (S_ORG_EXT) and Contact (S_CONTACT) record carries a PARTY_ID foreign key pointing to a parent S_PARTY row. We extract S_PARTY records first, then S_ORG_EXT and S_CONTACT in the second pass, resolving the PARTY_ID to Account or Contact in Dynamics 365. Skipping this sequencing causes foreign-key violations at import time.

Siebel Accounts map directly to Dynamics 365 Account. The S_ORG_EXT row ID is preserved as a reference field for audit, and the Organization Name becomes Account Name. Siebel's Organization type, industry, and territory fields map to standard Account fields or custom fields configured in the destination org before migration.

Siebel Contacts map to Dynamics 365 Contact with a Lookup to the parent Account resolved via the S_PARTY PARTY_ID cross-reference. Each Contact's email address is used as the primary dedupe key during import. Contact job title, phone, and address fields migrate to standard Contact fields. Siebel's position-based access control does not map to Dynamics field-level security; we document the Siebel Position hierarchy for the admin to re-implement via Teams or Security Roles in Dynamics.

Siebel Opportunities map to Dynamics 365 Opportunity. Pipeline stage, revenue amount, probability, and close date transfer directly. The Opportunity-to-Account link is resolved at migration time using the Account PARTY_ID cross-reference. Siebel's multi-phase revenue tracking migrates as custom fields if the destination Dynamics org is configured for weighted revenue.

Siebel Quotes map to Microsoft Dynamics 365 Sales Quote. Quote header fields (name, status, expiration date, total amount) migrate to standard Quote fields. Quote line items migrate to Quote Product records linked via the Product2 lookup. The Quote-to-Order linkage in Siebel (S_DOC_QUOTE to S_ORDER) requires manual configuration in Dynamics 365 to associate the migrated Order with the migrated Quote.

Siebel Orders map to Microsoft Dynamics 365 Sales Order. Order header fields (order number, status, date, total) migrate to standard Order fields. Order line items (S_ORDER_ITEM) migrate to Order Products. Document attachments stored in S_ORDER_DOC and S_ORDR_DOC_LIT migrate as SharePoint files attached to the Order record via the Dynamics 365 SharePoint integration.

Siebel Service Cases map to Dynamics 365 Case. Case status, priority, assigned employee, and related activity logs transfer to standard Case fields. Custom escalation fields from Siebel extension tables migrate to custom Case fields. Case-to-Contact and Case-to-Account lookups are resolved using the S_PARTY PARTY_ID cross-reference at migration time.

Siebel Activities map to Dynamics 365 Task and Event based on activity type. Call, email, meeting, and task engagements transfer to Task (with TaskSubtype set for calls) or Event records with ActivityDate preserved for timeline ordering. Owner assignment migrates by resolving the Siebel Position/Employee to a Dynamics 365 User by email match. Activity-to-Contact and Activity-to-Account lookups resolve via the S_PARTY cross-reference.

Siebel Literature records (S_LIT) store metadata and a file system path reference to the binary document. The database export does not include the files themselves. We extract the S_LIT path list, package the corresponding files from the Siebel File System, and deliver them alongside the migration for re-upload into a Dynamics 365 SharePoint document library linked to the appropriate Account, Contact, or Opportunity record.

Siebel Assets (S_ASSET) represent installed products or financial holdings linked to an Account. We migrate the asset record with its name, quantity, status, and Account relationship. In Dynamics 365, assets can be represented using the native Asset (msdyn_asset) entity available in the Field Service or Project Service Automation apps, or as custom Product records with a serial number field, depending on the customer's Dynamics edition.

Siebel custom extension tables built atop the S_ base table pattern are migrated on a per-table basis. We export the extension table data, map foreign keys to parent S_PARTY or S_ORG_EXT records, and load into custom Dynamics 365 entities created before migration. Custom fields use the __c suffix per Dataverse naming convention. Each extension table requires a separate mapping pass because the schema is unique to the customer's Siebel configuration.

Siebel Positions represent organizational roles and control record visibility through the Position-Employee assignment model. Positions migrate as structural data only; we extract the Position hierarchy and document it for the customer's admin to re-implement via Dynamics 365 Teams, Security Roles, and Sharing Rules. User-to-Position assignment maps to Dynamics 365 User-to-Team membership, which controls data access differently than Siebel's Position-based visibility model.