Migrate from CRM Runner to Salesforce Sales Cloud

CRM Runner Contact records map to Salesforce Contact. Name, email, phone, address, and custom fields transfer directly. We use email as the dedupe key during import. Any CRM Runner contact without an email address receives a placeholder email formatted as contact-{record_id}@crmrunner-migrated.local so that Salesforce's email deliverability rules do not block import. CRM Runner contacts without a linked Company map to a Salesforce Account named 'Unassigned - Migrated' for manual review post-migration.

CRM Runner Company records map to Salesforce Account. Company name becomes Account Name, domain data becomes Website, and address fields map to BillingAddress. We extract any embedded contact count from CRM Runner to flag Accounts that should have multiple Contact children in Salesforce. Account is created before Contact import so that the AccountId Lookup is satisfied at insert time.

CRM Runner's Job is a hybrid work-order-and-opportunity record containing status, assigned team members, location, time entries, and custom fields. We split this during migration: job name, amount (if present), stage, close date, and owner map to Salesforce Opportunity. If the destination org includes Service Cloud, the job's operational fields (location, technician assignment, service type, status) map to a Work Order custom object with a custom job_id__c field linking back to the originating CRM Runner record for audit. Time entries embedded within Jobs extract as a separate CSV package and do not map to standard CRM activity objects.

CRM Runner Team Member records (name, role, department, permission level) map to Salesforce User records. We resolve Team Members by email for matching against the destination org's User table. Active Team Members in CRM Runner map to active Salesforce Users; inactive Team Members map to inactive Salesforce Users. Any Team Member in CRM Runner without a corresponding Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Permission levels do not automatically map to Salesforce Profiles or Permission Sets; we document the gap as a manual configuration step.

CRM Runner embeds call logs, SMS threads, and in-app chat as discrete records attached to contacts or jobs. We flatten these into Salesforce Task records with TaskSubtype = Call for phone logs and TaskSubtype = Email for SMS threads, preserving the original timestamp as ActivityDate. For chat records we create Note records linked via ContentDocumentLink to the parent Contact or Opportunity. WhoId on the Task points to the migrated Contact; WhatId points to the related Opportunity if the communication is job-linked.

CRM Runner task records with due date, assignee, status, and description map directly to Salesforce Task. Assignee resolution uses the Team Member-to-User mapping. Task status values map to Salesforce Task Status (Not Started, In Progress, Completed, Waiting on someone else, Deferred). Any CRM Runner task linked to a Job maps via WhatId to the migrated Opportunity.

CRM Runner custom fields on contacts, companies, and jobs extract during scoping and map to Salesforce custom fields on the equivalent object. We create the destination field schema in Salesforce (via metadata API into Sandbox) before data import. Text fields map to Text, numeric fields to Number, date fields to Date, and picklist values to Picklist. Any custom field with no clear Salesforce type equivalent goes to a text field with a naming convention crmrunner_original_type__c and is flagged for the customer's admin to re-type post-migration.

CRM Runner pipeline stages map to Salesforce Opportunity Stage values within a Salesforce Record Type that we configure before migration. Stage names and ordering transfer directly. Any custom stage logic (conditional stage progression, automated stage-triggered notifications) is documented as a written specification for manual Flow rebuild because CRM Runner's pipeline configuration has no exportable automation component.

CRM Runner time-clock records (clock-in, clock-out, duration) are embedded within Jobs and Team Members rather than exposed as standalone objects. We extract them as a separate CSV package keyed on team_member_id and job_id with a crmrunner_migration_id column. These do not map to standard Salesforce CRM activity objects. We recommend pairing the CRM migration with a dedicated payroll tool migration for this data set.

CRM Runner payment records embedded within Jobs are exported as a separate financial CSV package. Salesforce Sales Cloud is not an accounting system; payment data is best served by a dedicated accounting tool (NetSuite, QuickBooks, Stripe). We include a payment_history.csv in the migration artifact package keyed on job_id and contact_id for import into the customer's chosen accounting platform.

CRM Runner product catalog entries and QR code configurations are platform-specific display assets with no standard Salesforce CRM equivalent. We do not migrate these as they are tied to CRM Runner's native product and service presentation layer. The customer must rebuild product catalog entries as Salesforce Products (Product2) and configure QR code generation separately using a Salesforce-native or AppExchange solution.

CRM Runner's trigger-action automations have no documented export or migration path. We document every automation identified during scoping as a written specification: trigger type, conditions, actions, and recommended Salesforce Flow equivalent. The customer's admin rebuilds them in Salesforce Flow post-migration. This is not included in the standard migration timeline and is a separate rebuild scope.