Migrate from OPEX 365 CRM to Microsoft Dynamics 365 Sales

OPEX 365 CRM Contacts are standard Dataverse contact entity records that map directly to Microsoft Microsoft Dynamics 365 Sales Contact. We preserve full name components, email addresses, phone numbers, postal addresses, and lifecycle fields. Owner assignment migrates by resolving the source Owner's email against the destination User table. Any Contact record without a matching destination User goes to a reconciliation queue for the admin to provision before record import resumes.

OPEX 365 CRM Accounts are the parent entity for Contacts in the Dataverse model and map 1:1 to Microsoft Microsoft Dynamics 365 Sales Account. We preserve industry classification, annual revenue, address fields, and the parent-child hierarchy for nested account structures. Account is imported before Contact to satisfy the AccountId lookup on the child Contact records.

OPEX 365 CRM Opportunities map directly to Microsoft Microsoft Dynamics 365 Sales Opportunity. Pipeline and stage names vary between OPEX 365 CRM implementations, so we capture the source stage labels and map them to destination stage values configured in the customer's org. Estimated close date, actual close date, and amount fields migrate directly. Closed-Won and Closed-Lost reasons from custom properties become standard opportunity fields.

OPEX 365 CRM Lead records map to Microsoft Microsoft Dynamics 365 Sales Lead. Lead status and lead quality score properties migrate to corresponding destination fields. We preserve any lead source attribution and campaign association stored in the OPEX 365 CRM deployment. Leads are imported after Accounts because the customer may configure Account creation from Lead conversion.

Activities in OPEX 365 CRM use activityparty entities with polymorphic partyid references to Contacts, Accounts, Leads, or Users. We resolve each activityparty record to its correct target type and destination ID before importing. Emails become EmailMessage records; calls become Task records with TaskSubtype=Call; appointments become Event records; standalone tasks become Task records. Historical timestamps are preserved by setting ActivityDate to the original OPEX 365 CRM createdon value.

OPEX 365 CRM Cases (incident entity) map to Microsoft Microsoft Dynamics 365 Sales Case. We preserve case status, priority, subject, and entitlement associations. Case history migrates as a related activity timeline attached to the Case record. Cases are linked to their originating Contact and Account during migration.

OPEX 365 CRM Product records include pricing information linked via bundle and productpricelevel entities. We migrate the product catalog with pricing tiers, noting that bundle structures may require manual reassembly if the destination org uses a different pricing model. ProductCode and description fields migrate directly.

OPEX 365 CRM deployments frequently include custom entities built on top of the base Dataverse schema. We run a pre-migration schema discovery scan using the Dataverse EntityDefinitions endpoint to enumerate all custom entities and their attribute metadata before any data moves. Each custom entity is mapped to an equivalent custom entity in the destination org, with attribute types converted to match the destination schema (OptionSetValue to Picklist, UniqueIdentifier to GUID string, etc.). Lookup relationships to standard entities are preserved by resolving the target record IDs at migration time.

Notes and email attachments in OPEX 365 CRM are stored as annotation entities with base64-encoded content. We extract annotation records separately using the Dataverse RetrieveContent放电 API and store binary content in staging blob storage, then remap file references to the target CRM's attachment endpoint during import. This adds a distinct step to the migration sequence but is required to avoid losing file attachments embedded in Notes.

User records in OPEX 365 CRM include security roles and business unit assignments. We map source users to destination users by email address match. Any owner reference on a record that does not resolve to an active destination User is flagged for the customer's admin to provision before that phase of migration proceeds. Inactive source users are mapped to inactive destination users to preserve historical assignment attribution.