Migrate from Groundhogg to Salesforce Sales Cloud

Groundhogg Contacts map to either Salesforce Lead (for unqualified prospects) or Contact (for qualified buyers attached to an Account). We apply a split rule during scoping based on the customer's tagging taxonomy, contact scores, or lifecycle intent signals. If the customer uses Groundhogg primarily for sales-qualified contacts, all records map to Salesforce Contact with a custom field gh_original_status__c preserved for audit. Owner attribution is resolved by matching the Groundhogg WP user ID to the Salesforce User email before import.

Groundhogg Company records map to Salesforce Account. We use company name as the dedupe key and domain (if present) as the Website field. Account is inserted before any Contact import so the AccountId lookup is satisfied at Contact insert time. If the customer uses a custom company_id property, we map it to a custom Account field for cross-reference.

Groundhogg Deals map to Salesforce Opportunity. The dealstage property maps to Salesforce StageName and the pipeline assignment maps to a Salesforce Record Type and Sales Process configured before migration. Deal value, close date, and custom properties migrate directly. If the customer is on a Groundhogg plan below Pro, Deals may not exist or may be inconsistently populated; we audit the database during discovery to avoid partial migration.

Each Groundhogg Pipeline becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that whitelists stage values. Stage probability percentages migrate from Groundhogg to Salesforce StageProbability. If Groundhogg Pipeline visual layout was customized, we document the stage names and order in the Flow Audit for manual rebuild in Salesforce.

Groundhogg's flat tag taxonomy maps to Salesforce multi-select picklist on Contact (if fewer than 150 distinct tags) or a custom text field for larger tag sets. Tags carry no hierarchy in Groundhogg; if the customer relies on parent-child tag groupings, we document the taxonomy for manual regrouping in Salesforce.

Groundhogg custom properties on Contact and Company migrate to Salesforce custom fields of equivalent type. Text fields map to Text, date fields to Date, choice fields to Picklist or Multi-Select Picklist, and number fields to Number. We export the full Groundhogg custom field schema during discovery and pre-create destination fields before any data import to avoid type-mismatch rejections.

Groundhogg stores Owner references as WordPress user IDs. We export WP user email addresses and match against the Salesforce destination org's User table. Owners without a matching Salesforce User are placed in a reconciliation queue. The customer's admin provisions missing Users before migration resumes because OwnerId is required on Contact, Account, and Opportunity.

Groundhogg Contact-level notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent Contact or Account. Note body, timestamp, and author attribution (WP user email) are preserved. If the customer uses Groundhogg's rich-text note feature, HTML content converts to Salesforce's rich-text Note body.

Groundhogg email open events migrate to Salesforce Task records with Subject indicating 'Email Opened' and ActivityDate set to the original Groundhogg timestamp. The task is linked to the Contact via WhoId. Open events without a corresponding email send record are flagged during scoping.

Groundhogg link click events migrate to Salesforce Task with Subject 'Link Clicked' and a custom field gh_clicked_url__c carrying the URL. ActivityDate preserves the original timestamp. Click events are linked to the Contact record via WhoId and to the related Opportunity via WhatId if the click occurred on a tracked Opportunity email.

Groundhogg tag change events (applied or removed) migrate as Salesforce Task records with Subject 'Tag Updated' and a custom field gh_tag_action__c (Applied or Removed) plus gh_tag_name__c. This preserves the engagement signal without requiring Groundhogg tags to map directly to Salesforce picklist values, which would exceed field length for active tag sets.

Groundhogg Broadcast records (subject, send date, recipient count) map to Salesforce Campaign. Recipients are loaded as CampaignMember records linked to the corresponding Contact. We do not migrate broadcast email body content; the customer may reuse subject lines and send-date metadata to recreate the Campaign in Salesforce for historical reporting.

Groundhogg Flows cannot be exported as reusable automation templates. We export trigger type, step count, step names, and conditional logic summary as a written Flow Audit document. The customer's admin or a Salesforce partner uses this document to rebuild Flows in Salesforce Flow. Flows with fewer than ten steps may be candidates for Salesforce Flow's simple record-triggered automation; complex branching flows require a separate rebuild scope.

Groundhogg Tracks (Agency-tier visual funnels) do not migrate as discrete objects. We document the funnel name, stage count, stage names, and entry/exit criteria in the Flow Audit. Visual layout does not export; the admin rebuilds funnel logic as Salesforce Flow or as a sequence of Campaigns with automated status updates.

Groundhogg Deals on Pro and above tiers with a status of Won map directly to Salesforce Opportunity with Stage = Closed Won. Deals with Lost status map to Opportunity with Stage = Closed Lost and a custom field gh_loss_reason__c carrying the Groundhogg close reason. Open deals migrate with their current stage and probability preserved.