Migrating SolarWinds Service Desk to ServiceNow takes 3–10 weeks depending on CMDB depth and volume. The biggest risk is broken references from wrong load order. Automations must be rebuilt.
There is no native migration path from SolarWinds Service Desk to ServiceNow; the migration requires API extraction from SolarWinds, staged loading into ServiceNow Import Sets, and manual relationship rebuilding. The fundamental challenge is a data model conversion: SolarWinds uses a flat incident/service-request object and a parent/child CI hierarchy, while ServiceNow splits these across separate tables (incident, sc_req_item) and uses a class-based CMDB inheritance model with 700+ subclasses. Custom work is required to map picklist strings to numeric enums, rebuild CI relationships after loading both endpoints, and fully reconstruct all automation rules, SLA policies, workflows, and portal configurations from scratch in ServiceNow.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick Answer
This migration is medium-to-high complexity. Realistic timelines range from 3 weeks for small environments (under 50,000 records) to 8+ weeks for enterprises with deep CMDB hierarchies and 500,000+ records. The single biggest risk is broken CI-to-incident relationships caused by loading records in the wrong order. Automations, SLA policies, workflow rules, and triggers cannot be migrated and must be rebuilt manually in ServiceNow. Teams with fewer than 100,000 total records and no multi-level CMDB dependencies can often handle this in-house with a dedicated engineer. Environments with complex CMDB trees, custom CI types, and compliance requirements should use a managed migration service.
If your SolarWinds instance uses Task Management v2, those task records currently have no
If your SolarWinds instance uses Task Management v2, those task records currently have no API support as of the June 30, 2026 release. Confirm an alternate extraction path before committing to the migration schedule. (documentation.solarwinds.com)
Performance impact on production instances
Schedule bulk Import Set loads during off-peak hours (weekends or after business hours). Large transform map runs consume database and application server resources, which can degrade performance for concurrent users. Monitor the sys_import_set_run table for long-running transforms. If you have a dedicated migration window, consider temporarily increasing the instance's transaction quota or running loads against a sub-production instance first, then promoting via Update Sets.
If you load incidents before users or CIs exist in ServiceNow, every reference field will be empty
There is no way to retroactively populate reference fields via Import Sets without re-running the transform. Get the order right the first time.
If audit fidelity matters, decide before build whether SolarWinds comments become
If audit fidelity matters, decide before build whether SolarWinds comments become ServiceNow comments (requester-visible), work_notes (internal), or a preserved legacy transcript attachment. Retrofitting that choice after UAT usually means a full reload.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in SolarWinds Service Desk
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated SolarWinds Service Desk → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit
SolarWinds Service Desk → ServiceNow specifics
- Workflow engine limits
- SolarWinds Service Desk automation rules support basic triggers and field updates. ServiceNow Flow Designer (available in ITSM Pro and higher) and Business Rules offer scripted, multi-step orchestrations across any table, including cross-table subflows and approval chains.
- CMDB maturity
- SolarWinds Service Desk supports a parent/child CI hierarchy with dependency mapping, but ServiceNow's CMDB uses a class-based inheritance model (cmdb_ci and 700+ subclasses) with relationship types, discovery integrations, the Common Service Data Model (CSDM), and the CMDB Health Dashboard for ongoing quality scoring.
- Multi-department scale
- SolarWinds supports Enterprise Service Management with renamed modules per service provider. ServiceNow's domain separation and scoped applications handle true multi-entity isolation.
- Licensing alignment
- Confirm whether your target ServiceNow instance is ITSM Standard or ITSM Pro/Enterprise. Features like Flow Designer, the Identification and Reconciliation Engine (IRE), and CSDM alignment require ITSM Pro or higher. If your migration plan depends on these capabilities, verify licensing before committing to a timeline.
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the SolarWinds Service Desk export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of SolarWinds Service Desk satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
SolarWinds Service Desk → ServiceNow specifics
- XML export
- use for partial rollback of specific tables. Faster to restore selectively but does not capture relationships or system state as reliably. Suitable for environments under 50,000 records.
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how SolarWinds Service Desk record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the SolarWinds Service Desk → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to SolarWinds Service Desk. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against SolarWinds Service Desk. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while SolarWinds Service Desk stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze SolarWinds Service Desk and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep SolarWinds Service Desk read-only as the archive and rollback path.
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile SolarWinds Service Desk and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the SolarWinds Service Desk archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
SolarWinds Service Desk ServiceNow Object Mapping
| SolarWinds Service Desk field | ServiceNow field | Notes |
|---|---|---|
| Incidents | incident | Classification field determines if record is incident vs. service request. State fields require enum-to-integer translation. |
| Service Requests | sc_req_item (RITM) | Requires creating parent sc_request records first. Catalog context must exist before loading request history. |
| Catalog Items | sc_cat_item | Forms, variables, approvals, and fulfillment logic usually need a full rebuild, not field copy. |
| Problems | problem | SolarWinds problem tasks map to problem_task. Do not land primary problem records on problem_task. |
| Changes | change_request | Differentiate between Standard, Normal, and Emergency types. CAB workflow states need manual remapping. |
| Releases | rm_release | Not all ServiceNow instances have release management activated. Many teams archive release history or map it to change history. |
| Configuration Items (CIs) | cmdb_ci subclasses | Map each CI type to the correct ServiceNow CI class (e.g., cmdb_ci_server). Do not dump everything into generic cmdb_ci. |
| CI Relationships | cmdb_rel_ci | Load only after both endpoint CIs exist. Map SolarWinds dependency links to ServiceNow relationship types (e.g., "Runs on", "Depends on"). |
| Assets / Hardware | alm_asset + alm_hardware | SolarWinds merges asset and CI concepts that ServiceNow separates. Decide whether each source asset becomes an asset, a CI, or both. |
| Users | sys_user | Must be migrated first to preserve record ownership. Match on email address as the unique key. |
| Groups | sys_user_group | Group membership stored separately in sys_user_grmember. |
| Departments | cmn_department | Flat in SolarWinds, can be hierarchical in ServiceNow. Used for cost centers and organizational hierarchy. |
| Sites | cmn_location | SolarWinds site = ServiceNow location. Site-driven routing usually becomes location plus assignment rules. |
| Solutions (Knowledge Base) | kb_knowledge | Must create kb_knowledge_base and kb_category records first. Categories and publishing flow may differ. |
| Categories / Subcategories | sys_choice entries | Become picklist values on the target table, not standalone records. |
| Comments (public) | sys_journal_field (element=comments) | One journal entry per comment, linked by element_id. |
| Comments (private/internal) | sys_journal_field (element=work_notes) | Timestamp preservation requires sys_created_on override with elevated privileges. |
| Attachments | sys_attachment + sys_attachment_doc | ServiceNow stores attachments in 4KB chunks. Must be downloaded from SolarWinds and uploaded via the Attachment API. |
| Tasks | Case by case | As of June 30, 2026, SolarWinds Task Management v2 has no API support. Confirm an alternate extraction path if task records are in scope. (documentation.solarwinds.com) |
| Contracts | ast_contract | Field mapping differs significantly. |
| Risks | No direct equivalent | Migrate as records in a custom table or as risk assessment entries. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Users | low | Users are flat records coalesced on email address and must be loaded first to preserve ownership references, making them straightforward to migrate. |
| Groups | low | Groups map directly to sys_user_group with membership in sys_user_grmember, requiring a simple two-step load after users exist. |
| Incidents | medium | Incidents require state enum translation from strings to numeric codes and must be separated from service requests based on the classification field. |
| Service Requests | high | Service requests must be split into sc_request and sc_req_item records with catalog item dependencies, variables, and fulfillment logic that often need full reconstruction. |
| Configuration Items (CIs) | high | Each SolarWinds CI type must be mapped to the correct ServiceNow cmdb_ci subclass, and CI relationships must be loaded after both endpoints exist to avoid broken dependency chains. |
| CI Relationships | high | SolarWinds parent/child dependency links do not map 1:1 to ServiceNow's cmdb_rel_ci relationship types, requiring careful type mapping and strict load-order enforcement. |
| Knowledge Articles | medium | Articles require pre-creation of kb_knowledge_base and kb_category records, and the publishing workflow and category structure may differ significantly. |
| Attachments | medium | ServiceNow stores attachments in 4KB chunks across sys_attachment and sys_attachment_doc, requiring download from SolarWinds and re-upload via the Attachment API. |
| Custom Fields | medium | SolarWinds custom fields export as dynamic key-value pairs that must be mapped to predefined dictionary columns or variables in ServiceNow, with reference fields requiring pre-existing target records. |
| Comments and Work Notes | medium | Public and private comments must be split into separate sys_journal_field entries with correct element types, and timestamp preservation requires elevated import user privileges. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Incident vs. Service Request Split
SolarWinds stores incidents and service requests in a single object differentiated by a classification field, while ServiceNow requires splitting them across the incident table and sc_req_item table with parent sc_request records and catalog dependencies.
CMDB Class Inheritance Mapping
SolarWinds uses a flat parent/child CI hierarchy that must be mapped to ServiceNow's class-based cmdb_ci subclasses and separate cmdb_rel_ci relationship records, requiring strict load-order sequencing to avoid broken references.
State and Enum Translation
SolarWinds uses string-based picklist values and supports custom states, which must be translated to ServiceNow's numeric state codes and sys_choice entries to avoid breaking dashboards and SLA logic.
Comment Timestamp Preservation
Preserving original timestamps on journal entries requires overriding sys_created_on with an import user that has elevated privileges, since ServiceNow stores comments in a separate sys_journal_field table rather than as nested objects.
Automation and Workflow Rebuild
SolarWinds automation rules, SLA policies, triggers, approval logic, and notification templates have no automated migration path and must be manually reconstructed using ServiceNow Business Rules, Flow Designer, and SLA Definitions.
Asset-CI Relationship Separation
SolarWinds merges asset and CI concepts into a single entity, while ServiceNow separates them across alm_asset/alm_hardware and cmdb_ci tables, requiring a deliberate decision on whether each source record becomes an asset, a CI, or both.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a SolarWinds Service Desk to ServiceNow migration take?
Small environments with fewer than 50,000 records typically complete in 3–4 weeks including testing. Enterprise migrations with 500,000+ records, CMDB hierarchies, and compliance requirements take 6–10 weeks. The largest time variable is the number of test migration cycles required to achieve clean validation.
What data cannot be migrated from SolarWinds Service Desk to ServiceNow?
Automation rules, SLA policies, workflow triggers, report configurations, dashboards, email notification templates, and portal branding cannot be migrated. These must be manually rebuilt in ServiceNow. The historical data moves; the operating logic does not.
Can SolarWinds Service Desk history be preserved in ServiceNow?
Yes. Incident history, internal work notes, and public comments can be fully preserved by loading them as sys_journal_field entries with original timestamps. This requires the migration user account to have elevated privileges to override sys_created_on and sys_created_by fields.
Can I migrate CMDB data without losing relationships?
Yes, but it requires treating CMDB as its own migration stream. Load CIs into the correct ServiceNow subclasses first, then load cmdb_rel_ci relationship records after both endpoint CIs exist. Use the Identification and Reconciliation Engine to prevent duplicate CIs.
How much does a SolarWinds Service Desk to ServiceNow migration cost?
A DIY API-based migration for a small environment costs 150–250 hours of developer time. Managed migration services for enterprise environments typically range from $10,000 to $50,000+ depending on scope, CMDB complexity, and compliance requirements.