Migrate from SolarWinds Service Desk to Zendesk

SolarWinds Incidents map directly to Zendesk Tickets via the primary ticket identifier. The SolarWinds incident priority (low, medium, high, critical) maps to Zendesk priority (low, normal, high, urgent). Incident status (new, in progress, on hold, resolved, closed) maps to Zendesk ticket status (new, open, pending, hold, solved, closed). We preserve incident history, public and private comments, and SLA timer values as Zendesk comments and SLA metrics. The SolarWinds X-Samanage-Authorization Bearer token authenticates against SolarWinds API v2.1; Zendesk API token authenticates against Zendesk REST API.

Service Requests follow the same SolarWinds API schema as Incidents with a distinct type field (request). We map them to Zendesk Tickets with a custom ticket field (request_type = 'service_request') to preserve the distinction. Approval workflow metadata attached to service requests migrates as ticket comment notes because Zendesk approvals are a separate feature with different configuration semantics. The customer's admin rebuilds approval flows in Zendesk after migration using the written inventory we provide.

Problems require explicit enablement under SolarWinds Setup > Global Settings > Service Desk Settings > Extra Features. If this module was never activated, no problem records exist and we exclude the object from migration. If enabled, Problems have no native Zendesk equivalent; we create a custom Zendesk Sunshine object named Problem with fields mirroring the SolarWinds schema (problem_id, title, description, priority, status, assignee, requester, related_incidents). Related incidents link via Zendesk relationship records or a custom multi-line text field listing linked incident IDs. We flag this configuration decision during discovery.

Zendesk has no native ITAM module, making this the most significant schema gap in the migration. SolarWinds assets expose serial_number, purchase_date, assignment_history, and CI relationships. We map assets to Zendesk Organizations with custom fields for serial number, asset tag, purchase date, and warranty expiration. For organizations requiring full CI relationship tracking, we build a custom Zendesk Sunshine object (CI_Record) with lookup relationships to Organizations. We advise customers during scoping whether to use the Organization-plus-custom-fields approach or the Sunshine object approach based on their asset management maturity and reporting needs.

SolarWinds User roles (Agent, Requester, Administrator) map to Zendesk Users. We preserve active/inactive status, email address, name, and group assignments. SolarWinds Agent group memberships map to Zendesk Groups. Any SolarWinds user without a matching Zendesk user email goes to a reconciliation queue for the customer's admin to provision before record migration resumes. Zendesk end-users (requesters) and agents are separate user types; we map by permission level from SolarWinds role.

SolarWinds Companies serve as organizational containers for users and assets. They map directly to Zendesk Organizations with company name, domain, address, phone, and associated user count preserved. Organization is created as a top-level Zendesk record so that the Organization lookup is satisfied before any related User or Ticket import. The Zendesk organization domain becomes the dedupe key during import.

SolarWinds Knowledge Base articles migrate to Zendesk Help Center articles. We preserve article content, attachments, and category assignments. Category structure mapping requires care because SolarWinds uses a two-level category hierarchy (top-level and second-level) while Zendesk Help Center uses section-based hierarchy. We map SolarWinds top-level categories to Zendesk sections and second-level categories to Zendesk subsections. Orphaned articles (where the parent category has no Zendesk equivalent) are flagged for manual categorization. Article versioning does not migrate because Zendesk articles use a draft/published state model.

SolarWinds custom fields (Checkbox, Date, DateTime, Dropdown, Email, Multi-picklist, Number, Star Rating, Text, Text Area, User, User Multi Select) map to Zendesk ticket fields by data type. Dropdown and Multi-picklist map to Zendesk dropdown and tagger fields respectively. User and User Multi Select fields require email-to-User lookup resolution in Zendesk. Text Area maps to Zendesk Textarea. Star Rating maps to a custom integer field with visual display handled post-migration via Zendesk app or theme customization. We extract the full custom field schema during discovery and produce a typed field mapping table before import.

SolarWinds SLA policies define response and resolution deadlines per priority level. We map SLA assignments to Zendesk SLA Policies, which are attached to Zendesk ticket fields or requester organizations. Business-hours calendar settings (which define when SLA timers pause) require validation because SolarWinds and Zendesk use different calendar configuration models. We document the source SLA calendar and advise the customer on the Zendesk business hours setup required to replicate the same timer behavior.

Tags applied to SolarWinds tickets and assets migrate as Zendesk tags (string arrays). The Zendesk tag model supports flat tagging; hierarchical tagging in SolarWinds is flattened to a dot-separated string (e.g., tier-2.network becomes 'tier-2.network' as a single tag) to preserve the original organizational labeling scheme.

File attachments on SolarWinds tickets and assets are downloaded via the API and re-uploaded to Zendesk via the Zendesk Attachments API endpoint. Attachment size limits (Zendesk allows 50 MB per attachment on Enterprise, 20 MB on lower tiers) and storage quotas are validated during discovery. Large-volume attachment migrations require storage headroom at the destination before migration begins.

SolarWinds historical report definitions and saved analytics dashboards have no documented export mechanism via API. We do not migrate report configurations. Customers export data as CSV from SolarWinds built-in reporting for manual re-creation in Zendesk Explore or a third-party BI tool. We provide a list of all active report names and their SolarWinds object scope to assist the customer's admin during rebuild.