Migrate from SortScape to HighLevel

Job Run groupings and route-optimization sequences do not migrate

SortScape's Job Runs apply a route-optimization algorithm that reorders jobs for a crew's daily route to minimize drive time. HighLevel has no native Job Run concept and no route-optimization capability. The optimization output — the ordered stop sequence — is stored in SortScape's scheduling engine and is not part of the export. FlitStack preserves the Job Run name as a tag on each Opportunity for reference, but the route order must be rebuilt manually in HighLevel or through a third-party routing tool integrated via webhook or workflow trigger. Teams relying heavily on SortScape's routing should plan for a separate routing tool post-migration or use HighLevel's Calendar with manual sequencing.

HighLevel custom fields are object-scoped at creation and cannot be reclassified

HighLevel's custom field system assigns a field to a specific object (Contact, Opportunity, Company) at creation time. A field created on Contact cannot later be moved to Opportunity — the field must be deleted and recreated on the correct object. SortScape allows custom fields on Jobs, Properties, and Customers without this restriction. FlitStack's pre-migration planning step documents every SortScape custom field and its intended HighLevel object so fields are created on the right object before any data lands. If SortScape uses the same field name on multiple objects (e.g., 'site_notes' on both Property and Job), separate HighLevel fields are created on each object with distinct API names.

SortScape's CSV export requires UTF-8 encoding and date format compliance for HighLevel import

SortScape's data export produces CSV files in the account's locale encoding, which may not be UTF-8 if the account is set to Australian English or other regional settings. HighLevel's import pipeline rejects CSV files with encoding mismatches, causing silent failures on accented characters in customer names and property addresses. Additionally, SortScape exports dates in DD/MM/YYYY format by default, but HighLevel expects YYYY-MM-DD on most date fields. FlitStack normalizes encoding and reformats all date fields before submitting to HighLevel's import pipeline. Accounts with emoji in customer notes or property descriptions require additional cleaning.

SortScape invoice records and Xero/QuickBooks references are preserved as cross-references only

SortScape generates invoices that sync to Xero or QuickBooks for accounting. Those invoice records — line items, payment status, tax amounts — live in the accounting platform, not in SortScape's data export. FlitStack migrates the SortScape invoice ID and accounting platform reference as custom fields on the Opportunity (Xero_Invoice_Ref__c, QB_Invoice_ID__c), but the invoice financial data itself is not transferred. Teams must ensure their Xero or QuickBooks connection is active during migration so invoice reconciliation can occur post-import by matching on the reference field.

SortScape's iPhone app restart issue means recent jobs may have unsaved offline data

SortScape users on iOS report that the app requires regular restarts to function properly, and the in-app mapping feature is only available on the desktop version. Field crews working offline may have jobs created or status changes stored locally on the device that have not synced to SortScape's cloud before the migration export runs. FlitStack requires a 48-hour delta window after the initial export to capture any records modified in SortScape during the cutover period. Teams with heavy mobile usage should force-sync all devices before the migration snapshot is taken to minimize post-migration reconciliation work.