Migrate from Crust CRM to HighLevel

Crust CRM Contact records map to GoHighLevel Contact. Standard fields (name, email, phone, address) migrate directly. The Crust lifecycle stage or lead status property is preserved as a GoHighLevel custom Contact field so the original buyer journey stage is available for reporting. We use email as the dedupe key and skip records that already exist in GoHighLevel to avoid duplicate contacts on import.

Crust CRM Company records map to GoHighLevel Company. The company name becomes the Company name field, and domain from Crust maps to the Website field. We create Company records before Contact import so that the company-contact relationship is satisfied at the moment of Contact insert. Deduplication runs against existing Company records using company name as the match key.

Crust CRM Deal records map to GoHighLevel Opportunities. The Deal amount maps to Opportunity Value, close date maps to Close Date, and the Crust pipeline-stage pair maps to a specific GoHighLevel Pipeline and Stage that we configure before migration. We resolve the owning user by email match against GoHighLevel Users.

Crust CRM pipelines and their stage names are organization-specific. We collect the full pipeline-stage map during discovery and create equivalent GoHighLevel Pipelines with matching stage names before any Deal records are imported. Stage probability percentages from Crust are stored as notes for the customer to configure in GoHighLevel's stage settings.

Where Crust CRM uses a separate Lead object distinct from Contact, we evaluate the Lead's last activity date and status to determine migration destination. Active Leads with recent engagement become GoHighLevel Contacts tagged with the original Lead source and with the lifecycle stage property set to lead. Stale or unqualified Leads are tagged and placed in a separate pipeline stage for re-engagement rather than imported as dead records.

Crust CRM activity records linked to Contacts or Deals migrate to GoHighLevel Activity records (calls, emails, meetings, notes). We preserve the parent record linkage by resolving the Contact or Opportunity reference at migration time. Activity timestamps are preserved to maintain the chronological timeline inside GoHighLevel. Activity type is mapped to the GoHighLevel Activity type enum.

Crust CRM owner assignments on Contacts, Companies, and Deals are resolved by matching the owner email to an existing GoHighLevel User. Any Crust owner without a matching GoHighLevel User is flagged in a reconciliation report for the customer to provision before record import resumes. Orphaned assignments are set to a default user during migration and noted for post-migration correction.

Crust CRM attachments stored per-record are exported individually with their filename and associated record ID preserved. They are re-attached to the corresponding GoHighLevel Contact or Opportunity using the GoHighLevel file upload API. Attachment metadata (file size, type, upload date) is preserved as a custom field on the file record.

Crust CRM's configurable module architecture means every organization may have unique custom objects. We run a pre-migration schema audit to enumerate all Crust custom objects, their field types, and any inter-module dependencies. Each custom object maps to a GoHighLevel Custom Object with equivalent field types. GoHighLevel limits custom objects to 10 per sub-account; we verify the count against this ceiling during scoping and flag any objects that exceed it for customer decision on archiving or selective migration.

Crust CRM tags migrate as GoHighLevel Tags. Tags used for lead classification or pipeline routing are recreated as tags in GoHighLevel and reapplied to the corresponding Contact or Opportunity records during migration. The customer chooses whether tags that represent lifecycle stages should also set the GoHighLevel Contact lifecycle stage property or remain as standalone tags.

Crust CRM automated workflows cannot be exported as reusable code for GoHighLevel. We document every active Crust workflow with its trigger, conditions, branch logic, and actions in a written inventory delivered to the customer after migration. The customer's admin uses this inventory to rebuild equivalent GoHighLevel Workflows using GoHighLevel's trigger-action builder. We do not rebuild workflows as part of the migration scope.