Migrate from Service Suite FSM to HighLevel

Work orders have no native HighLevel equivalent — custom object or hybrid mapping required

Service Suite FSM's work order is the operational centrepiece of the platform, holding job description, status, priority, scheduled date, assigned technician, site address, and line items on a single record. HighLevel has no work order object — the closest native construct is an Opportunity tied to a pipeline. We handle this by mapping work orders to Opportunities with a set of custom fields for the FSM work order ID, FSM status, priority, scheduled start and end dates, assigned technician (resolved by email to a HighLevel user), and site address. Line items (parts and labour) map to a separate custom Work Order Line Item object with a lookup to the Opportunity. Before migration, you confirm the custom field set and Opportunity pipeline stage mapping so the schema is ready when data lands.

FSM automations — scheduling rules, dispatch triggers, and service agreement workflows — do not migrate

Service Suite FSM uses scheduling rules, dispatch logic, and service agreement renewal triggers to automate field operations. These are configuration-level automations that live in the FSM platform and have no HighLevel equivalent at a structural level. HighLevel's Workflows builder handles marketing and sales automation through triggers and actions, but the FSM dispatch-and-scheduling logic requires a different design approach. We export the FSM workflow definitions as a structured document so your HighLevel admin or implementation partner has a rebuild reference. The scheduling board, route assignments, and dispatch rules must be recreated in HighLevel using Calendar bookings, workflow triggers, and (optionally) the HighLevel API for custom dispatch logic.

QuickBooks integration does not migrate — financial and payment data must be reconnected

Service Suite FSM includes native QuickBooks integration for syncing invoices, payments, customers, and products. HighLevel has no native QuickBooks connector. During migration, all FSM invoice records, payment history, and QuickBooks customer IDs are preserved as custom fields on the relevant Opportunities and Contacts, but the live integration cannot be transferred. After migration, you must reconnect QuickBooks through a third-party integration tool (such as a Zapier connection, a native HighLevel payment workflow, or a custom API integration) or accept that invoicing runs separately from HighLevel. This is a material change for teams relying on FSM's accounting sync.

Address duplication across FSM work orders and customer records requires consolidation

Service Suite FSM stores address data on both the customer record and the work order record, meaning the same service address can appear in two places within one FSM account. HighLevel separates Contact address from Company address, and Opportunities carry address data only through custom fields. We deduplicate addresses during mapping by designating one canonical address per customer-contact pair and storing the work order site address as a custom field on the Opportunity. If your FSM has conflicting addresses between the two records (a common data-quality issue in FSM setups), we surface the discrepancy before migration and apply your chosen resolution rule.

FSM multi-location and franchise structures map to HighLevel sub-accounts — schema redesign needed

Service Suite FSM supports multi-location setups where each franchise or branch operates as a separate entity with its own customers, technicians, and work orders. HighLevel's multi-account model uses sub-accounts (available on the Unlimited and Agency Pro plans) to isolate data by client or location. If your FSM account holds multiple franchise locations, we map each to a separate HighLevel sub-account. This requires pre-migration planning to define the sub-account structure, assign FSM locations to sub-accounts, and configure user access per sub-account. The migration is scoped per sub-account, and inter-location reporting requires cross-sub-account queries or a separate analytics layer.