Migrate from GorillaDesk to HighLevel

GorillaDesk customers map directly to HighLevel contacts. The customer's name, email, phone, address, and created-at timestamp all have native equivalents in HighLevel's contact record. The gorilla_desk_id is stored as Source_ID__c for delta-run deduplication and traceability. Custom fields for customer type, lead source, and billing preferences are also migrated to preserve business context.

GorillaDesk customer records that include a business name map to HighLevel companies in addition to contacts. HighLevel's contact-company relationship supports the same primary-company-per-contact model. For residential customers without a company, only the contact record is created. If multiple contacts share the same business name, each contact links to the same company record to maintain relationship integrity.

GorillaDesk company records (business-name customers) map 1:1 to HighLevel companies. The company name, domain/website, industry, employee count, and address fields are all direct candidates. Parent-company hierarchies from GorillaDesk map to HighLevel's Parent_Company__c relationship field. Additional attributes such as annual revenue, company size classification, and primary contact are preserved as optional custom fields.

GorillaDesk job records are not exposed via the public API — only customer, company, user, and note endpoints are accessible. We request job data via bulk CSV export from GorillaDesk's admin UI where available, then map job records to either a HighLevel custom Service_Job__c object or to opportunity records, depending on whether the job represents a billable service (opportunity) or historical record (custom object). The mapping approach is decided during the sample migration phase.

GorillaDesk job statuses (e.g., Scheduled, En Route, In Progress, Completed, Cancelled) map to HighLevel pipeline stage names. Each GorillaDesk status value is mapped value-by-value to a corresponding HighLevel pipeline stage so the migration preserves the current-state status of every job at migration time.

GorillaDesk invoices and estimates are not available via API. We attempt a bulk export from GorillaDesk's admin UI and re-upload invoice PDFs as HighLevel contact attachments. Line-item invoice data (services, materials, quantities, prices) is stored in a custom field or custom object if the export is available. Invoice totals and status map to custom fields on the associated contact or opportunity.

GorillaDesk notes (customer-scoped) map directly to HighLevel notes. Each note's content, author, and created-at timestamp are preserved. HighLevel attaches notes to the corresponding contact record using the email-matched contact ID. Notes from GorillaDesk that reference specific job IDs are flagged for association with the reconstructed Service_Job__c record.

GorillaDesk users (technicians, dispatchers, admins) are resolved by email match against HighLevel team members. Unmatched users are flagged before migration — the team either creates the HighLevel user first or assigns records to a fallback team member. GorillaDesk role labels are stored as a custom field on the HighLevel user record for reporting continuity.

GorillaDesk service templates define pre-configured job types with line items and materials. These are not exposed via API. We extract service template names and structure from GorillaDesk's UI export and store them as tags or custom fields on migrated job records. Rebuilding the equivalent in HighLevel requires manual recreation of service templates as opportunities with pre-set custom field values and workflow triggers.

GorillaDesk GPS tracking and route optimization data is operational (not billing or contact data) and is not available via API. Historical route data, technician driving paths, and geofence records do not migrate. The operational capability must be re-evaluated in HighLevel's calendar and location context — HighLevel's appointment booking does not replace field-service route optimization.

GorillaDesk phone type classifications (mobile, office, home, etc.) stored as part of the customer record map to a custom pick-list field on the HighLevel contact. The phone number itself maps directly to the contact's phone or mobile field; the type label is preserved in the custom phone_type__c field.

GorillaDesk files attached to customer records (e.g., property photos, service reports, signed documents) are downloaded and re-uploaded as HighLevel contact attachments. File size limits are respected. Inline images embedded in notes are extracted and rehosted as separate attachments linked to the contact.

GorillaDesk VoIP call recordings, call logs, and SMS threads are stored within GorillaDesk's telephony module and are not accessible via the public API. We cannot migrate call history or SMS conversations. Teams should export this data directly from GorillaDesk before the migration window and re-upload to HighLevel's LC Phone module manually, or use HighLevel's built-in SMS/voice tools going forward.

GorillaDesk custom fields added at the customer level (beyond the standard name/email/phone/address set) are mapped to HighLevel contact custom fields. Each custom property requires a corresponding custom field created in HighLevel before migration. Field data types are preserved: text fields to text, pick-lists to pick-lists, date fields to date fields.

GorillaDesk's Sources tab — tracking where customers came from — maps to either a HighLevel contact custom field (lead_source__c) or a tag applied at migration time. Tags are preferred when GorillaDesk sources are unstructured or numerous, as HighLevel tags support bulk application and workflow triggers.