Migrate from OpenCRM to Microsoft Dynamics 365 Sales

OpenCRM Organisation records map to Microsoft Dynamics 365 Sales Account. The Organisation Name becomes Account Name; the primary address maps to Address Line 1, City, State/Province, and Country. We use the OpenCRM record ID as an external identifier for upsert matching so that if a migration run is interrupted, subsequent runs update rather than duplicate Account records. Account must be imported before Contact because Dynamics 365 Contact requires a valid AccountId lookup at insert time.

OpenCRM Contact records map to Dynamics 365 Contact. We resolve the parent Organisation reference to an AccountId using the external identifier resolved in the Account import phase. Standard fields (FirstName, LastName, Email, BusinessPhone, MobilePhone) map directly; custom contact fields map to Dataverse custom fields created during the schema phase. Orphaned Contacts without a valid parent Organisation are flagged in a reconciliation report before we commit the Contact batch.

OpenCRM Deals map to Dynamics 365 Opportunity. Deal name becomes Opportunity Name; Deal value maps to EstimatedRevenue; expected close date maps to CloseDate; owner assignment maps to OwnerId via the User reconciliation table. The Deal's linked Organisation or Contact maps to AccountId and ContactId on Opportunity respectively.

OpenCRM pipeline stages are tenant-defined free-text values with no enforced list. Dynamics 365 Opportunity Stage is a picklist tied to a Sales Process. We produce a stage-mapping table during scoping, presenting it to the customer for confirmation of the 1:1 or N:1 mapping between OpenCRM stage names and Dynamics 365 stage values. Probability percentages migrate from OpenCRM to StageProbability, rounded to the nearest integer allowed by Dynamics 365.

If OpenCRM uses multiple pipelines to separate lines of business or product categories, each pipeline becomes a Dynamics 365 Opportunity Record Type with its own Sales Process that whitelists the relevant stage values. We configure Record Types and Sales Processes in the destination sandbox before migration so that Opportunity records land with the correct RecordTypeId from the first import run.

OpenCRM call activity records map to Dataverse PhoneCall or Task with TaskSubtype = Call. Subject, description, duration, and call outcome migrate to custom fields on the PhoneCall entity. The Parent Contact or Account reference resolves to the migrated ContactId or AccountId. We set ActualEnd to the original OpenCRM timestamp to preserve call chronology in the activity timeline.

OpenCRM meeting records map to Dataverse Appointment. Subject, Location, Start, End, and Description migrate directly. Attendees resolve to ContactId and AccountId references via the migrated Contact and Account records. The Organizer field maps to the resolved OwnerId of the original OpenCRM meeting owner.

OpenCRM task activities map to Dataverse Task with Status, Priority, Subject, and ActivityDate preserved. Assigned-to resolves via the User reconciliation table. Tasks linked to a specific Deal migrate with the WhatId pointing to the migrated Opportunity record.

OpenCRM Notes attached to Contacts, Organisations, or Deals migrate as Dataverse Annotation records linked via the ObjectId lookup to the migrated Contact, Account, or Opportunity. Note body migrates as the Notetext field; any embedded file references migrate as separate DocumentLocation annotations pointing to the attachment file store we extract alongside the record data.

OpenCRM custom fields on Contact, Organisation, and Deal are discovered during scoping by inspecting a sample CSV export. We create matching Dataverse custom fields in the destination environment before migration, mapping data types (text to String, number to Integer or Decimal, date to DateTime) and preserving the original OpenCRM field labels as field display names in Dynamics 365. Customer confirms custom field scope during the scoping sign-off.

OpenCRM Owner assignments on Deals and Contacts are resolved by email match against the Dynamics 365 User table. Owners without a matching Dynamics 365 User are held in a reconciliation queue and the customer's admin provisions the User record before the migration resumes. OwnerId references on Opportunity, Contact, and Account are written as the resolved Dynamics 365 User ID, not the OpenCRM owner name string.