Migrate from Comarch Field Service Management to HighLevel

Work-order-as-opportunity decomposition causes a structural flattening of Comarch's service hierarchy

Comarch FSM models service records as formal Work Orders with line items, parts, SLA definitions, and sub-tasks in a hierarchical structure. HighLevel has no native Work Order object — the closest analogue is an Opportunity with Tasks attached. When FlitStack decomposes a Comarch Work Order into a HighLevel Opportunity plus Tasks, the SLA response and resolution windows lose their native enforcement mechanism. We preserve the SLA data in custom fields (sla_response_time__c, sla_resolution_time__c, sla_priority__c), but SLA breach alerts require rebuilding in HighLevel's Workflow Builder. This is a fundamental model gap — teams that rely on Comarch's SLA enforcement must account for manual SLA tracking in HighLevel after migration.

Asset records must be represented as contacts with custom fields — no native equipment management in HighLevel

Comarch FSM treats Assets (equipment, devices, installed products) as first-class objects with fields for serial numbers, manufacturers, installation locations, maintenance histories, and parent-child hierarchies. HighLevel has no Asset object. FlitStack maps Comarch Assets to HighLevel Contact records tagged with the asset name, storing serial numbers, manufacturer, and model as custom fields on the contact. Parent-child asset hierarchies collapse to a flat contact structure with a custom parent-asset lookup. The maintenance history and IoT sensor data from Comarch cannot be represented natively in HighLevel — sensor readings and predictive maintenance alerts are lost unless a custom integration or third-party IoT tool is built.

HighLevel's API rate limits on sub-account plans cap bulk migration throughput

HighLevel's API enforces rate limits of 200,000 requests per day per sub-account at the base tier, with a burst limit of 100 requests per 10 seconds. Comarch FSM deployments with large volumes of Work Orders, Assets, and technician records can exceed this throughput ceiling during a migration cutover window. FlitStack mitigates this by using HighLevel's bulk-import CSV pipeline for Contacts and Companies, which bypasses per-record API calls, and by applying a throttled loop for Opportunities where each record requires individual API calls. Migration runs that exceed the daily rate limit are paused and resumed on the next 24-hour window — this can extend the cutover timeline for large datasets.

Comarch FSM workflows, SLA rules, and scheduling logic cannot be migrated and require complete rebuild in HighLevel

Comarch FSM workflows define automated escalation paths, SLA breach notifications, technician dispatch triggers, and process-routing rules. HighLevel's Workflow Builder implements automations through a trigger-action model with conditions and filters. These are architecturally incompatible — there is no export format from Comarch that maps to HighLevel's automation schema. Every Comarch workflow, SLA rule, escalation path, and scheduling constraint must be recreated from scratch in HighLevel's Workflow Builder. FlitStack provides a structured export of Comarch workflow definitions (step-by-step rule logic, trigger conditions, and action outcomes) as a reference document for your HighLevel admin to rebuild from. This is disclosed upfront as a limitation of every FSM-to-CRM migration.

Comarch multi-site and multi-region configurations map to flat Company records with address sprawl

Enterprise Comarch FSM customers often manage hundreds of service sites under a single customer account, each with its own address, access instructions, and asset inventory. HighLevel's Company object stores one primary address. Multi-site data from Comarch maps to multiple address custom fields on the primary Company record (site_name__c, site_address__c, site_latitude__c, site_longitude__c) plus tags for site identification. For Comarch deployments with more than 10 service sites per customer, this flattening can make the HighLevel Company record large and require technicians to reference a separate site-lookup sheet during field visits. We flag multi-site customers before migration and discuss a tagging strategy that allows filtering by site within HighLevel's contact/company list view.