Migrate from HighQ to HighLevel

HighQ iSheets are not native CRM records — schema translation requires a mapping plan per iSheet

HighQ iSheets are spreadsheet-like tables attached to Sites, not CRM contacts or companies. Each iSheet has its own column schema, and the same data pattern (for example, a list of client names and matter numbers) might appear across multiple iSheets in different Sites. FlitStack maps each iSheet to a HighLevel Custom Object, but the column-to-field translation must be planned individually — there is no automated field-matching across iSheets. You will need to review each iSheet mapping plan before migration runs so that column types and picklist values translate correctly into HighLevel custom fields.

HighQ Workflows do not translate to HighLevel Workflow Builder — rebuild required

HighQ automations are configured per Site using a rule-based Workflow engine with triggers, conditions, and actions. HighLevel's Workflow Builder uses a completely different event-driven model with different trigger types, action names, and flow-control logic. There is no automated migration path. FlitStack exports your HighQ workflow definitions as a structured JSON document listing trigger types, conditions, actions, and sequence. Your HighLevel admin uses this document as a rebuild reference. Workflows that depend on HighQ-specific events (such as a document approval completion) may need to be redesigned rather than directly translated.

File attachments in iSheets must be re-uploaded to HighLevel storage

HighQ iSheets support file attachments per row — documents uploaded directly to a cell in an iSheet. HighLevel Custom Objects store files as related HighLevel Files attached to the Custom Object record, not as inline cell attachments. FlitStack downloads all HighQ iSheet file attachments, re-uploads them to HighLevel, and links each file to the corresponding Custom Object record. If your HighQ account uses large file attachments (over HighLevel's 25MB per-file limit), those files are flagged before migration so you can decide whether to compress, split, or exclude them.

HighQ Site permissions do not map to HighLevel roles — documented for manual recreation

HighQ Site-level permission sets (Viewer, Contributor, Admin) control what internal team members and external client portal users can see and do within a Site. HighLevel's permission model uses team member roles (Admin, Manager, User) scoped to the entire sub-account, plus optional location-based access restrictions. There is no direct mapping between HighQ Site permissions and HighLevel role definitions. FlitStack documents your full HighQ permission structure (which users have which role on which Site) as a permissions matrix. Your HighLevel admin uses this matrix to configure roles and access in HighLevel before go-live.

HighLevel API rate limits may throttle large HighQ data extractions

HighLevel API 2.0 enforces a limit of 200,000 requests per day and 100 requests per 10 seconds per sub-account. HighQ data extractions involving multiple Sites, many iSheets, and file downloads can generate high API call volumes. FlitStack paces extraction using HighLevel's rate limit headers and handles 429 responses with automatic retry using exponential backoff. For migrations exceeding the daily request quota, extraction runs over multiple days with delta reconciliation at the end.