Migrate from Vonigo to HighLevel

Vonigo Clients map directly to HighLevel Contacts. Name, email, phone, address, and contact preferences transfer as standard fields. Original Vonigo client ID is stored as a custom field (vonigo_client_id) for traceability and delta-run de-duplication. Franchise assignment is preserved as a custom field.

Vonigo stores multiple phone numbers per client. HighLevel stores one phone and one mobile on Contact. We split by phone type — primary phone maps to Phone, mobile or secondary maps to Mobile. Any additional phone numbers beyond two are appended to a custom field (Additional_Phones__c) as semicolon-delimited text.

Vonigo client email maps directly to HighLevel Contact.email. Email serves as the primary deduplication key during migration, preventing duplicate contact creation when the same client appears multiple times across locations or franchises. Records with null, placeholder, or invalid email formats are flagged in a pre-migration review report for your team to correct before the full migration run begins. This ensures clean contact data in HighLevel from the initial load.

Vonigo Locations representing service addresses, branches, or franchise sites map directly to HighLevel Companies. The location name, full street address, city, state, and postal code transfer as standard Company fields. Any location-specific custom fields — such as territory zone, branch manager, or regional classification — migrate as Company custom fields, preserving all contextual metadata associated with each service location.

Vonigo's franchise-level location hierarchy has no direct HighLevel equivalent. We record the franchise identifier as a custom pick-list field on Company (Franchise_ID__c) so reports can group locations by franchise. For agency-managed migrations, this can alternatively route to HighLevel sub-account assignment.

Vonigo Work Orders carry rich FSM data — status, service type, technician, schedule, line items, photos, signature — that HighLevel's Opportunity object does not natively represent. For standard work orders, we map to a HighLevel Opportunity with work order number as Name, amount from total price, and original status preserved in a custom field. For complex work orders with multiple line items, we use a Custom Object (Work_Order__c).

Vonigo FSM statuses (Pending, Confirmed, In Progress, Completed, Invoiced, Cancelled) have no direct HighLevel pipeline stage equivalent, as pipeline stages represent a sales cycle rather than a field-service lifecycle. Each Vonigo FSM status maps to a distinct custom pick-list value on a custom field (Work_Order_Status__c) on the target object. This preserves the complete FSM status history for operational reporting while keeping HighLevel pipeline stages available for tracking sales-cycle progression independently.

Each service line on a Vonigo Work Order (service type, quantity, unit price, total) migrates as a set of custom fields on the Work_Order__c custom object: Service_Type__c, Quantity__c, Unit_Price__c, Line_Total__c. Multi-line work orders may also use a related Custom Object (Service_Line__c) linked by a lookup relationship.

Vonigo Estimates map to a custom object (Estimate__c) because HighLevel has no native quoting or estimating feature. Estimate number, date, status (Draft, Sent, Approved, Declined), line items, and total amount transfer. If the Estimate converted to a Work Order, the Work Order ID is stored as a cross-reference custom field.

Vonigo Invoices migrate as a custom object (Invoice__c) since HighLevel has no native invoicing. Invoice number, date, due date, line items, subtotal, tax, total amount, amount paid, and payment status (Paid, Partial, Unpaid) are preserved as custom fields. Payment records link to the Invoice via a lookup relationship.

Vonigo Payment records migrate as individual Payment__c custom objects linked to their parent Invoice__c via a lookup. Payment date, amount, method, and transaction reference transfer. HighLevel's own payment recording via invoices does not exist natively, so payment history is fully preserved in this custom object structure.

Vonigo technicians and franchise owners resolve to HighLevel Users by email match. Unmatched users are flagged before migration — your team either creates the HighLevel user first or assigns records to a fallback owner. No record lands without a resolved HighLevel owner. Vonigo internal IDs are stored for audit traceability.

Vonigo file attachments — photos, signatures, documents — on Work Orders and Locations are downloaded and re-uploaded to HighLevel Files attached to the target record. File name, type, and original upload timestamp are preserved. HighLevel's file size limits (25MB per file) apply; oversized files are flagged for manual handling.

Vonigo custom fields on Clients, Locations, and Work Orders migrate to HighLevel custom fields on the equivalent target object. Field data types are matched: text → text, number → number, date → date, pick-list → pick-list. Vonigo's custom field schema is documented in the migration plan so custom field creation in HighLevel can proceed in parallel.