Migrate from Comet Suite to HighLevel

HighLevel has no native work-order or job object — Jobs must become a custom object

Comet Suite Jobs (work orders) are a first-class object with status, crews, sites, and line items. HighLevel does not have a native job or work-order object — Opportunities are sales-pipeline entities, not operational job records. We resolve this by creating a Job__c custom object in HighLevel that mirrors Comet Suite's Job schema: job number, status, type, site, assigned technician, scheduled date, and total. If your team uses Jobs primarily for pipeline tracking rather than field operations, we can alternatively map Jobs to Opportunities with a custom job-type field added to each pipeline. Your admin chooses the approach before migration runs, and the choice affects pipeline configuration in HighLevel.

Tags are flat in HighLevel — hierarchical Comet Suite categorizations collapse

Comet Suite may allow hierarchical or multi-value tag structures on Jobs and Clients for filtering and reporting. HighLevel tags are a flat, single-value list on each record — a Contact or Job__c record has one tag per category, not a nested tree. We transfer all tag values verbatim, but if your Comet Suite setup relies on hierarchical tag logic (e.g., Region > City > District), that structure collapses into a single concatenated tag string in HighLevel. Your team should audit the resulting flat tag list post-migration and consider rebuilding filtering logic with HighLevel's Smart Lists and custom fields instead.

HighLevel's API rate limit (200k/day per sub-account) constrains bulk migration speed

HighLevel's REST API caps sub-account API usage at 200,000 requests per day with a burst limit of 100 requests per 10 seconds. For migrations exceeding 50,000 records with associated activities and custom fields, this cap requires staged bulk processing rather than real-time API writes. We handle rate-limit backoff automatically and queue records for retry, but the overall migration window extends proportionally for large datasets. We recommend scheduling migrations during off-peak hours to maximize available API quota, and we can request a temporary limit increase through HighLevel's enterprise support if your dataset exceeds 200,000 records.

Comet Suite custom fields on Sites require a location mapping strategy

Comet Suite Sites carry custom fields specific to each location (e.g., access codes, site contact name, parking instructions, equipment on-site). HighLevel Companies and Contacts have a fixed set of standard address fields but no native Site object. We map Site custom fields to a custom location object or append them as custom text fields on the associated HighLevel Company record. If a Client has multiple Sites, all Site custom fields land on the same Company record, which may require a multi-value custom field or a separate Site junction object your admin configures in HighLevel.

Comet Suite workflows and dispatch rules cannot be exported in a migration-ready format

Comet Suite automation rules (job-stage triggers, crew dispatch notifications, client email alerts) are proprietary workflow definitions that do not have a documented export API. HighLevel's Workflow Builder uses a trigger-action model that is architecturally different from Comet Suite's rule engine. We can provide a structured document listing every Comet Suite workflow rule with its trigger conditions and actions — this serves as a rebuild specification for your HighLevel admin. However, the migration carries no automation logic automatically. Plan for a separate workflow-rebuild phase after data migration completes, using HighLevel's Workflow Builder templates as the foundation.