Migrate from SolarWinds Web Help Desk to Zendesk

WHD Tickets (service requests) map directly to Zendesk Tickets. The WHD fields for status, priority, category, assignee, requester (client), description, and SLA timers migrate to Zendesk's Ticket fields. WHD's long-text description and resolution fields truncate under WHD's template export; we flag any truncated descriptions during scoping and handle via direct DB query where self-hosted access is available. Zendesk Comments map from WHD ticket thread entries.

WHD Clients (end-user contacts who submit tickets) map to Zendesk End Users. We export all client fields including name, email, phone, location, and organization assignment. Zendesk User is created before the first Ticket import so that the requester_id reference is satisfied. Clients without email addresses require the customer to decide whether to create placeholder emails or flag as unresolved during reconciliation.

WHD Technicians map to Zendesk Agents. WHD's per-technician pricing means we audit active versus inactive technicians during scoping to help the customer right-size their Zendesk agent count. We export technician name, email, role, and group assignment from WHD and map group membership to Zendesk Groups. Inactive technicians can be imported as Zendesk end users or held for manual provisioning based on the customer's preference.

WHD Asset records (hardware and software inventory) map to Zendesk Assets. WHD assets include type, serial number, purchase date, vendor, location, and manufacturer/model references. Zendesk requires Asset Type, Manufacturer, and Model to exist as configuration records before Asset import, so we create those first. WHD Purchase Orders linked to assets attach as Zendesk Asset descriptions or custom fields since Zendesk has no native PO object.

WHD Locations (with address, contact, and parent-location hierarchy) map to Zendesk Organizations. WHD organizations and locations both create Zendesk Organizations; the customer chooses during scoping whether to treat WHD's location hierarchy as flat organizations or nested via Zendesk's parent organization field.

WHD Change Requests track CAB-approved infrastructure changes with risk fields and approval workflows. Zendesk has no native Change Request object, so Change Request fields migrate as Zendesk Ticket custom fields and a dedicated Change Request ticket status set. The CAB approval history and risk score store in custom fields; the customer's admin rebuilds the approval workflow as a Zendesk Macro or Business Rule post-migration.

WHD Knowledge Base Articles with categorization and article text map to Zendesk Help Center articles. Article text, category assignments, and publication status migrate. Zendesk's Help Center section structure differs from WHD's category hierarchy; we flatten or nest categories during scoping based on the customer's content organization preference. Attachments on KB articles migrate as Zendesk article attachments.

WHD custom fields on Tickets, Clients, and Assets map to Zendesk Ticket Fields and User Fields. WHD's custom fields are indexed overnight (8pm PT for US datacenter); we run custom field imports 24-48 hours before the main data pass to ensure all field indexes are populated. Zendesk custom fields are created via the Zendesk API before migration begins and are immediately available, removing the indexing wait on the destination side.

WHD stores attachment references and metadata on tickets. Actual file blobs require separate handling: for self-hosted WHD we extract via filesystem access; for cloud-hosted WHD we handle via manual download-and-reupload or the customer's file share. WHD's practical attachment ceiling is ~25MB via email/MAPI transport; Zendesk supports 50MB. We flag any WHD attachment exceeding 25MB during scoping and handle via direct extraction. Attachment name, size, and upload timestamp migrate as Zendesk ticket attachment metadata.

WHD tags on tickets and assets map to Zendesk Tags. Tags are preserved as plain-text arrays and applied per record in Zendesk. WHD's multi-value tagging migrates directly to Zendesk's tagging model with no transformation required.

WHD SLA configurations (response and resolution timers by priority or category) migrate as Zendesk SLA Policies, which the customer's admin configures in Zendesk Admin post-migration. We export SLA rules as a written configuration inventory documenting WHD's SLA name, timer values, and applicable priority/category conditions so the admin can rebuild accurately.