Migrate from LeadSimple to HighLevel

LeadSimple bulk export omits notes and activity history — API extraction required separately

LeadSimple's bulk export (accessible from the Leads page Export button) produces an XLS file containing contact fields, pipeline data, and property details — but it does not include notes, call logs, email threads, or text histories. Those records live inside LeadSimple's UI and must be pulled via API. FlitStack AI performs a separate activity-history extraction pass using LeadSimple's API endpoints, converting each record into a HighLevel Task with original timestamp, owner, and type preserved. If your LeadSimple plan or API configuration restricts access to activity data, we disclose that limitation in the scoping phase and document what can and cannot be extracted before migration commits.

LeadSimple Processes (workflow automations) have no migration path — they must be rebuilt

LeadSimple's Process engine stores conditional rules, stage-change triggers, auto-follow-up sequences, renewal alerts, and delinquency workflows as internal automation definitions that do not export in a machine-readable format. There is no equivalent in HighLevel — LeadSimple Processes do not map to HighLevel Workflows because the trigger models differ fundamentally. LeadSimple's processes fire based on stage transitions and property events; HighLevel Workflows are event-driven with triggers like 'Contact Created' or 'Tag Applied'. FlitStack AI documents every LeadSimple Process with screenshots and rule descriptions, delivering that documentation as a rebuild reference for your HighLevel admin. The rebuild itself is a separate engagement and is not included in the standard migration scope.

Property and unit records require custom object creation in HighLevel before data can land

LeadSimple's native Property and Unit objects have no direct HighLevel equivalent — HighLevel does not ship with a property or unit management module. Before any property data can migrate, a HighLevel admin must create a Property__c custom object and a related Unit__c custom object with the appropriate fields (address, type, occupancy, annual contract value, cost for properties; unit number, occupancy, rent for units). The Unit__c object requires a lookup relationship back to Property__c. We deliver a custom object schema specification before the migration runs, and your HighLevel admin creates the objects. If this step is not completed before data lands, property and unit records cannot be written.

HighLevel custom field scope is fixed at creation — contact vs. opportunity cannot be switched

HighLevel distinguishes between Contact custom fields (attached to the person record) and Opportunity custom fields (attached to the deal record), and this scope is locked once the field is created. If you create a field as a Contact field and later realize you need it on the Opportunity, the field must be recreated. During LeadSimple migration planning, we identify every custom field that needs to migrate and classify it by intended use in HighLevel before creating the fields. For fields that apply to both Contact and Opportunity (e.g., Annual_Contract_Value), we create them on both objects to avoid scope errors.

Tag list migration requires value-by-value registry creation in HighLevel

LeadSimple tag lists are flat comma-separated strings in the export — a contact can have any number of tags with no enforced vocabulary. HighLevel's tag system is an organization-wide registry: tags must exist in HighLevel before they can be applied to a record. If a LeadSimple contact carries tags that do not yet exist in your HighLevel instance, we create each tag during migration. Large tag vocabularies (hundreds of unique tags) require more migration time because each unique tag must be registered before assignment. We report the unique tag count during scoping so you can anticipate this step.