Migrate from Field service software to Salesforce Sales Cloud

Source work orders map to Salesforce Cases (or a custom WorkOrder__c object if Service Cloud Field Service is not in use). RecordTypeId differentiates work order types (Installation, Repair, Maintenance) so stage pick-list values are scoped correctly per type. Original work order number preserved in Case Number or a custom Source_WO_Number__c field.

Source customers with their billing and service addresses map directly to Salesforce Accounts. Multi-location customers (source locations) collapse to one Account with multiple Shipping Addresses or associated Location custom objects. Parent-child company hierarchies map to Account.ParentId. This consolidation ensures that all service history, work orders, and contact information roll up under a single Account hierarchy, maintaining organizational structure while reducing data duplication across your CRM.

Primary contacts at each customer site map to Salesforce Contacts with AccountId pointing to the parent Account. Location-specific contact roles (Site Manager, Maintenance Tech) migrate as a custom Contact_Role__c pick-list or Salesforce Contact Roles. This approach preserves the relationship between each contact and their associated account, while the role designation ensures dispatchers and technicians can quickly identify the right point of contact when scheduling or performing service visits.

Equipment records with serial numbers, install dates, warranty terms, and status map to Salesforce Asset. Parent-child asset hierarchies (compressor unit → chiller → plant) map via Asset.ParentId lookup. Asset must be migrated after Account to satisfy AccountId foreign key requirement. This ordering ensures that every asset links to its parent account, maintaining the relationship between installed equipment and the customer location where it's deployed.

Source service territories with geographic boundaries map to Salesforce Territory (requires Territory Management enabled) or a custom Territory__c object with Latitude/Longitude and polygon boundary fields. Routing rules require Salesforce Maps or custom Flow logic post-migration. Geographic boundaries, service zones, and skill requirements associated with each territory are preserved as reference data so your admin can rebuild routing logic in Salesforce without starting from scratch.

Source technicians map to Salesforce Users by email resolution. Skills, certifications, and service territories attached to technicians migrate as custom fields on User (Skills__c, Certifications__c, Territory_Coverage__c). Unmatched technicians flagged for admin provisioning before migration runs. This ensures that your field workforce retains all relevant qualifications and coverage assignments in Salesforce, enabling skill-based routing and accurate scheduling after cutover.

Parts and labor lines on work orders map to Salesforce Case Line Items (Service Cloud) or a custom Work_Order_Line__c junction object. Each line links to the parent Work Order and the Product/Part used. This maintains the detailed cost breakdown for each service visit, preserving parts consumed, labor hours, and pricing information so your finance team can track service profitability and inventory consumption accurately.

Parts catalog and service products map to Salesforce Product2 with ProductCode and Description. Unit cost and list price require custom currency fields (Unit_Cost__c, List_Price__c) since Salesforce Product2 Cost field is not standard. PricebookEntries created to activate pricing. This setup enables accurate service quotes, work order invoicing, and inventory valuation within Salesforce, eliminating the need to reference external pricing spreadsheets during service delivery.

Historical service visits, inspections, and interventions map to Salesforce Tasks (for completed actions) and Events (for scheduled appointments). Original timestamps, technician owners, and parent Work Order links preserved. Inline photos and signature images re-uploaded as Salesforce Files. This preserves your complete service history with full audit trail, allowing dispatchers to review past visit details and technicians to access customer-specific notes directly within Salesforce.

Source custom objects (PM schedules, Inspection Templates, Warranty Claims) map 1:1 to Salesforce custom objects with __c suffix. N:N relationships in the source require Salesforce junction objects. FlitStack surfaces the custom object schema before migration to plan junction-object creation. This discovery phase ensures that complex relationships between custom entities are translated correctly, maintaining data integrity and enabling your team to continue using established service processes in Salesforce.

Work order attachments (photos, signed forms, PDFs) re-upload to Salesforce Files (ContentDocument/ContentVersion) linked to the parent Work Order Case. File size limits apply — Salesforce default 25MB per file. Inline images in notes downloaded and rehosted. All documentation associated with service visits becomes accessible within Salesforce, giving technicians and customer service representatives immediate access to work order supporting materials without switching between systems.

Source ERP or accounting integrations have no Salesforce CRM equivalent — they must be rebuilt post-migration via Salesforce Connect, MuleSoft, or an iPaaS tool. FlitStack documents the integration endpoints and data contracts as a handoff artifact for your integration team.

Automated scheduling rules, skill-based routing, and priority-based dispatch logic in the source do not migrate. They must be rebuilt using Salesforce Flow, OmniStudio, or the Field Service managed package. FlitStack exports the source rule definitions as a configuration reference document.

Report definitions and dashboards do not migrate — the underlying data does, but the report structure requires rebuilding in Salesforce Reports & Dashboards. FlitStack preserves the source report field list as a rebuild checklist. This includes all calculated fields, filters, groupings, and chart configurations so your analytics team can replicate existing reports in Salesforce without reverse-engineering the original design from scratch.

Source user roles and permission levels have no Salesforce equivalent at migration time — Salesforce profiles and permission sets are destination-side schema configuration. FlitStack maps source user-role names to a permission-set plan for your Salesforce admin. The mapping document identifies which source permissions (dispatcher, technician, admin, manager) correspond to which Salesforce profiles and permission sets, ensuring your team retains appropriate access levels immediately after go-live.

Multi-site customers with separate locations map to one Salesforce Account with multiple Shipping Addresses or Salesforce's Associated Location object (requires Field Service). Geographic coordinates preserved in custom Latitude__c and Longitude__c fields for routing. This maintains geographic context for each service site, enabling accurate distance calculations, territory-based assignment, and mobile routing within Salesforce or third-party map integrations post-migration.