Migrate from Kickserv to Salesforce Sales Cloud

Kickserv customers map to Salesforce Accounts as the company record, with the primary contact name mapped to the Account's primary Contact. Phone, email, and address from Kickserv populate the Account. Secondary contacts in Kickserv create additional Contact records linked to the Account.

Kickserv stores one address per customer record. This maps to the Account's shipping address in Salesforce. When Kickserv has separate billing and job-site addresses, both locations are preserved as custom address fields on the Account object. If multiple job locations exist per customer, additional custom address fields capture each site for dispatch routing purposes.

Jobs are the core work-order object in Kickserv. They map to Salesforce Cases by default, which lets Service Cloud features apply. Teams that need Kickserv-style job metadata (technician assignment, job type, status flow) configure custom Service_Job__c with all Kickserv job fields as __c fields. Status values map via value-mapping tables.

Kickserv job statuses such as Scheduled, In Progress, Completed, Cancelled, and On Hold translate to Salesforce Case Status values or a custom pick-list on Service_Job__c. The mapping deliberately preserves operational semantics — On Hold in Kickserv retains its distinct meaning and does not automatically convert to a Closed status in Salesforce, ensuring that workflow state accurately reflects the original service operation.

Kickserv job types including HVAC Repair, Plumbing, Electrical, and similar categories map to a Salesforce custom pick-list or the standard Case Type field. When Kickserv utilizes custom service categories beyond the built-in options, these become a custom Service_Type__c field on the job object to preserve all categorization detail from the source system.

Kickserv employees with API tokens map to Salesforce Users by email match — their technician ID and role transfer as custom fields. Non-billable staff without Salesforce licenses become Contact records so their job history is preserved but they cannot own records in Salesforce.

Kickserv estimates containing line items, totals, and approval status map to Salesforce Opportunities with custom Estimate__c fields storing the estimate number, version, and approval state. Organizations licensed for Salesforce CPQ can subsequently upgrade migrated estimates to native Quote objects, unlocking full quote-to-cash workflows and advanced pricing logic after the initial migration completes.

Estimate line items from Kickserv map to OpportunityLineItems in Salesforce, which first requires corresponding Products to exist in the Salesforce Pricebook with active PricebookEntries. When Kickserv line items are service descriptions rather than product SKUs, they migrate as Description-based line items without a PricebookEntry, preserving the description and quantity while limiting native Salesforce pricing functionality.

Kickserv invoices map to Salesforce Orders by default, with Order fields capturing the invoice number, date, total amount, and payment status. Paid invoices in Kickserv set the Order status to Activated with the payment date preserved as a custom field. Unpaid invoices retain Draft status until payment is recorded post-migration, maintaining the financial state from the source system.

Kickserv charges and online payments require a custom Payment__c object or manual reconciliation in Salesforce since no native equivalent exists. Stripe payment identifiers from Kickserv are preserved as custom text fields on the Payment__c record for audit trail continuity, enabling finance teams to reference the original payment processor transaction if needed.

Kickserv time entries tracking clock-in and clock-out activity map to Salesforce Tasks with Task.Type set to Time Entry, Subject containing the Job name, and a custom Duration__c field storing total hours worked. The OwnerId links to the resolved technician User record, maintaining attribution for payroll and utilization reporting purposes.

Scheduled appointments in Kickserv migrate directly to Salesforce Events with original start and end times preserved. The assigned technician maps to the Event OwnerId or AssignedTo field, while the related Job or Case attaches as WhatId for cross-object relationship continuity. Event status values including Confirmed and Cancelled map to Salesforce Event status fields.

Kickserv notes attached to jobs and customers migrate to Salesforce Notes in classic orgs or ContentNotes in Lightning Experience. The note body text, author information, and creation timestamp are all preserved during migration. Notes linked to specific jobs carry the parent Case or Service_Job__c ID for navigation and context within the migrated Salesforce records.

Photos and file attachments from Kickserv jobs re-upload to Salesforce Files linked to the parent Case or Service_Job__c record. Salesforce's default 25MB per file size limit applies to migrated attachments. Inline images embedded in Kickserv notes are extracted, downloaded, and re-hosted as Salesforce Files to maintain accessibility within the new system.

Kickserv custom fields on Jobs and Customers become Salesforce custom fields with the __c suffix following Salesforce naming conventions. Field types map accordingly: text fields to Text(255), numbers to Number fields, dates to Date fields, and pick-lists to Picklist fields. Multi-select pick-lists in Kickserv require custom multi-select fields in Salesforce to preserve the multiple-value selection capability.

Kickserv's bidirectional QuickBooks Online sync represents a Kickserv-specific integration with no Salesforce equivalent available out of the box. Migration teams must configure Salesforce-to-QuickBooks integration separately using middleware solutions, AppExchange connectors, or custom development after cutover completes. The invoice and payment mapping from Kickserv is documented for replay during the new integration setup.