Migrate from CRUMP CRM to Microsoft Dynamics 365 Sales

CRUMP CRM Contacts are standard Dynamics 365 Contact records. We export via the source org's Dataverse or OData endpoint and map directly to the destination Contact entity. Standard fields (fullname, emailaddress1, telephone1, address) migrate without transformation. CRUMP CRM may layer custom fields on Contact; we enumerate every custom field during the audit phase and map each to a corresponding custom field in the destination org's Contact entity before import.

CRUMP CRM Accounts map 1:1 to Microsoft Microsoft Dynamics 365 Sales Account records. Parent-child hierarchy, if present in the source org, is preserved and reconstructed using the ParentAccountId lookup. The account's primary contact is flagged during import so that the primarycontactid lookup is resolved before the next phase begins.

CRUMP CRM Deals correspond to Microsoft Dynamics 365 Sales Opportunities. The dealstage in CRUMP CRM maps to the StageName field on Opportunity, and pipeline assignment maps to a Sales Process or Record Type we configure in the destination before migration. Closed-Lost and Closed-Won dates, deal value (estimatedvalue), and probability all transfer directly. CRUMP CRM custom fields attached to Deals require explicit enumeration during the audit phase because the CRUMP CRM layer may use non-standard schema names different from the native Dynamics 365 opportunity schema.

CRUMP CRM's bundled Project Management module stores project records including status, start and end dates, assigned team members, and task summaries. We export project records and map them to the Dataverse msdyn_project entity or the Project table in Dynamics 365 Project Operations if that module is licensed in the destination. Task-level detail below the summary level may not be fully representable in the standard project entity without Project Operations; we flag any task records that cannot map natively and document them separately for admin rebuild.

Helpdesk tickets in CRUMP CRM are Cases or Incidents in Dynamics 365 Customer Service terminology. We map ticket status, priority, description, and the linked contact lookup. CRUMP CRM ticket custom fields require explicit enumeration and mapping against the destination Case entity's custom field schema. If the destination org does not have Customer Service licensed, tickets migrate as Cases in the base Sales entity set with a flag that the customer should consider Customer Service licensing for long-term support workflow management.

CRUMP CRM's bundled invoicing module exports invoice records with line items, totals, payment status, and dates. Microsoft Dynamics 365 Sales includes an Invoice entity backed by Dataverse. We preserve invoice headers and line items, and reconstruct the relationship to the originating Opportunity or Account from the source export. Invoice PDFs attached as notes migrate as ContentDocument records linked via ContentDocumentLink.

CRUMP CRM Tasks exist across multiple bundled modules (CRM tasks, project tasks, helpdesk tasks). We deduplicate by subject and timestamp, label each task by its origin module using a custom sourcemodule__c field, and import into the unified Microsoft Dynamics 365 Sales Task entity. Task Status, Priority, and ActivityDate preserve directly; assigned owner resolves via email match against the destination User table.

CRUMP CRM user accounts and role assignments export from the source Dynamics 365 instance. We match each user by email against the destination Microsoft Dynamics 365 Sales User table. Inactive CRUMP CRM users are archived rather than imported to prevent ghost records in the destination. Role and security role assignments are documented separately for the customer's admin to reconfigure in the destination because security roles carry org-specific permission sets that must be validated in the destination context.

CRUMP CRM may expose custom entities built on top of the Dynamics 365 Dataverse layer. Each custom object and its fields are enumerated during the audit phase. We map each custom entity to a corresponding custom table in the destination Microsoft Dynamics 365 Sales org, preserving API names with the __c suffix per Microsoft convention. Lookup relationships to standard entities are resolved in dependency order so that parent records are present at insert time.