Migrate from FieldEdge to HighLevel

FieldEdge work orders have no native HighLevel equivalent — job records require a custom opportunity object

HighLevel's Opportunities object is designed for sales pipeline stages, not field-service job tracking. A FieldEdge work order (with technician assignment, job type, status, and line items) has no direct field in HighLevel's standard opportunity schema. We create a custom opportunity object with custom fields for job type, technician, status, and notes — but this schema must be defined and created in HighLevel's Settings > Custom Fields before data lands. If the custom opportunity object is not pre-created, migration validation fails for work-order records. The custom object creation is part of our pre-migration schema plan, but your HighLevel admin must approve and create it in the UI.

FieldEdge automations cannot be exported and must be rebuilt in HighLevel's workflow builder

FieldEdge workflow automations (dispatch notifications, follow-up sequences, invoice reminders) use a trigger-action model that is not compatible with HighLevel's workflow engine. There is no import path — the automation logic must be rebuilt manually inside HighLevel's Workflow Builder. We export FieldEdge workflow definitions as a written reference document so your HighLevel admin or consultant can replicate the triggers and conditions. This is a manual step that extends the post-migration timeline and must be accounted for in the project plan. HighLevel's workflow builder supports more complex branching logic than most field-service platforms, so rebuilt automations may offer improved functionality, but the rebuild effort is non-trivial.

HighLevel's API rate limits require batched migration with pagination and retry logic

HighLevel API v2.0 enforces a limit of 100 requests per 10 seconds and 200,000 requests per day per sub-account. For FieldEdge accounts with over 10,000 records, a naive single-threaded migration will hit these limits during the full load phase. FlitStack AI implements batched import with exponential backoff and respects the per-10-second throttle, but this extends migration clock time. Large FieldEdge accounts (25,000+ records) should expect the API-rate-limit pacing to add 4–8 hours to the migration window. We surface this in the pre-migration scoping call and plan batch windows accordingly.

QuickBooks integration data does not migrate — invoice references are preserved as custom fields

FieldEdge's native QuickBooks integration stores invoice and payment records linked to the accounting system. HighLevel does not connect to QuickBooks through a native integration — businesses must set up either HighLevel Payments or a separate Stripe/QuickBooks bridge manually post-migration. We preserve FieldEdge invoice numbers, amounts, and payment status as custom fields on the linked opportunity record so your accounting team can reconcile the books manually during the transition. The financial data itself is preserved; the integration connection is not.

FieldEdge service locations mapped as multiple contact addresses may exceed HighLevel's standard address model

FieldEdge customers can have multiple service addresses (primary billing address plus multiple job-site locations) stored as separate location records. HighLevel's standard contact model has one address per contact. For FieldEdge accounts with extensive multi-location customer records, we map the primary address to the standard contact address field and store additional service locations as custom text fields on the contact. This is a known limitation of HighLevel's native address model — if full multi-location fidelity is required, a custom location object linked to the contact is recommended, but this requires additional schema setup.