Migrate from KulaHub to HighLevel

KulaHub stores all business entities as flat Contact records with no separate Company object. We evaluate each KulaHub contact for Account creation: contacts with a company name field, multiple contacts sharing the same company domain, or a business-type tag are candidates for Account creation in GoHighLevel with the contact linked via AccountId. Contacts without a clear business affiliation load as standalone GoHighLevel Contacts. The original KulaHub contact ID is preserved in a custom field kulahub_id__c for reconciliation.

KulaHub logs telephone calls, emails, and system events per contact as chronological activities. We export the full activity history as a time-series ordered by timestamp, then load it into GoHighLevel's contact activity timeline as Task records (for calls and generic activities) and Event records (for meetings). ActivityDate on each record preserves the original KulaHub timestamp to maintain chronological ordering in GoHighLevel's timeline view.

KulaHub stores email campaign history, templates, and tracking data (opens, clicks, unsubscribes) per contact. We extract campaign membership as GoHighLevel contact tags (campaign_name) and store campaign-level summary data (send date, open rate, click rate) in custom fields on each contact record. GoHighLevel's native email campaign builder rebuilds future campaigns; we do not migrate email templates as reusable objects but preserve the campaign history as contact data.

KulaHub links document blobs to contact records via a foreign-key relationship. We extract each document and its associated contact, then upload the file to GoHighLevel as a Contact file attachment. File names and any document notes migrate as metadata. Large document volumes require batch processing during the migration window.

KulaHub tasks are assigned to specific users and linked to contacts. We map tasks 1:1 into GoHighLevel Tasks attached to the corresponding Contact record. Task status, priority, due date, and assigned user migrate. Owner assignment resolves by matching KulaHub user email against the GoHighLevel user directory created during the User mapping phase.

KulaHub users appear in activity logs and task assignments. We export the full KulaHub user list first so owner-ID mapping is resolved before any records referencing users are loaded into GoHighLevel. The customer's GoHighLevel admin provisions users before migration day; we match by email and surface any KulaHub owner without a GoHighLevel counterpart in a reconciliation report.

KulaHub captures website enquiries via forms linked to contacts. The form-field schema is not publicly documented, which is a KulaHub platform-level gap. We request a sample export of form-submission data during discovery to build the field mapping. Any unmapped fields hold in a staging table and are presented to the customer for manual mapping before the production run, then load as GoHighLevel contact custom fields or as JSON-encoded data in a notes field.

KulaHub does not expose a separate Company or Account object; all business entities are stored as Contacts. Any company-level data embedded in KulaHub contact records (company name, website, industry, employee count fields) is extracted and used to create GoHighLevel Account records. The corresponding Contact records are linked to the Account via AccountId. If no company data exists in KulaHub, no Account records are created and contacts load as standalone.

KulaHub has no Deals or Pipeline object; opportunity and deal-stage tracking does not exist as a distinct data type. If the customer has been tracking deal-like data in custom KulaHub contact fields or notes, we evaluate whether to create GoHighLevel Opportunities and a corresponding pipeline. Pipeline stages are configured in GoHighLevel before Opportunity records load. If no deal data exists, this object is excluded from migration scope.

KulaHub stores email unsubscribe states and GDPR preference flags per contact, but the data format is not publicly documented. We export preference flags as GoHighLevel contact custom fields (kulahub_email_opt_in__c, kulahub_gdpr_consent__c) so the destination system can respect existing suppression lists. HasOptedOutOfEmail is set to true for any contact flagged as unsubscribed in KulaHub to ensure immediate compliance at go-live.