Migrate from ServiceNow IT Service Management to HubSpot Service Hub

ServiceNow Incidents map to HubSpot Tickets. The Incident state (New, Active, On Hold, Resolved, Closed) maps to a HubSpot pipeline with stages named to match the ITSM lifecycle. We preserve incident.number as a custom Ticket property hs_incident_number__c for cross-reference. Impact, Urgency, and Priority (I-P-U matrix) migrate as custom select properties. The assigned_to user resolves to a HubSpot User by email match. Incidents linked to Configuration Items carry the CI reference in a custom property or lookup to a custom CI object we pre-create in HubSpot.

ServiceNow Problems map to HubSpot Tickets with a custom type property set to Problem, or to a HubSpot Custom Object (Enterprise tier) if the customer requires problem-incident linking as a first-class relationship. We preserve the problem_id field, known_error status, and problem_manager assignment as custom Ticket or custom object properties. Child incident relationships migrate as HubSpot ticket association records linking the Problem ticket to each related Incident ticket.

Change Requests map to HubSpot Tickets with a custom type property set to Change Request and a separate Change Request pipeline. Risk level (Low, Medium, High, Critical) migrates as a custom select property. CAB approval status maps to a custom ticket property; actual CAB approval records do not migrate because HubSpot has no native approval engine for ticket records. Implementation tasks (child Task records) migrate as HubSpot child Tasks linked to the parent Change Request ticket.

ServiceNow Service Catalog Items with custom variable sets and variable set definitions are configuration, not data. The catalog structure, variable sets, and item-to-category relationships do not migrate. We document the existing catalog hierarchy and variable definitions in a written catalog map for the customer's HubSpot admin to rebuild using HubSpot's knowledge base and form builder. The underlying catalog request records (sc_task orRequested Item records) that generate ticket history do migrate as tickets.

ServiceNow CIs from the CMDB export as a HubSpot Custom Object named Configuration_Item__c with properties for ci_name, ci_class, serial_number, and ip_address. Parent-child CI relationships export as lookup fields on the custom object or are flattened into a delimited text property for reporting. If the customer does not hold HubSpot Enterprise, we map CIs to Companies with a ci_type custom property and acknowledge the limitation that parent-child dependency graphs do not map. The CI record count and relationship table volume are inventoried during discovery to scope custom object quota consumption.

ServiceNow Knowledge Articles export with article body, metadata (author, article number, category), workflow state (Draft, Published, Retired), and tags. We migrate articles to HubSpot Knowledge Base using the HubSpot Knowledge Base API. Article approval workflows and draft-retired states do not migrate; all migrated articles land as published in HubSpot unless the customer specifies otherwise during scoping. Categories map to HubSpot Knowledge Base sections and categories. We deliver a URL redirect map so that old ServiceNow KB URLs can be redirected to the new HubSpot KB URLs.

ServiceNow Users (fulfillers and requesters) map to HubSpot Users by email address. We extract first_name, last_name, email, department, and location. Fulfiller license type from ServiceNow maps to a HubSpot role assignment (agent or admin) during scoping. Inactive ServiceNow users migrate as inactive HubSpot Users and are flagged for the customer's admin to activate on a defined schedule. The Fulfiller versus Requester licensing distinction in ServiceNow has no direct HubSpot equivalent; we document the role distribution so the customer can plan HubSpot seat allocation.

ServiceNow Groups define ticket assignment routing, approval chains, and group-type classifications (fulfillment, approval, etc.). HubSpot does not support Groups as a migration object; the standard migration tools exclude Groups. We map ServiceNow Group membership to HubSpot Teams and Inboxes where applicable, and we deliver a written Group-to-Team mapping table listing each ServiceNow Group, its members, its assignment type, and the recommended HubSpot Team or Inbox equivalent. Group managers and group-type approval chain roles require manual configuration post-migration.

ServiceNow SLA records carry breach duration, business hours calendar references, and breach actions. HubSpot Service Hub has no native SLA timer mechanism. We capture SLA name, breach duration in hours, and calendar reference as custom Ticket properties (sla_name__c, sla_breach_hours__c, sla_business_hours__c) during migration. SLA breach status is computed post-migration using HubSpot reporting or a custom workflow step. Calendar definitions that do not map 1:1 are flagged in the discovery report with a recommendation to standardize business hours in HubSpot Settings before migration.

ServiceNow Tasks attached to Incidents or Change Requests migrate as HubSpot child Tasks under the corresponding parent Ticket. Task state, assignment, and due date transfer directly. Parent reference is resolved at migration time using the incident_number or change_request lookup property on the child task.

File attachments on Incidents, Problems, and Change Requests export via the ServiceNow table API and import to HubSpot Tickets using the HubSpot Files API linked to the target ticket record. Attachment volumes above 1 GB require chunked export and storage consideration. Inline images embedded in ticket body text cannot be extracted as standalone attachments and are flagged as a limitation in the gotchas section. We notify the customer during scoping if attachment volume approaches storage limits.

Instance-specific custom fields on ServiceNow Incident, Problem, and Change Request tables require field-level inventory during discovery. We create matching custom properties in HubSpot using the HubSpot Properties API before migration begins. Data types are mapped as follows: ServiceNow string to HubSpot string, ServiceNow boolean to HubSpot checkbox, ServiceNow reference to a lookup property pointing at the migrated target object, ServiceNow choice to HubSpot select or multi-select. Custom fields that reference ServiceNow-only tables (e.g., CI references) map to the corresponding HubSpot custom object or company property.