Migrate from CRUMP CRM to Salesforce Sales Cloud

Contacts from the Dynamics 365 CRM module map to Salesforce Lead if the contact is an unqualified prospect or to Salesforce Contact if the contact is associated with an Account. We apply the split based on the source contact's statecode, ownerid relationship, and any custom Dynamics 365 fields indicating qualification status. The original CRUMP CRM contact record ID is preserved in a custom field crump_contact_id__c on both Lead and Contact for audit and cross-reference.

Dynamics 365 Accounts map directly to Salesforce Account. The accountid from Dynamics 365 becomes the dedupe key during import. Parent-account hierarchy migrates via the ParentId field on Account. Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

CRUMP CRM Deals correspond to Dynamics 365 Opportunities. Deal name, estimatedvalue, closeprobability, and actualclosedate migrate to Opportunity Name, Amount, Probability, and CloseDate. The Dynamics 365 pipeline stage (stageid and stagename) maps to Salesforce StageName, which we configure as a Sales Process before migration. Closed-won and closed-lost reasons from Dynamics 365 custom fields become Salesforce Loss Reason and Win Reason picklist values.

CRUMP CRM Projects live in the Project Management module, a distinct Dynamics 365 entity type from CRM Deals. We export project records including project name, status, start and end dates, and assigned team members as a Salesforce custom object named Project__c. Task-level detail within projects may not be fully representable in a standard Salesforce deployment and is documented separately as a Phase 2 custom object or PSA (Product Scheduling Automation) integration scope.

Helpdesk tickets in CRUMP CRM are Cases in Dynamics 365 and migrate to Salesforce Case if the destination org includes Service Cloud or if the customer configures Case as a standard object. Ticket title, status, priority, description, and the linked contact's customerid migrate to Case Subject, Status, Priority, Description, and ContactId. Custom fields attached to tickets require explicit enumeration during the audit phase and are created as custom Case fields before import.

Invoicing records from the bundled suite export with line items, totals, and payment status. CRUMP CRM invoices link back to the originating Deal (Opportunity) in Dynamics 365; we reconstruct this relationship by matching the originating opportunityid on the invoice to the migrated Opportunity. Invoices become Salesforce Order records. If the customer does not use Salesforce Order Management, we deliver invoices as a structured CSV alongside the migration with a reference map for manual entry.

CRUMP CRM stores tasks across multiple modules: CRM tasks, project tasks, and helpdesk tasks. We deduplicate and label each task by its origin module using a custom field crump_module__c so the destination team can categorise or filter them. Task subject, status, priority, activitydate, and ownerid migrate directly. The original Dynamics 365 activityid is preserved in crump_activity_id__c for reconciliation.

Email history from Dynamics 365 CRM activities migrates to Salesforce EmailMessage records linked to an Activity Task record. The WhoId on Task points to the migrated Lead or Contact; WhatId points to the related Opportunity or Account. Email body and timestamp preserve. We use the Salesforce Bulk API 2.0 for large email histories because standard CSV import does not support the EmailMessage object.

Meeting records from Dynamics 365 activities migrate to Salesforce Event with StartDateTime, EndDateTime, Subject, and Location preserved. Attendee mapping links to EventRelation records pointing at the migrated Leads, Contacts, and Users. We resolve attendee email addresses against the migrated User and Contact tables during the transform phase.

Call activity records from Dynamics 365 CRM migrate to Salesforce Task with TaskSubtype = Call. Call disposition, duration, and any recording URL stored in Dynamics 365 custom fields migrate to custom Task fields. Activity ordering is preserved by setting ActivityDate to the original Dynamics 365 timestamp.

Notes from Dynamics 365 CRM migrate to Salesforce Note records linked via ContentDocumentLink to the parent record (Lead, Contact, Account, or Opportunity). Note body migrates as plain text. Any note attachments (which are separate blob records in Dynamics 365) are flagged separately for the file-level export pass.

CRUMP CRM user accounts and their Dynamics 365 security role assignments require explicit mapping. We resolve users by email match against the Salesforce destination org's User table. Inactive users in CRUMP CRM are archived rather than imported to avoid ghost records. Any CRUMP CRM user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Attachments stored as Dynamics 365 notes or SharePoint-linked document locations require a separate file-level export pass and cannot be migrated through the standard API layer without explicit SharePoint access credentials. We flag this as a separate file migration scope and do not include binary blob migration inside the standard API migration pass. If the customer uses Dynamics 365's notes with attachments, we enumerate every note with an attachment and provide a file inventory with record linkage for manual re-attachment or a scoped file migration engagement.

Custom entities created on top of the Dynamics 365 instance are enumerated during the audit phase. Each custom entity and its fields are documented individually because no two Dynamics 365 deployments share the same custom schema. We pre-create the equivalent Salesforce custom objects with matching field types, lookup relationships, and validation rules in a Sandbox before any data import. The destination API name follows Salesforce __c convention and is matched to the source entity's logical name where possible.