Migrate from Mobile Service App to HubSpot

HubSpot's 500 custom property limit applies per portal — source schemas exceeding this threshold require property pruning

HubSpot's portal-level custom property cap of 500 properties per object is a hard limit on most Starter through Professional tiers. Mobile Service App setups with 100+ custom fields per object — common in heavily customized field service deployments — will exceed this threshold. We run a pre-migration property audit that counts all source custom fields and maps them to HubSpot properties, flagging any that would push the total over 500. Teams must decide which properties to archive as JSON blobs versus migrate as live fields before the migration begins. This decision directly affects pricing and timeline.

Technician-to-job assignments require owner resolution by email — unmatched technicians land without an OwnerId

HubSpot Deals require an OwnerId lookup to a portal user, and HubSpot Contacts representing technicians also need owner assignment for reporting. The Mobile Service App stores technician IDs that are internal to the source platform with no guaranteed email correspondence. We resolve assignments by matching the technician's email from the source Employee record against HubSpot portal users. Any technician whose email has no matching HubSpot user account is flagged before migration, and their associated jobs are assigned to a designated fallback owner. If fallback assignments are not pre-authorized, records will fail validation during the migration run.

N:N customer-to-location relationships collapse to primary company association in HubSpot

Mobile Service App supports a customer having multiple service locations with equal billing or operational standing — a many-to-many relationship between customers and locations. HubSpot Company records hold a single primary address, and while you can create multiple Companies for each location, there is no native N:N junction object that preserves the 'same customer, multiple sites' relationship. We handle this by creating separate Company records per location and linking them via a custom junction property (Parent_Customer_ID__c) so reporting can reconstruct the relationship. This requires pre-approval of the company-split strategy before migration runs.

Scheduling and dispatch rules do not migrate and have no HubSpot equivalent — rebuild required

The routing rules, geographic clustering logic, technician availability windows, and dispatch priority settings that power Mobile Service App's scheduling engine have no schema analogue in HubSpot CRM. HubSpot does not include a scheduling or dispatch module at the CRM tier, so these rules must be rebuilt either manually within HubSpot or by integrating a third-party scheduling tool such as Jobber, ServiceTitan, or a custom scheduling API. We export the source scheduling configuration as a structured JSON document that documents the current rules for a rebuild reference, but the migration does not carry over any automation, routing, or scheduling logic.

Job visit history converts to HubSpot Notes — rich metadata like GPS coordinates and travel time may be lost

HubSpot Notes have a body field and timestamp, but they do not natively store structured metadata like GPS coordinates, travel distance, or per-stop duration that Mobile Service App captures as visit record fields. We migrate visit metadata as formatted text within the Note body so it remains searchable, but the structured fields cannot be used for reporting or filtering within HubSpot's native analytics. If GPS or travel-time reporting is required post-migration, teams should configure a custom object for job visits with dedicated fields for these values before the migration runs.