Migrate from ServicePRO to HubSpot Service Hub

ServicePRO Service Requests map to HubSpot Tickets. Standard fields (status, priority, category, assigned technician) map directly. Custom form fields on ServicePRO tickets require explicit field-type mapping — text to string, numeric to number, date to date, checkbox to boolean, dropdown to HubSpot dropdown — because ServicePRO encodes field type as integer pairs in the metadata API. We flag masked-entry fields (telephone, SSN, credit card) for PII handling and exclude them from the import payload unless the customer provides explicit written authorization.

ServicePRO ticket conversations migrate to HubSpot Ticket Conversations via the HubSpot conversations API. Each message body, author, timestamp, and attachment reference is resolved against the migrated user mapping. Large binary attachments (PDFs, images) migrate as file links where the source URL remains accessible; we flag any attachments exceeding HubSpot's 10 MB per-file limit for manual re-upload.

ServicePRO Employees (via GET api/v1/Setup/GetEmployeeInfoByEmployeeId) map to HubSpot Users. The built-in CSV Import Utility handles bulk user creation with department assignments. We resolve ServicePRO employee IDs against HubSpot user IDs by email match, and any orphaned user references (technicians who no longer exist in HubSpot) are held in a reconciliation queue for the customer's admin to provision before record import resumes.

ServicePRO Assets migrate to a HubSpot Custom Object named Asset. We pre-create the custom object schema in HubSpot (with API name Asset__c) including fields for asset name, type, serial number, and any custom asset fields defined in ServicePRO, before any records import. The CSV Import Utility can also handle bulk asset loads for the flat asset fields, with custom object used for fields that require the full schema resolution.

ServicePRO Enterprise multi-ServiceCenter configurations must be consolidated into HubSpot's single-queue model. Each Service Center maps to a HubSpot Pipeline (if the customer wants distinct stage tracks) or a HubSpot Team (if the customer wants a single pipeline with team-based routing). We present both options during scoping and require explicit sign-off on the chosen mapping before extraction begins, because routing tickets to the wrong team post-migration is a high-impact data integrity failure.

ServicePRO Target Categories are hierarchical lookup structures exposed via GetTargetCategoryList. They define the classification taxonomy for service requests. We map each Target Category to a HubSpot Ticket Pipeline, and any sub-categories map to Pipeline stages within HubSpot. The isRelated and UsedInSharedRef flags from the ServicePRO API determine whether the category applies to multiple record types and whether it should be treated as a shared reference or an isolated taxonomy.

ServicePRO Target Records (vendors, customers, locations, equipment types) map to HubSpot Contacts and Companies. We use the targettypeid field from GetTargetList to route each record to the correct HubSpot object — customer-type targets map to Contact, company-type targets map to Company, vendor-type targets map to Company with a vendor flag, and location-type targets map to Contact address properties or a custom location property.

ServicePRO Programs define service offerings and link to inventory items, branches, and events. HubSpot Service Hub has no native Program object. We map Programs to a Custom Object (Program__c) with lookup relationships to the related Asset (via Asset__c), Branch (as a text or dropdown property), and Event records. Program-to-ProgramEvent links are preserved as separate Program Event custom object records or as a many-to-many association table.

ServicePRO System Email Accounts define sending and receiving addresses used in ticket communications. Professional is capped at 10; Enterprise is unlimited. We export account configurations including SMTP settings and forwarding rules as a written configuration document. HubSpot's inbox routing is configured manually post-migration because inbox connections require the customer's email infrastructure credentials and SPF/DKIM verification, which cannot be migrated programmatically.

ServicePRO Custom Forms define ticket intake layouts and capture structured data. Professional is capped at 25 forms; Enterprise has unlimited. We export form structure and field definitions from the metadata API and produce a written form-equivalence guide mapping each ServicePRO form to a HubSpot ticket configuration (standard properties plus custom fields) and optionally a HubSpot Form for the intake side. The customer rebuilds the intake form in HubSpot Forms or via a customer portal form.

ServicePRO Business Rules define automated routing, escalation, and notification logic. They have no documented API export endpoint. We document every Business Rule discovered during the discovery phase — trigger condition, action type, escalation timer, and routing target — in a written rules inventory. This inventory is a direct input to the customer's HubSpot Workflow rebuild. We do not migrate Business Rules as code because the two systems' automation models are structurally incompatible. The customer's admin uses the inventory to rebuild rules in HubSpot Workflows post-migration.

ServicePRO stores attachments linked to tickets, assets, and forms. We export attachments via the API or via direct database reference where accessible. Large binary attachments (images, PDFs over 10 MB) are flagged for manual re-upload because HubSpot's file size limit is 10 MB per file. Attachment-to-record associations are preserved via the HubSpot file linking API so that the migrated ticket shows the correct attachment list.