Migrate from FRONTU to HighLevel

Frontu Customer maps directly to HighLevel Contact. The customer's name splits into First Name and Last Name on the HighLevel Contact. Email, phone, and address fields map one-to-one. Notes and tags from Frontu become HighLevel Contact tags. Original customer ID preserved as Source_System_ID__c for traceability and delta-run de-duplication.

Frontu Company maps to HighLevel Company. Company name, domain/website, industry, employee count, and annual revenue translate directly. Frontu's parent-company hierarchy (if used) maps to HighLevel's Parent Company field. HighLevel Company is optional — if Frontu customers are individuals without a company association, the contact lands standalone in HighLevel.

Frontu Work Order is the primary non-direct mapping. Each work order becomes a HighLevel Opportunity linked to the customer Contact. The Opportunity Name derives from the work order title or number. Work order amount (if a billed service) maps to Opportunity Value. Pipeline and stage in HighLevel are configured to reflect Frontu's job-status progression: Pending maps to an early stage, In Progress to a mid-stage, Completed to Closed Won, and Cancelled to Closed Lost.

Frontu job status values (Pending, In Progress, Completed, Cancelled) map to HighLevel Opportunity Stage values. We configure the HighLevel pipeline so stage names match Frontu's status labels. Probability and forecast-category values are set per stage based on standard HighLevel conventions — these are destination-side schema values your team reviews before migration runs.

Frontu Tasks attached to a work order map to HighLevel Tasks on the associated Contact or Opportunity. Task subject, description, assigned user (by email lookup), due date, and status all translate directly. Completed task history is preserved with original completion timestamps. HighLevel Tasks support the same owner-resolution logic as other objects.

Frontu Technician records resolve to HighLevel Users by email match. We query HighLevel's user list by email address — if a matching user exists, the technician's tasks and work orders are assigned to that user as OwnerId. If no match is found, records are flagged for your team to either invite the technician to HighLevel or assign to a fallback owner before migration.

Frontu Location (street address, city, GPS latitude and longitude, Google Maps URL) has no native equivalent in HighLevel. We create custom fields on the relevant Opportunity: Address__c for the formatted address, GPS_Latitude__c and GPS_Longitude__c for coordinates, and Google_Maps_URL__c for the link. If Frontu stores location as unstructured notes, we parse and normalize it into these fields.

Frontu service-type classification (e.g., Repair, Installation, Maintenance, Inspection) maps to a custom picklist field on the HighLevel Opportunity: Service_Type__c. Pick-list values are created to match Frontu's taxonomy exactly. This field is used in HighLevel reporting and can trigger Workflows once your team rebuilds automations.

Frontu work-order attachments (photos taken by technicians, customer signatures, documents) re-upload to HighLevel Files attached to the relevant Opportunity or Contact record. File size limits per HighLevel's storage apply. Inline images embedded in Frontu notes are extracted and re-uploaded as separate files. Original attachment filenames are preserved for reference.

Frontu Route (a collection of scheduled jobs assigned to a technician for a given day) has no direct HighLevel equivalent. We preserve the route identifier as a custom Opportunity field (Route_ID__c) and add a Route_Date__c custom date field so your team can reconstruct route groupings manually in HighLevel's pipeline view. Full route-optimization logic must be rebuilt in HighLevel's Workflow Builder or calendar tools.

Frontu custom fields on any object map to HighLevel custom fields of the equivalent type (text, number, date, picklist, checkbox). We create HighLevel custom fields before migration runs, matching data types and pick-list values. Frontu's custom-field schema is reviewed during the pre-migration audit to identify any fields that require transformation (e.g., multi-select values stored as delimited strings).

Frontu routing rules, dispatch automations, and task-triggered notifications do not migrate — they are a configuration artifact of Frontu's scheduler, not data. We export the configuration as a reference document your HighLevel admin can use to rebuild equivalent automations in HighLevel's Workflow Builder. Scheduling and routing logic is rebuilt from scratch.