Migrate from MobileWorker to HighLevel

Geopoint fields have no native HighLevel equivalent — coordinates must be split and stored as custom decimal fields

mobileWorker stores location data as a native geopoint on Workers, Assignments, and Locations — the ArcGIS platform handles geo-filtering and map rendering automatically. HighLevel has no geopoint, geo-fence, or map widget built into its core CRM. We split every latitude and longitude value into separate custom decimal fields (e.g., Location_Latitude__c, Location_Longitude__c) on the contact or task record. This preserves the coordinate data but requires a third-party map embed or custom widget to render it visually. Your admin should evaluate HighLevel's iframe-friendly architecture to embed a mapping tool before finalizing the workflow triggers that reference these coordinates.

Assignment status value mapping requires explicit pairing — unmapped values default to null and block task creation

HighLevel task status is an open pick-list with default values (Not Started, In Progress, Completed, Deferred, Waiting on Someone). mobileWorker assignment status values (which often include custom states like Paused, Reassigned, Cancelled) do not auto-match. We build an explicit value-mapping table before migration runs — every source status value must be paired with a destination status value or a custom status field. If a source value has no destination match and no custom field is created, that field is written as null, which causes the task creation to fail validation. The mapping plan is delivered on day one of the engagement so your HighLevel admin can add custom status values to the task object before any data is written.

Offline sync configuration does not migrate — field crews lose offline map access unless a replacement is evaluated

mobileWorker's offline capabilities are tied to the ArcGIS map tile cache and the mobile app's local storage settings. These are platform-level configurations, not data records — they cannot be exported as data and have no equivalent in HighLevel's architecture. After migration, field crews lose the ability to view assignment maps and route geometry offline. We document the current offline configuration (tile cache size, sync interval, conflict-resolution rules) in a text export so your team can evaluate alternatives: HighLevel's mobile-responsive forms, a companion offline field app (JotForm Mobile, Fulcrum), or a custom-built mobile form integrated via HighLevel's webhook system. This decision point is surfaced in the migration plan, not left as a post-migration surprise.

Route-to-task linking requires a custom object with a lookup relationship — standard HighLevel objects do not model route sequences

mobileWorker route records contain an ordered sequence of stops, each with arrival time, assignment reference, and geometry. HighLevel has no native route, stop-sequence, or dispatch-optimization object. We model this as a Route__c custom object (route name, total distance, geometry JSON) linked to individual tasks via a Route__c lookup field on each task. The migration plan includes the custom object schema definition — Route__c, Stop_Count__c, Total_Distance__c, Geometry_JSON__c — so your HighLevel admin can create these fields in the sandbox before data lands. The ordered sequence of stops is preserved in the geometry JSON blob rather than as a linked list, so any route-visualization feature in HighLevel would need to parse that JSON client-side.

HighLevel API rate limits (200k/day, 100/10s burst) require throttled bulk writes on large worker datasets

HighLevel's API 2.0 enforces 200,000 requests per day per sub-account with a 100-request burst per 10-second window. For migrations exceeding 50,000 workers or assignment records, we implement a write queue with exponential backoff that stays within these limits. The migration platform monitors the X-RateLimit-Remaining response header and pauses writes when the burst limit is approached. Records that fail due to rate-limit 429 responses are retried after the window resets. This is disclosed upfront because teams migrating from ArcGIS — which has no per-record API cost — sometimes assume the destination API is unlimited. It is not, and planning around the rate limit adds 1–2 days to the migration window for large datasets.