Migrate from ContactDB to HighLevel

Each ContactDB contact record maps to a GoHighLevel Contact. Standard fields (first name, last name, email, phone, job title) map directly. The ContactDB export does not expose a unique record ID, so we use email as the dedupe key during GoHighLevel import. Records missing both email and phone are flagged in the pre-import validation report for the customer to resolve before the import pass because GoHighLevel requires at least one contact identifier.

ContactDB stores company name as a per-contact attribute, not a normalized company record. Multiple contacts sharing the same company name will appear with that company name repeated across rows. We extract all unique company names from the contact set, deduplicate by exact name match, and create one GoHighLevel Company per unique name. Each resulting Contact record receives a lookup link to its parent Company via the GoHighLevel Company Name matching field.

ContactDB firmographic columns (SICCODE, industry, company size, credit rating, country) have no direct GoHighLevel standard field equivalents. We create GoHighLevel custom fields under Settings > Custom Fields for the Contact object: sic_code__c, industry_category__c, company_size_range__c, and credit_rating__c. Each Contact record receives these values populated from the corresponding CSV column during import.

ContactDB segments by industry, profession, title, country, and software usage as filter criteria, but segment labels are not exported as standalone tag objects. We reconstruct segment membership by extracting the criteria values present in each contact record and writing them as a GoHighLevel multi-select custom field (e.g., original_segment__c). The customer confirms during scoping which segment categories are operationally meaningful to preserve.

GoHighLevel import requires at least one contact identifier (email or phone) and enforces format validation. ContactDB exports may contain malformed email addresses, placeholder values (e.g., info@), or missing phone numbers, particularly in records from markets with limited firmographic completeness. We run a pre-import validation pass that outputs a separate error CSV of records with invalid or missing identifiers, allowing the customer to clean or suppress those records before the GoHighLevel import.

ContactDB does not have a pipeline or deal-tracking model. GoHighLevel Pipelines and Stages are not migrated data but rather destination platform configuration. We set up the customer's initial GoHighLevel pipeline structure (e.g., Prospect, Qualified, Proposal, Closed Won) based on the stated sales process, with Stage names matching what the customer will use to route imported ContactDB leads into the pipeline.

ContactDB holds no deal or opportunity records. However, GoHighLevel Opportunities are commonly created post-migration for contacts that enter the pipeline. We can pre-seed Opportunity records linked to imported Contacts for any deal data the customer maintains in a separate spreadsheet, using the Opportunity Name, Stage, and Amount fields from GoHighLevel's standard Opportunity object. This is an optional add-on scope confirmed during discovery.

ContactDB does not expose a custom field schema. GoHighLevel supports Custom Objects from the Starter tier onward. If the customer has supplementary data (e.g., a separate product interest spreadsheet, account priority ratings, or renewal dates) that was derived from or enriched alongside the ContactDB purchase, we can model this as GoHighLevel Custom Object records linked to the migrated Contacts via a lookup relationship. We define the Custom Object schema (fields, field types, relationship field) during the schema design step.