Migrate from Civicrm to Microsoft Dynamics 365 Sales

CiviCRM Contact subtypes (Individual, Household, Organization) map to Dynamics Contact. We recommend mapping all CiviCRM Contacts to Dynamics Contact rather than splitting to Lead, because CiviCRM has no separate Lead object and organizations using CiviCRM typically track all contacts equally without a qualification gate. If the customer requires Dynamics Lead for an explicit sales qualification workflow, we define the split rule during scoping using contact properties such as source, activity count, or contribution history, and preserve the original contact record as a custom field on Lead for audit.

CiviCRM Activities (email, call, meeting, task subtypes) map to Dynamics Task and Event objects. Each Activity type routes to the corresponding Dynamics object: calls and tasks become Task records, meetings become Event records. The src_contact_id maps to WhoId, and the case_id or parent_case reference maps to WhatId pointing at the related Case. We flag Activities that represent informal deal or pipeline stages for Opportunity reconstruction separately during scoping.

Single-record custom groups attach as custom fields on the parent object using the custom.* selector in APIv4. Multi-record sets appear as separate entities prefixed Custom_ and become Dynamics custom objects with lookup relationships to the parent Contact or Case. We query both via API, reconstruct the multi-record cardinality, and create the corresponding custom object schema before import. Multi-record sets with more than 20 custom groups fall back to entity-by-entity exports to stay within MySQL join limits on the CiviCRM side.

CiviCRM Relationships (spouse, household member, employee, employer, and custom types) map to Dynamics Connection records with ConnectionRole matching the CiviCRM relationship_type label. Both contact references (contact_id_a and contact_id_b) map to the Dynamics record1id and record2id Contacts. We preserve the relationship is_active flag and start/end dates as custom fields on Connection since Dynamics Connections do not natively track activation periods.

CiviCRM Groups map to Dynamics Marketing Lists (for contact segmentation and campaign targeting) or Teams (for access control and record sharing). We preserve the group hierarchy where it exists, flattening nested groups into a flat list annotated with parent group references. Dynamic (smart) groups that recalculate based on CiviCRM search criteria cannot be reproduced as static lists; we document the search criteria and recommend rebuilding as a Dynamics Marketing List with equivalent filter conditions or a Power Automate flow.

CiviCRM Contributions (financial_type, total_amount, currency, receive_date, payment_instrument, check_number, card_type, trxn_id) have no standard Microsoft Dynamics 365 Sales equivalent. We create a custom object contribution_custom with fields matching the CiviCRM contributionfinancial_type, total_amount, currency, receive_date, and payment_instrument. Price sets introduce variable line-item complexity; we flatten price set fields to custom line_item fields on the contribution_custom record. The source contact_id maps to a Contact lookup.

CiviCRM Memberships (type, status, start_date, end_date, source, join_date, renewal_notification_date) have no standard Dynamics equivalent. We create a membership_custom object with type, status, start_date, end_date, join_date, and source fields. Membership Price Sets introduce tier complexity that we flatten into custom fields on the membership_custom record. The owner contact_id maps to a Contact lookup. If the customer also tracks membership fees as Contributions, we link the membership_custom record to the corresponding contribution_custom record via a custom lookup field.

CiviCRM Cases map to Dynamics Case records. Case_id, subject, case_type, and start_date migrate directly. Case statuses require per-type enumeration: we enumerate every active case_type during scoping, extract its status option values, and map each to a Dynamics global Case Status value. Status IDs are scoped to each case_type in CiviCRM; we handle this individually to avoid silent mis-assignments. The activity chain attached to each Case migrates as related Task records with WhatId pointing to the Case.

CiviCRM Events (title, event_type, start_date, end_date, location, max_participants, fee_level, is_monetary) map to a custom event_custom object. Price sets, participant roles, and online registration profiles introduce complexity: we flatten price set fields to custom price_level fields, participant roles to custom fields or separate participant records linked via Contact lookup, and registration profiles to a custom registration_custom object. If Dynamics Calendar is in use, we also create corresponding Calendar entries with registration links.

CiviCRM Grants (grant_type, amount_requested, amount_granted, amount_total, status, deadline, decision_date, notes) exist only where the Grants extension is enabled. We create a grant_custom object with the available grant fields and map the receiving contact_id to a Contact lookup. Grant data often has tight coupling to the associated Contribution records for grant-funded donations; we preserve the financial_type context on linked contribution_custom records for audit trails.

ECK allows arbitrary custom entity types with user-defined properties and custom field attachments. Each ECK entity type is scoped to a CiviCRM extension and can reference contacts via custom relationship fields. We handle ECK entities as custom objects requiring explicit schema analysis during scoping. We document each ECK entity type, its properties, its CiviCRM extension origin, and its contact reference pattern, then create corresponding Dynamics custom objects before migration. ECK entities without contact references and with purely internal organizational purpose are migrated at the customer's request and documented separately if out of scope.