Migrate from Jobber to Salesforce Sales Cloud

Jobber Client maps to a Salesforce Contact with its primary property promoted to an Account record. The Account captures the primary service address and company-level billing info; the Contact holds client name, email, phone, and a reference back to Account via AccountId. Jobber does not enforce a company hierarchy, so we create a default Account using the client's display name when no company association exists.

When a client has a single primary service location, Jobber Property maps directly to a Salesforce Account record with type='Service Location'. When a client has multiple properties (common for commercial HVAC or property-management clients), the first property becomes AccountId on the Contact, and additional properties migrate to a custom Property__c object linked to the Account via lookup. This split preserves every service address and its associated job history.

Jobber Quotes contain line items, pricing, and client-acceptance status. In Salesforce, quotes can live as Salesforce-native Quote records (which attach to Opportunities and support approval workflows) or as Opportunity records with custom fields holding the same data. We default to Opportunity-based quoting for simpler setups and surface the Quote object as an option when your team uses Salesforce CPQ or quote-approval routing.

Jobber Jobs map to Salesforce Tasks linked to the Contact (for work performed at a client location) with the associated AccountId populated for reporting. For teams that need to track job-type metadata (e.g., job category, priority, assigned crew), we recommend creating a custom Job__c object before migration so each work order is a first-class record with its own custom fields, related to the Contact and Account via lookup.

Jobber Invoices migrate to Salesforce Orders by default (preserving invoice number, total amount, status, and line items). If the Salesforce org uses Salesforce Billing or a third-party billing integration, the Order object is the correct target. For teams without Salesforce Billing, we surface invoice records as a custom Invoice__c object with a PDF attachment placeholder so the financial record is preserved even if the billing workflow is not active.

Jobber Team Members map to Salesforce Users by email address match. Unmatched team members are flagged before migration — either they are already Salesforce users or the team must decide to create them as Salesforce users before the full migration runs. We do not migrate role-based permissions from Jobber since Salesforce's sharing model (profiles, permission sets, roles) is destination-side schema configuration.

Jobber visits and appointments map to Salesforce Events with the original start/end time, assigned technician (mapped to Salesforce User), and parent Contact and Account. The Event's WhatId links to the related Account so calendar views show the full client context. Jobber's GPS check-in and route data does not have a Salesforce equivalent and is preserved as a custom field on the Event for reference only.

Every custom field in Jobber requires a corresponding Salesforce custom field created before migration. We deliver a schema setup plan listing each custom field name, data type, and target Salesforce field API name (ending in __c for custom fields on standard objects or on custom objects). Pick-list fields in Jobber require explicit value-mapping against Salesforce pick-list values — we flag mismatches for manual resolution before the test migration.

Notes attached to Jobber Clients or Jobs migrate as Salesforce Notes (legacy Note object) or ContentNotes (Lightning Experience rich-text notes) linked to the corresponding Contact or Account. Original create dates are preserved as CreatedDate if the note is created during migration; the original note timestamp is stored in a custom Original_Create_Date__c field for audit continuity.

Jobber payment records (credit card transactions, ACH, cash) have no direct Salesforce equivalent — Salesforce handles payments through Salesforce Billing, Stripe integrations, or third-party payment apps. We preserve payment records as a custom Payment__c object on the Order/Invoice record with transaction ID, amount, date, and payment method for reference. Payment processing logic must be rebuilt in Salesforce via your chosen payment integration.

Jobber's form and checklist data (e.g., pre-job safety checklists, post-job sign-off forms) have no native Salesforce equivalent. We export form submissions as JSON blobs stored in a custom Job_Form_Data__c long-text field on the Job__c record, and attach any PDF or image output as Salesforce Files (ContentVersion) linked to the same record. The form logic and conditional branching must be rebuilt in Salesforce using Flow or a third-party forms app.