Migrate from CRM Runner to Microsoft Dynamics 365 Sales

CRM Runner's single Contact object maps to a split model in Microsoft Dynamics 365 Sales . We apply a qualification rule during scoping based on CRM Runner's pipeline stage property: contacts in an active pipeline map to Salesforce-style Leads; contacts associated with a Company record and a closed-won Job map to Dynamics Contact attached to an Account. We preserve the original CRM Runner pipeline stage in a custom field crm_runner_stage__c on both Lead and Contact for audit. Unqualified contacts without a Company association map to Lead with LeadSource defaulted to 'Other'.

CRM Runner Company records map directly to Microsoft Dynamics 365 Sales Account. The Company name becomes Account Name; address fields map to Address composite fields in Dataverse. We use Company external ID as the dedupe key during import and create Accounts before any Contact import so that the AccountId Lookup is satisfied at Contact insert time. Parent-child Account hierarchies require manual mapping if the customer uses CRM Runner's company grouping feature.

CRM Runner Jobs is the primary migration complexity. Jobs embed work order status, assigned team members, location, and time entries in one record. Microsoft Dynamics 365 Sales has no native Work Order object; we create a custom Work Order entity (crerunner_job__c) with fields for job status (mapped from CRM Runner job stage), address (from CRM Runner location), assigned technician (lookup to User), and duration (from embedded time entries). If the customer licenses Dynamics 365 Project Operations, Jobs may map to Project and Project Team Members instead. We confirm the target entity during scoping based on the customer's licensed modules.

CRM Runner Team Members map to Microsoft Dynamics 365 Sales Users. We resolve by matching CRM Runner email address against the destination Azure AD tenant. CRM Runner role and department fields map to Dynamics Security Role assignment and Team membership. Any CRM Runner Team Member without a matching Azure AD account goes to a reconciliation queue for the customer's admin to provision before user-assigned record migration begins. CRM Runner's GPS tracking and time-clock data does not map to Dynamics User fields and is flagged as a separate export artifact.

CRM Runner embeds call logs, SMS threads, and in-app chat as discrete records attached to Contacts or Jobs. We flatten these into Microsoft Dynamics 365 Sales activity records: phone calls map to Task with TaskSubtype=Call; SMS threads map to custom Note records or EmailMessage with Direction=Incoming; in-app chat logs map to Task records. The original CRM Runner timestamp preserves ActivityDate ordering. Calls and SMS attached to Jobs link via WhatId to the custom Work Order entity rather than Opportunity.

CRM Runner time-clock records are embedded within Jobs and tied to Team Members. They do not map cleanly to standard Microsoft Dynamics 365 Sales objects. We export time entries as a separate data package (CSV with job reference, team member reference, clock-in, clock-out, and duration) that the customer routes to a payroll system or imports into a custom Dynamics entity. Time entries associated with billable Jobs require the customer to decide whether to link them to the custom Work Order entity or handle them in a separate payroll tool.

CRM Runner payment records are embedded within Jobs and represent a financial data set rather than a CRM data set. We export payment records as a separate CSV package (transaction ID, amount, payment method, date, linked Job, linked Contact) that the customer imports into a dedicated accounting tool (Business Central, QuickBooks, or equivalent). Microsoft Dynamics 365 Sales is not the appropriate destination for payment transaction history; routing it there would create a data-shape mismatch that degrades CRM performance and reporting.

CRM Runner standalone Tasks map directly to Microsoft Dynamics 365 Sales Task records. Due date, priority, status, and description migrate directly. Task assignment resolves CRM Runner hubspot_owner_id to Dynamics OwnerId via the Team Member-to-User mapping. Open tasks migrate as Not Started; completed tasks migrate with Completed status and the original completion date preserved.

CRM Runner supports custom fields on Contacts, Companies, and Jobs. We extract all custom field definitions during scoping, map them to equivalent Microsoft Dynamics 365 Sales custom fields (with appropriate field types: Text, Integer, Decimal, Picklist, Boolean, DateTime), and deploy the destination schema via Dataverse API before any record import. Custom fields that reference CRM Runner-specific picklist values require a value mapping table to translate the options into Dynamics-compatible values.

CRM Runner pipeline stages are configurable and stored as a property on Contact and Job records. We map each CRM Runner stage name and order to a Dynamics Sales Process option set or a custom global option set that applies across Lead, Contact, Opportunity, and the custom Work Order entity. Stage probability values map to stageprobability on Opportunity if the customer uses that object.

CRM Runner automations configured through the trigger-action interface have no documented export or migration path. We do not migrate them as code. We document every active automation identified during discovery as a written specification: trigger type, conditions, and actions. The recommended rebuild path is Power Automate for cross-application flows (for example, notifying a Teams channel when a Job status changes) and Dynamics 365 Business Rules or Power Apps for form-level logic. Automations that involve CRM Runner's built-in VoIP or SMS require a separate communications platform migration.