Migrate from Pure Chart to HighLevel

Pure Chart custom properties require manual custom field creation in HighLevel before migration

Pure Chart stores proprietary charting metrics and custom data properties per contact with no fixed schema — field names, types, and count vary by account configuration. HighLevel custom fields must be created before data lands. FlitStack AI generates a custom field creation plan from Pure Chart's property inventory, but HighLevel's UI or API requires each field to be explicitly defined with a name, type, and (for picklists) option values. If your Pure Chart account has more than 50 distinct custom property names, the custom field setup phase extends the planning timeline and requires your HighLevel admin to approve the field list before migration validation runs.

HighLevel workflows and automations do not exist in Pure Chart — nothing migrates automatically

Pure Chart does not have a native workflow or automation engine. Any automation logic that existed in Pure Chart is embedded in third-party integrations (Zapier, Make, etc.) or manual processes — none of these are stored within Pure Chart's data model. HighLevel's Workflow builder creates trigger-action sequences from scratch. FlitStack AI does not migrate automations because there are none to migrate. Your team will need to document existing automation logic from Pure Chart integrations and rebuild those sequences in HighLevel's Workflow builder. We provide a workflow audit template to help capture the rebuild requirements.

Company-to-Contact relationship mapping requires a pre-migration deduplication pass

Pure Chart stores company data as contact properties (company name, domain) rather than a distinct company record. Multiple contacts sharing the same company name in Pure Chart may represent the same account but appear as separate entries with slight name variations (e.g., 'Acme Corp' vs 'Acme Corporation'). HighLevel's Companies object enforces one-record-per-account logic. FlitStack AI runs a company deduplication pass before creating Company records — matching by domain first, then fuzzy name matching on company strings. Contacts without a resolvable company link are attached to a default 'Unassigned' company record. This deduplication step adds 4–8 hours to the migration planning phase.

HighLevel API rate limits may extend migration clock time for large record sets

HighLevel API v2.0 permits 200,000 requests per day and 100 requests per 10 seconds per sub-account on standard plans. Pure Chart migrations exceeding 50,000 contacts with multiple custom fields per record generate API request volumes that approach or exceed these limits. FlitStack AI uses batch operations where possible (up to 200 records per request) to minimize total API calls. For record sets above 100,000, migration clock time may extend from 24 hours to 72 hours to respect rate limit throttling. Enterprise HighLevel plans with increased API limits are available and can reduce migration duration.

Original Pure Chart create dates cannot override HighLevel's system-created timestamp

HighLevel's Contact record schema includes a read-only Created At field that is set when the record is created via API. Pure Chart's original create dates are preserved in a custom datetime field (Original_Create_Date__c) rather than the system timestamp. Reports and filters built on HighLevel's native Created At field will show the migration date, not the Pure Chart creation date. Workflow triggers based on 'Contact Created' in HighLevel will fire on migration day, not on the original Pure Chart creation date. Segments and filters that depend on historical create dates need to reference the Original_Create_Date__c custom field.