Migrate from Summit Service Systems to Salesforce Sales Cloud

Summit service tickets map directly to Salesforce Cases without requiring any custom object creation. Ticket priority, status, and category fields translate to Salesforce Case Priority, Status, and Type pick-lists respectively. The original ticket number from Summit is preserved as Custom_Service_Ticket_ID__c on the Case record, ensuring traceability back to the source system and enabling delta-run de-duplication during incremental migration phases.

Summit work orders have no direct Salesforce standard-object equivalent, so FlitStack creates a custom Work_Order__c object to host this data. The custom object includes fields for work_order_number, scheduled_date, assigned_technician, labor_hours, and service_type. The Case record links to Work_Order__c via a lookup relationship, allowing each service ticket to associate multiple work order records while maintaining referential integrity across the Salesforce schema.

Summit assets map to Salesforce Asset records. The Asset Name, serial number, install date, and status fields map directly to their Salesforce counterparts. The ContactId lookup links the asset to the relevant customer contact. Location information and Summit custom property fields that lack direct Salesforce equivalents are mapped to custom fields created on the Asset object using the __c naming convention.

Summit customer records map to Salesforce Accounts. The company name, address, industry classification, and phone number fields map directly to their corresponding Account fields. Parent-child company hierarchies defined in Summit translate using the ParentId lookup field in Salesforce, preserving the organizational structure. Multi-location customers receive separate Account records, each linked to a common parent Account to maintain the relationship hierarchy.

Summit contacts who are customers map to Salesforce Contacts linked to Accounts. Summit technicians and agents who create and own records map to Salesforce Users by email match. Unmatched technicians are flagged and assigned to a fallback owner until a Salesforce User record is created.

Ticket comments in Summit become Salesforce CaseComments with the original body text, author name, and timestamp fully preserved. Internal-only notes that were restricted in Summit migrate as private CaseComments that remain visible only to the record owner and system administrators. Email thread content associated with tickets becomes EmailMessage records that attach directly to the corresponding Case, maintaining the full communication history within Salesforce.

Files attached to Summit tickets and work orders re-upload to Salesforce Files via ContentVersion. Each file gets a ContentDocumentLink connecting it to the corresponding Case or Work_Order__c record. Files over 25MB are flagged for chunked upload or alternative storage routing.

Summit's approval-gate history (approver, approval_date, status per gate) has no Salesforce equivalent in the standard data model. We create an Approval_History__c custom object with lookup to the Case, storing each approval step as a separate record with timestamp and outcome.

Every Summit custom property (text, number, date, pick-list) that has no direct Salesforce field equivalent is created as a custom field on the corresponding Salesforce object using the __c suffix. Pick-list custom properties in Summit require value-by-value mapping to Salesforce pick-list options.

Summit ticket categories map to Salesforce Case Record Types. Each Record Type gets its own page layout and Status pick-list values scoped to that type. This prevents a general service ticket and a billing dispute ticket from sharing the same stage pipeline.

Summit's SLA field (response time, resolution time targets) has no Salesforce standard equivalent. We migrate the SLA tier name and target hours into a custom SLA__c pick-list field. Salesforce Omni-Supervisor or a Flow calculates SLA breach triggers using these values post-migration.

Summit locations linked to customers are merged into the Account's standard billing and shipping addresses, supplemented by a custom Location__c custom object for accounts with multiple sites. Each distinct service location receives its own Location__c record containing site_type, square_footage, and operating_hours fields, all linked back to the parent Account through a lookup relationship.