Migrate from Civicrm to HighLevel

CiviCRM Individual contacts map to GoHighLevel Contact records. We preserve first name, last name, email, phone, address, and any single-record custom fields via the Contact custom field system. The dedupe key is email address. Individual contact subtypes from CiviCRM are preserved as a custom field civicrm_contact_type__c.

CiviCRM Households represent a group of individuals (e.g., a family) with a household name and no individual first/last name. GoHighLevel has no native Household concept. We offer two migration strategies: map Households to GoHighLevel Contacts using the household name as the contact name, or create a Household Custom Object with a one-to-many association to individual Contacts. The customer selects the strategy during scoping based on whether household-level reporting is required.

CiviCRM Organizations map to GoHighLevel Contacts with the organization name as the contact name and the Company field populated. For organizations that also appear as individual contacts in CiviCRM (e.g., an employer on a relationship), we resolve the Contact-to-Company association using the CiviCRM current_employer relationship. The GoHighLevel Company record serves as the grouping mechanism.

CiviCRM Activities (calls, emails, meetings, tasks, notes) map to GoHighLevel Activity records linked to the Contact. Activity type, subject, date, details, and assignee transfer directly. CiviCRM Activities that represent pipeline-adjacent events (e.g., proposal sent, negotiation started) may be mapped to GoHighLevel Opportunities with a note rather than a standalone Activity, depending on the customer's business model. We preserve the full activity timeline for audit.

CiviCRM Groups map to GoHighLevel Tags on Contact records. Static Groups (manually maintained membership) become GoHighLevel Tags that are applied to the relevant Contact records during migration. Dynamic (smart) Groups in CiviCRM cannot be reproduced without re-running the underlying query logic; we document the criteria for each smart group so the customer's admin can rebuild them as GoHighLevel Smart Lists or Workflow filters post-migration.

CiviCRM Contributions (donations, payments, event fees) have no native GoHighLevel equivalent. We create a Contribution Custom Object with fields for amount, currency, financial_type, receive_date, payment_instrument, and status. The Custom Object links to the donor Contact via a many-to-one association. Price-set line items from CiviCRM contributions become separate Custom Object records (e.g., DonationLineItem) associated with the parent Contribution. This is one of the most significant schema decisions during scoping.

CiviCRM Memberships (type, status, start_date, end_date, source, renewal date) map to a Membership Custom Object in GoHighLevel linked to the Contact. Membership Price Sets introduce tier complexity that must be flattened into a single membership_type field or a related MembershipTier Custom Object with a lookup to the parent Membership. We preserve the membership_status_calculation for audit.

CiviCRM Events map to GoHighLevel Events (for appointment-style events with calendars) or a Custom Object (for conference-style events with registration tracking). Event type, title, start_date, end_date, and location transfer directly. Price sets and participant roles introduce complexity similar to Contributions and require a participant Custom Object. We assess event complexity during scoping to determine the right approach.

CiviCase records do not have a direct GoHighLevel equivalent. We create a Case Custom Object with fields for case_type, status, start_date, and client_contact. Each CiviCase activity chain (activities attached to the case) migrates as a Note on the Case record with a timestamp reference to preserve the timeline. Case statuses are per-case-type in CiviCRM, so we enumerate every active case_type during scoping and map each status value individually to the GoHighLevel Case status picklist.

CiviCRM Relationships (household member, employee-employer, spousal, case coordinator) connect two Contacts with a relationship type. GoHighLevel has no native relationship object. We preserve the relationship network by creating custom fields on each Contact (e.g., employer_contact_id__c for employee-employer) or by creating a Relationship Custom Object that links two Contact records by ID with a relationship_type field. The bidirectional nature of some CiviCRM relationship types is preserved where GoHighLevel associations support it.

CiviCRM Tags are flat labels attached to any entity. They map directly to GoHighLevel Tags on Contact records. Multi-entity tagging (tags applied to Contacts, Activities, and other entities) requires separate tag application on each entity type during migration. Tags used for donor segmentation or membership tier are preserved as tags on the relevant Contact or Custom Object record.

CiviCRM multi-record Custom_ tables (e.g., Custom_donor_history, Custom_volunteer_shifts) have no GoHighLevel native equivalent. We create Custom Objects for each multi-record custom table, preserving the parent lookup to the Contact record and all field data. Single-record custom fields on Contacts migrate as GoHighLevel Contact custom fields. ECK (Entity Construction Kit) entities are handled as Custom Objects with their user-defined properties mapped to typed fields. We query the custom group count during scoping; sites with more than approximately 20 custom groups require entity-by-entity exports to avoid MySQL join limits.