Migrate your SolarWinds Service Desk data

Incidents are the primary ticket object. Standard fields (priority, status, assignee, requester, description) map cleanly via the Samanage API. We preserve incident history, comments, and SLA timers during migration. Timer state is carried as a custom field where the destination does not support native SLA pause.

Service Requests follow the same API schema as Incidents with a distinct type field. Approval workflows attached to service requests are migrated as metadata since destination systems vary in their approval object model.

Problems require explicit enablement under Setup > Global Settings > Service Desk Settings > Extra Features. We cannot migrate problem records if this feature was never enabled in the source instance. Where enabled, we map Problems to the destination's equivalent object and link them to related Incidents via a custom association field.

Assets expose rich metadata including serial numbers, purchase dates, assignment history, and CI relationships. The CMDB dependency mapping on Premier tier is valuable but not available on lower tiers. We map hardware assets to the destination CI model and flag any asset fields that lack a direct equivalent.

User roles (Agent, Requester, Administrator) map via the API. We preserve active/inactive status and group assignments. When the destination uses a different role naming scheme, we map by permission level rather than role name.

Companies serve as organizational containers for users and assets. The API exposes company metadata including address and associated user counts. We migrate companies as top-level records and link them to corresponding user and asset records.

KB Articles can be exported and imported, but category structure and article versioning may not map 1:1. We migrate article content, attachments, and category assignments, then flag any orphaned articles for manual categorization review.

Custom fields on Incidents, Assets, and Users require field-level mapping work because naming conventions and data types vary between source and destination. We extract the full custom field schema pre-migration and generate a mapping table before any data is moved.

SLA policies define response and resolution deadlines per priority level. We map SLA assignments to the destination's SLA object, but timer-reset behavior on business-hours calendars requires validation post-import.

Change management templates and approval workflows are stored as configuration objects. We export the template definitions and recreate them in the destination where the target platform supports a similar change workflow model.

File attachments on tickets and assets are downloadable via the API and re-uploadable to the destination. Attachment size limits and storage quotas at the destination may constrain large-volume migrations. We chunk large attachment batches to avoid timeout failures.

Configuration item relationships are available primarily on the Premier tier. We export CI dependency graphs and attempt to recreate them as custom relationship objects in the destination, noting that not all platforms support visual CMDB mapping.

Tags applied to tickets and assets migrate as string arrays. The destination's tag model must support equivalent flat or hierarchical tagging to preserve organizational labeling schemes.

Historical report definitions and saved analytics dashboards do not have a documented export mechanism via API. We do not migrate report configurations. Customers should export data as CSV from built-in reports before migration and rebuild key reports in the destination platform.