Migrate from Zuper to HighLevel

Zuper Customer splits into HighLevel Contact (person-level fields: name, email, phone, address) and HighLevel Company (business-level fields: company name, website, industry, employee count). The Zuper Customer ID is preserved as Source_System_ID__c on both for traceability. Primary service address in Zuper maps to Contact address fields; property-level address maps to Company address.

Zuper Customer records where the contact is a business entity (e.g., property management companies, commercial clients) map directly to HighLevel Companies. Business name, domain, industry, and custom fields carry over. Contacts are created separately for individual points of contact at that company.

Zuper Job maps to HighLevel Opportunity — the job name becomes the Opportunity name, job amount/estimate becomes the Opportunity value, and job status maps to a HighLevel pipeline stage (e.g., 'Scheduled' → 'Qualified', 'Completed' → 'Won', 'Cancelled' → 'Lost'). Zuper job priority (low/medium/high/urgent) migrates to a custom Opportunity field (Priority__c).

Zuper job line items (service tasks, parts, labor) translate to HighLevel Opportunity products or a set of custom fields on the Opportunity object (Service_Type__c, Line_Item_Description__c, Quantity__c, Unit_Price__c). We surface the full line-item list in a migration plan; you choose whether to use HighLevel Products or custom fields based on your quoting workflow.

Zuper Teams map to HighLevel Users. Team name becomes the HighLevel user display name; team member email addresses are matched against HighLevel user accounts. Unmatched team members are flagged — HighLevel accounts must be provisioned before migration so owner resolution completes. Sub-team structures in Zuper map to HighLevel user tags or a custom Team_Name__c field on the User record.

Zuper timesheet records (hours logged, date, technician, job reference) have no native HighLevel equivalent. We create a Time_Entry__c custom object with fields for Technician__c (lookup to User), Job__c (lookup to Opportunity), Hours_Worked__c, Date__c, and Billable__c. This preserves historical labor data for reporting even though HighLevel's standard workflow model handles time tracking differently.

Zuper stores GPS coordinates and property addresses per job. These migrate as custom latitude/longitude fields (Job_Latitude__c, Job_Longitude__c) and a full address field (Job_Property_Address__c) on the Opportunity record, allowing HighLevel users to reference service locations within the Opportunity context.

Zuper tracks job status transitions with timestamps (e.g., Created → Scheduled → In Progress → Completed). We preserve these as Opportunity-level custom datetime fields: Job_Created_Date__c, Job_Scheduled_Date__c, Job_Completed_Date__c, and a custom text field Job_Status_History__c storing the full state-change log as a pipe-delimited string for audit continuity and provides a clear audit trail for compliance.

Zuper's built-in quoting and proposal tools export as a Quote__c custom object in HighLevel with fields for Quote_Number__c, Amount__c, Status__c, Valid_Until__c, and an attached PDF stored in HighLevel's Files. Alternatively, HighLevel's Documents feature can host rebuilt proposals with e-signature.

Every Zuper custom field discovered during audit (text, number, dropdown, date, checkbox, etc.) is created in HighLevel under the matching object in Settings > Custom Fields. HighLevel locks the field type after creation — if Zuper stores a field as free text and you need it as a pick-list in HighLevel, that value mapping is documented in the migration plan before the full run. This ensures data integrity and reporting.

Zuper file attachments on Jobs or Customers (photos, signed forms, PDF invoices) re-upload to HighLevel Files and attach to the corresponding Opportunity (job-as-Opportunity) or Contact record. Files are re-hosted; original storage references are not preserved. File size limits (25MB per HighLevel file) are enforced and oversized files flagged before migration.

Zuper Workflow Builder automations (node-based triggers on job events, customer updates, form submissions) do not migrate. FlitStack exports Zuper workflow definitions as JSON reference documents, and your HighLevel admin rebuilds them using HighLevel's visual Workflow Builder. The trigger vocabulary differs: Zuper uses 'Job Created' and 'Customer Updated' events; HighLevel uses 'Contact Created', 'Opportunity Updated', and 'Form Submitted' triggers.