Migrate from ClinchPad to HighLevel

ClinchPad Lead records contain contact fields (name, email, phone, company, address) and deal fields (deal value, expected close date, stage) in a single record. We split at migration time — contact fields map to GoHighLevel Contact properties (firstName, lastName, email, phone, address, companyName). Any ClinchPad custom text fields on the lead migrate as GoHighLevel Contact custom fields, which we pre-create in the destination account during schema setup.

The deal portion of each ClinchPad Lead splits into a GoHighLevel Opportunity. We create the Opportunity, link it to the Contact via the primaryContactId relationship, set the Opportunity name to the Contact name plus a deal identifier, and populate value, expectedCloseDate, and pipelineStageId from the ClinchPad deal fields. Contacts without an associated deal in ClinchPad create Contact records with no Opportunity — they enter GoHighLevel's pipeline as raw leads for the admin to qualify.

ClinchPad Kanban stages (e.g., New, Contacted, Proposal, Won, Lost) map to GoHighLevel Pipeline stages in matching sequence order. We pre-create the pipeline in GoHighLevel during schema setup with stage names and probabilities aligned to the source. Probability values from ClinchPad migrate as stage probability percentages in GoHighLevel, with any custom stage colors preserved in the written handoff documentation.

ClinchPad notes attached to a Lead or Deal migrate as GoHighLevel Contact Notes or Opportunity Notes. We preserve note body text and timestamp. If ClinchPad exposes author information in the export, we include it as a note body prefix. Note volume per record in ClinchPad is typically low given the platform's small-team focus, so this mapping is straightforward but required for audit continuity.

ClinchPad tags on Leads migrate as GoHighLevel Tags on Contact records. GoHighLevel supports native tagging on contacts, so no custom field creation is required. Tag names carry over verbatim. If the customer used tags as a segmentation proxy for campaigns, we flag this during scoping so the GoHighLevel admin can consider building a GoHighLevel Campaign or List structure as a replacement.

ClinchPad users map to GoHighLevel Users by email address. ClinchPad's flat user model has no granular role permissions, so the mapping is straightforward — each ClinchPad user becomes a GoHighLevel User with a basic CRM role. Any ClinchPad user referenced as a deal owner or note author without a corresponding GoHighLevel account enters a reconciliation queue for the admin to provision before record import.

ClinchPad stores attachments outside the lead record with external references (Wufoo form downloads, Dropbox links, direct upload URLs). The CSV export does not include file bodies — only filenames and attachment URLs. We request customer-provided access to the source attachment store during scoping. We download file bodies, map them to the corresponding GoHighLevel Contact or Opportunity using the export filename, and upload via the GoHighLevel API. Filename conflicts are handled with deduplication suffixes.

ClinchPad stores company name as a text field on the Lead record, not as a separate Company object. We map this to the companyName field on GoHighLevel Contact. If the customer requires a separate Company or Account object in GoHighLevel for multi-contact company modeling, we flag this during scoping and the admin can decide whether to create Company records after migration based on the imported Contact company data.