Migrate from SolarWinds Service Desk to HubSpot Service Hub

SolarWinds Incidents and Service Requests share the same API endpoint (api/samanage.com/incidents) with a type discriminator field. We split on type during the transform: records where type equals Incident land in HubSpot Tickets with a default ticket type of Incident, and Service Request records land with ticket type of Feature Request or a custom ticket pipeline name chosen during scoping. Priority, status, assignee, requester, description, and all custom fields map to the equivalent HubSpot Ticket properties. Incident history (comments, internal notes, resolution summary) migrates as HubSpot Ticket conversations.

Service Requests from SolarWinds are split from Incidents during the same transform pass and written to a separate HubSpot Ticket pipeline or ticket type. If the destination uses the Professional tier with multiple ticket pipelines, we map Service Requests to a dedicated pipeline. Approval workflows attached to service requests migrate as metadata notes because HubSpot's approval flow model differs from SolarWinds' built-in approval chain. We document each approval condition for the customer's admin to rebuild using HubSpot's Workflows tool.

Problems require explicit enablement under Setup > Global Settings > Service Desk Settings > Extra Features in SolarWinds; if this feature was never activated, the API returns empty sets and no problem records exist. We verify enablement status during discovery and include a check in our pre-migration audit. For enabled instances, we map Problem records to a HubSpot Custom Object named Problem (with a __c API name) or to Tickets with a custom Problem link property depending on the customer's preference. Root cause descriptions and known-error-list content migrate as long-text custom fields.

SolarWinds hardware assets expose serial number, purchase date, assignment history, and CI relationships. HubSpot has no native hardware asset object, so we create a custom object (e.g., IT_Asset__c) with custom fields for serial number, asset tag, purchase date, warranty expiration, assigned user (lookup to HubSpot User), and CI relationship (lookup to related IT_Asset__c records or Company). CMDB dependency graphs available on SolarWinds Premier tier migrate as custom relationship records within the same custom object. We pre-create the custom object schema before any asset import to satisfy lookup dependencies.

Software licenses and installations migrate to the same IT_Asset__c custom object with a software-specific record type. License key, version, vendor, seat count, and expiration date become custom fields. If the customer uses SolarWinds' software discovery to track installation counts, we map those counts to a custom integer field. License-to-asset assignments link via the IT_Asset__c lookup on the assigned user record.

SolarWinds Agent and Administrator users map to HubSpot Users. We resolve by email match against the HubSpot destination User table. Active/inactive status and group assignments migrate; inactive users are created as inactive HubSpot Users to preserve historical assignment data. Requesters (end users who submit tickets) map to HubSpot Contacts attached to their associated Company record. User roles (Agent vs Administrator) are preserved as HubSpot User role assignments. Any SolarWinds user without a matching HubSpot User or Contact goes to a reconciliation queue.

SolarWinds Company records map directly to HubSpot Company. The company name, domain, address, phone, and associated user count migrate to the equivalent HubSpot Company properties. Company is created before any Contact or Ticket import so that the Company-to-Contact association is satisfied at the moment of insert. We use Company name as the dedupe key during import.

KB Articles migrate to HubSpot Knowledge Base with article content and attachments preserved. SolarWinds nested category hierarchies (parent-child category structures) cannot map 1:1 to HubSpot's flat Knowledge Base category model, so we map to a top-level HubSpot category and flag articles that would be orphaned by the hierarchy flattening. Article versioning in SolarWinds is not preserved; we migrate the most recent published version of each article. Inline images download from SolarWinds and re-upload to HubSpot. Articles that reference article IDs not in the migration scope are flagged as orphaned links requiring manual cleanup.

SolarWinds custom fields (Checkbox, Date, Dropdown, Email, Multi-picklist, Number, Text, Text Area, User, User Multi Select, Attachment, Star Rating) require field-level mapping because HubSpot's property type model differs. Dropdown and Multi-picklist become HubSpot select and multi-select properties; User and User Multi Select become HubSpot User or Contact lookups where supported. We extract the full custom field schema during discovery, pre-create all custom properties in the HubSpot destination before migration, and map values during the transform. Attachment fields migrate as URL references or as HubSpot file attachments on the parent record, depending on the destination storage quota.

SolarWinds SLA policies define response and resolution deadlines per priority level. HubSpot Service Hub Free and Starter tiers have no native SLA management object. Professional tier ($130/seat/mo) offers SLA features but with timer-reset behavior that does not replicate SolarWinds' business-hours calendar logic exactly. We export the full SLA policy definitions (priority thresholds, first response deadlines, resolution deadlines, business hours, escalation paths) as a written SLA inventory document for the customer's admin to configure in HubSpot. Timer-reset behavior requires validation after rebuild.

Change management templates and approval workflows in SolarWinds have no direct HubSpot Service Hub equivalent. HubSpot's Workflows tool handles CRM automation (contact property updates, email triggers, task creation) but does not replicate ITSM change advisory board workflows or multi-stage approval chains. We export all change template definitions and approval workflow configurations as a written inventory document. The customer's admin or an ITSM consultant rebuilds these in ServiceNow or another ITSM tool if required. We flag that HubSpot Service Hub is not positioned as an ITSM replacement for change management.

File attachments on tickets and assets are downloaded from SolarWinds via the API and uploaded to HubSpot as file attachments on the parent Ticket or custom object record. HubSpot's file storage quotas and attachment size limits apply; we monitor upload success rates and flag any attachments that exceed HubSpot's size constraints. We preserve the original filename, file type, and upload timestamp. Attachments requiring download from SolarWinds before upload add time to the migration window for large file volumes.

Tags applied to tickets and assets migrate as HubSpot ticket tags. The flat tagging model in HubSpot accommodates SolarWinds tags that use single-level naming; hierarchical tags from SolarWinds are flattened to a hyphenated string. Tag assignments are preserved at the ticket level so that filtering by tag works in HubSpot's ticket views and reporting.