Migrate from iTop to HubSpot Service Hub

iTop UserRequest records map directly to HubSpot Tickets. We map title, description, status, priority, and requester contact. The iTop functional_ci link resolves to a HubSpot custom property itop_ci_id__c since HubSpot has no native CMDB class. The iTop service and subcategory fields map to Ticket subject or custom properties since HubSpot's native subject field is freeform text without a service catalog hierarchy. The assignee (agent) resolves by email match against HubSpot Users.

iTop Incident records map to HubSpot Tickets with the incident classification preserved in a custom property itop_incident_type__c. iTop's caller, impacted_ci, and assignment fields migrate as custom properties or mapped standard fields. The incident timeline and linked knowledge base articles from iTop migrate as ticket comments or custom engagement records. We distinguish Incidents from UserRequests in HubSpot using a custom picklist field rather than separate object types since HubSpot Tickets are unified.

iTop ChangeRequest records (normal, urgent, emergency types) map to HubSpot Tickets with type, approval status, and rollback plan preserved in custom properties (itop_change_type__c, itop_approval_status__c, itop_rollback_plan__c). ChangeRequest approval statistics map to custom number fields. HubSpot's Professional and Enterprise tiers support ticket pipelines that can be configured for change management workflows, but the approval chain logic requires re-implementation using HubSpot's Workflow builder post-migration. We document the existing approval hierarchy for the customer's admin to rebuild.

iTop Contact records (Person class) map directly to HubSpot Contacts. We map name fields, email, phone, and organization membership. iTop's org_id link resolves to a HubSpot Company lookup. For contacts that are iTop end users with no organization assignment, we create HubSpot Contacts without a Company association or optionally link them to a generic 'End Users' Company record depending on the customer's scoping preference.

iTop Organizations map to HubSpot Companies. We map the organization name, website, and hierarchical parent-child structure preserved as HubSpot's company hierarchy (parent_company_id). Organization type and status fields map to custom properties. The organization is created before any Contact import so that the Company lookup is satisfied at Contact insert time.

iTop Services linked to SLA definitions and provider contracts map to HubSpot's Service Objects on Professional and Enterprise tiers. On Starter tier, service and subcategory names migrate as ticket custom properties (itop_service__c, itop_subcategory__c) and are documented for future Service Object setup if the customer upgrades. Service hierarchy (parent-child services) is preserved as a text path property for manual catalog structuring in HubSpot.

iTop CMDB CI classes (Servers, Network Devices, Applications, Databases) have no native HubSpot equivalent. We map CIs to HubSpot Companies with a custom object_type__c property distinguishing CI class (Server, Network, Application, Database). CI relationships (depends_on, impacted_by, logically_impacted_by) are stored as custom multi-select or relationship records. The customer chooses during scoping whether CIs live as Companies (for visibility in the CRM context) or as a Custom Object (for ITSM-specific CI tracking). CI health status and criticality migrate as custom properties.

iTop User account metadata (login, profile, role assignments) migrates as a user inventory document rather than as functional user records. Direct migration of user credentials is not supported due to iTop's PHP-based password hashing and session management. We export the account list with role mappings for the customer's admin to provision matching HubSpot Users manually. Active iTop agents map to active HubSpot Users; inactive agents map to inactive HubSpot Users for historical assignment preservation.

iTop stores attachments in a local file system path structure that becomes invalid in a cloud destination. We export the attachment metadata (filename, size, linked object class, linked object ID) and the raw files separately. During import, we re-upload files to HubSpot's file storage and link them to the target record (Ticket, Contact, or Company) via HubSpot's file API. Large attachment batches are chunked by object and date range to avoid payload limits.

iTop FAQ and KB articles (title, content, category) export in structured format. We recommend using HubSpot's native Knowledge Base import tool for article content and category mapping as it handles content formatting better than generic CSV import. We export iTop KB content in HTML-compatible format and map article categories to HubSpot knowledge base categories during scoping. If the customer does not have HubSpot knowledge base access (Starter tier), we deliver the KB content as a structured export for manual re-creation.

iTop SLA definitions (escalation matrices, response time targets, resolution time targets) export as a written SLA inventory document. SLA escalation rules are platform-specific and cannot migrate as functional policies. We document each SLA's trigger conditions, escalation levels, and time thresholds with a recommended HubSpot SLA Policy configuration equivalent. The customer's admin implements SLA Policies in HubSpot Service Hub Professional or Enterprise post-migration.

iTop allows defining custom classes via XML extensions that create unique class schemas per installation. We export custom object data but each custom class schema must be reviewed and mapped individually. During scoping, we request a schema export from iTop's Designer module or direct XML inspection and work with the customer to define field mappings for each custom class to HubSpot's equivalent standard or custom object. Custom object relationships (foreign keys) are resolved using the same lookup approach as standard iTop objects.