Migrate from ServicePRO to Intercom

Service Requests map to Intercom Conversations or Tickets depending on channel intent. Chat-based requests become Intercom Conversations; email-initiated or back-office requests become Tickets with a Ticket Type. We preserve ServiceRequestId as external_id on the Intercom record for dedupe and audit. Status (Open, Pending, Resolved, Closed) maps to Intercom's Open, Snoozed, Closed states. Priority maps to Ticket Priority (if using Tickets) or a custom conversation attribute. Assigned technician maps to Intercom's assigned admin via the User mapping. Custom form field values migrate as data attributes, requiring pre-creation of the attribute in Intercom before conversation import.

ServicePRO employees and technicians map to Intercom Admins. We extract via the Employee API (GetEmployeeInfoByEmployeeId) and match by email to existing Intercom Admins. The CSV Import Utility handles bulk user load with department assignments that map to Intercom Teams. Inactive or deleted ServicePRO technicians are flagged for the customer to decide whether to provision them as inactive Intercom Admins for historical record assignment or reassign open tickets first.

ServicePRO Asset records map to an Intercom Custom Object we define as 'Asset' before migration begins. We map asset name, type, serial number, and any custom asset fields to custom attributes on the Asset Custom Object. Customer linkage (customer account or location) maps to a reference attribute pointing to the migrated Contact or Company. We pre-create the Asset Custom Object schema (including attribute types) in Intercom during the scoping phase so that the attribute IDs exist before any Asset records are imported.

ServicePRO Target Categories are hierarchical lookups (vendors, customers, locations, equipment types) used for ticket classification. We map the top-level category name to Intercom Tags or to a custom conversation attribute with a picklist of the leaf-level values. The isRelated and UsedInSharedRef flags from the Setup API determine whether the category is used for filtering or routing. This is documented in the mapping spec for customer validation before import.

Individual entities within Target Categories (vendor records, customer records, location records) map to Intercom Contacts or Companies depending on type. Vendor-type Target Records map to Intercom Company with a custom vendor_flag attribute. Customer-type records map to Intercom Contact with location-specific custom attributes. Equipment-type records that have a serial number and customer linkage map to the Asset Custom Object created in the Assets mapping step.

ServicePRO Programs define service offerings linked to inventory, branches, and events. Contract linking between customers, sites, and agreements is a frequently praised feature in G2 reviews and must be preserved. We map Programs to a Custom Object 'Service Agreement' with attributes for program name, program type, linked customer (as Contact reference), linked site (as location attribute), and any contract dates. We preserve Program-to-ProgramEvent relationships as a custom event list attribute on the Service Agreement record.

ServicePRO Custom Forms define ticket intake layouts with enumerated field types (text, numeric, date, checkbox, dropdown, masked-entry). Each form maps to an Intercom Ticket Type with corresponding Ticket Attributes defined as data attributes. Masked-entry fields (telephone, SSN, credit card) are flagged for PII handling: we either exclude them from migration or migrate with a masked value and a note to the customer. Dropdown option lists must be validated as identical between source and destination before finalizing the import mapping.

ServicePRO System Email Accounts define sending and receiving addresses used in ticket communications. Professional is limited to 10; Enterprise has unlimited. We export the SMTP configuration (address, server, port, authentication) and document it for the customer's admin to configure in Intercom under Settings > Inboxes > Email. This is a manual step, not an automated migration item, because Intercom's email channel configuration requires authentication verification within the platform UI.

ServicePRO Enterprise multi-ServiceCenter configurations must be consolidated into Intercom's Team and Inbox structure. Each Service Center queue maps to an Intercom Inbox, and Service Center boundaries are enforced by assigning each Inbox to a Team. Professional edition customers with a single Service Center map to a single Intercom Inbox. We define the Center-to-Inbox mapping explicitly in the scoping phase with customer sign-off because the wrong consolidation plan redirects ticket assignment post-migration.

ServicePRO attachments linked to tickets, assets, and forms migrate as Intercom attachments on the corresponding record. We attempt export via API or direct database reference where accessible. Large binary attachments (images, PDFs over 10 MB) are flagged for the customer to decide whether to migrate or re-upload post-migration, because large binary payloads increase API load time and may exceed Intercom's attachment size limits.

ServicePRO Business Rules define automated routing, escalation, and notification logic with no documented API export endpoint. We document every Business Rule discovered during the discovery phase in a written rules inventory with trigger, conditions, actions, and an Intercom Rule equivalence. The customer rebuilds rules in Intercom's Rules engine or via Fin AI Agent procedures. We do not migrate Business Rules as code.

ServicePRO KB articles have no documented export endpoint and must be extracted manually or via custom API. We extract article title, body, author, and any categorization metadata and map them to Intercom Help Center Articles within Collections and Sections. The three-level ServicePRO article hierarchy maps to Intercom's Collection > Section > Article structure. Article URLs and any internal linking require redirect mapping post-migration.