Migrate from Swivl Tech to HighLevel

Swivl contacts (customer name, email, phone, address) migrate directly to HighLevel Contact records. Email address is the primary de-duplication key. Multiple contacts with the same email collapse to a single HighLevel Contact on upsert. The original Swivl contact ID is stored in a custom source_id field on the HighLevel Contact for traceability during reconciliation and delta-run de-duplication in subsequent migration passes.

Swivl company records (business name, industry, employee count, address) map to HighLevel Company records. Swivl's company-to-contact relationship migrates as a HighLevel Company-Contact association. Parent-company hierarchies, if used in Swivl, map to HighLevel's Company hierarchy. We also preserve the original Swivl company ID in a custom field to support delta-sync and post-migration audit trails.

Each Swivl Job migrates as a HighLevel Opportunity. Job name becomes Opportunity name. Swivl's job-status value (Scheduled, In Progress, Completed, etc.) is mapped to a corresponding HighLevel Pipeline Stage value by the migration plan. If Swivl uses multiple pipelines (e.g., Repair vs. Installation), each becomes a separate HighLevel Pipeline.

Swivl's fixed job-status vocabulary maps value-by-value to HighLevel Pipeline Stage pick-list values defined in your HighLevel pipeline. We deliver a status-to-stage mapping table as part of the migration plan. Stage-entered timestamps from Swivl are preserved as custom datetime fields on the HighLevel Opportunity.

Swivl job line items (service description, quantity, unit price, total) do not map to a native HighLevel Opportunity structure. We create a custom field on the HighLevel Opportunity (e.g., Job_Line_Items__c) and store line-item data as a JSON string or structured text. HighLevel's Products feature can be used to model individual line items as Opportunity Products if you configure a product catalog in HighLevel during setup.

Swivl stores service-address fields (street, city, state, ZIP) on the Job record. We map these to the Contact's address fields in HighLevel. We also apply a 'Service Location' tag to the Contact so HighLevel users can distinguish a customer's billing address from their job-site address without modifying the schema.

Swivl assigns technicians and crews to jobs. HighLevel does not have a native technician-assignment object on Opportunities. We resolve each Swivl technician email to a HighLevel User and store the assignment as a custom text field or tag on the Opportunity. For multi-technician jobs, we store the crew list as a comma-separated custom field.

Swivl invoices carry status, amount, and line items. HighLevel has no native invoice object at the base CRM level. We create a custom object (e.g., Invoice__c) in HighLevel or store invoice data as custom fields on the related Opportunity, preserving invoice number, total amount, and payment status. HighLevel Payments can be used to track settlement if enabled.

Swivl custom fields configured in the FSM setup migrate as HighLevel custom properties on the appropriate object (Contact or Opportunity). Swivl field types (text, number, date, pick-list) map to equivalent HighLevel field types. Pick-list values require value-by-value mapping if the destination property uses a choices field type in HighLevel.

Swivl file attachments (photos, signed forms, job documents) are downloaded and re-uploaded to the corresponding HighLevel Contact or Opportunity record as HighLevel Files. Original filenames and timestamps are preserved during the transfer process. File-size limits and format restrictions apply per HighLevel's upload constraints, and attachments exceeding those limits are flagged in the migration audit log for manual handling.

Swivl tags on contacts and jobs migrate directly as HighLevel tags. Multi-tag values from Swivl are split into individual HighLevel tags on upsert. Tags on contacts carry over to the HighLevel contact record; tags on jobs carry over to the Opportunity.

Swivl user records (name, email, role) are matched to HighLevel users by email. Unmatched users are flagged before migration — your team either invites them to HighLevel first or assigns records to a fallback owner. Role-based access in Swivl (Admin, Technician, Office Staff) does not map to HighLevel's permission model and must be reconfigured post-migration.