Migrate from OPEX 365 CRM to Salesforce Sales Cloud

OPEX 365 CRM Contact records with a null or unqualified lead status map to Salesforce Lead. Contacts with an associated Account and a qualified lifecycle stage map to Salesforce Contact under the resolved Account. We preserve the original Dataverse contactid as a custom field opex_contact_id__c for cross-reference audit and any future bi-directional sync requirements.

OPEX 365 CRM Account maps directly to Salesforce Account using accountid as the dedupe key. Parent account hierarchy migrates via the ParentId field. Industry classification, annual revenue, number of employees, and address fields map to their typed Salesforce equivalents. Account is created before Contact import so that AccountId is resolved at the moment of Contact insert.

OPEX 365 CRM Opportunity maps to Salesforce Opportunity. Pipeline and stage names are captured from Dataverse processstage or custom pipeline/stage metadata and mapped to Salesforce StageName after the target Record Type and Sales Process are configured. Estimated close date maps to CloseDate and Amount maps to Amount. We preserve the original opex_opportunity_id__c cross-reference field.

Each distinct OPEX 365 CRM pipeline becomes a Salesforce Record Type on Opportunity, with a corresponding Sales Process that whitelists only the relevant stage values. Stage probability percentages migrate from Dynamics stage probability metadata to Salesforce StageProbability. Closed-Won and Closed-Lost stage names are preserved for reporting continuity.

OPEX 365 CRM Lead maps directly to Salesforce Lead when a separate Lead object exists in the source environment. Lead status, lead quality score, and source campaign attribution migrate to custom fields if the destination Salesforce org does not have matching standard fields.

OPEX 365 CRM Cases (incidents) map to Salesforce Case. Case priority, status, subject, and description migrate directly. We resolve the regardingobjectid reference to link the Case to the correct Account or Contact in Salesforce. Entitlement and SLA associations are preserved as custom fields since Salesforce Service Cloud entitlement management requires separate configuration.

OPEX 365 CRM Product records map to Salesforce Product2. The product number or SKU maps to ProductCode. Product bundle structures (productpricelevel entities) are decomposed: the parent bundle migrates as a Product2 and child items migrate as related Product2 records with a custom bundle_parent__c lookup field, since Salesforce OpportunityLineItems do not natively support nested bundles.

OPEX 365 CRM Dataverse User records are resolved against Salesforce Users by email address. The destination User must be provisioned before migration begins. Any owner reference in the source that does not resolve to a Salesforce User goes to a reconciliation queue. Inactive users from Dynamics are created as inactive Salesforce Users to preserve historical assignment on audit records.

OPEX 365 CRM ActivityPointer records are split by activitytypecode: email records migrate to Salesforce EmailMessage; phone call and task records migrate to Task with TaskSubtype set; meeting and appointment records migrate to Event. Each activity is resolved to its WhoId and WhatId in Salesforce using the Activity Party resolution pass before insert. ActivityDateTime preserves the original timestamp for timeline ordering.

The Dataverse ActivityParty entity is polymorphic: a single activityparty record can reference Contact, Account, Lead, or User via partyid. We resolve each reference to its target type and Salesforce ID before importing the parent Activity. Missing target records are created as placeholder Contacts with a flag indicating they require manual review post-migration. Event attendees create EventRelation records in Salesforce.

OPEX 365 CRM annotation records require a separate extraction pipeline. The Dataverse RetrieveContent放电 API is called per annotation to extract the base64-encoded file body, which is stored in FlitStack AI staging blob storage. During Salesforce import, ContentVersion records are created with the binary body and linked via ContentDocumentLink to the parent record (Contact, Account, Opportunity, Case). Text notes migrate as Salesforce Note objects. This two-phase approach is required because standard Dataverse API responses do not include attachment bodies.

Any Dataverse entity beyond the standard Contact, Account, Opportunity, Case, and Activity objects is enumerated during pre-migration schema discovery via the EntityDefinitions endpoint. Each custom entity migrates to a Salesforce Custom Object with the __c API name suffix. Custom attributes are mapped to typed Salesforce fields. Lookup relationships to standard objects are resolved via the same parent-record lookup sequence used for standard objects. Custom entities with polymorphic lookups require the same disambiguation pass as ActivityParty.