How to Migrate from SolarWinds Service Desk to ServiceNow

A SolarWinds Service Desk to ServiceNow migration moves your ITSM data — incidents, problems, changes, CMDB configuration items, assets, users, groups, knowledge articles, and attachments — from the Samanage-based cloud platform into ServiceNow's table-driven architecture. This is a data model conversion, not a ticket dump. The safe pattern is API extraction from SolarWinds, staged loading into ServiceNow Import Sets, relationship rebuilds, then a delta cutover.

Why Teams Migrate from SolarWinds Service Desk to ServiceNow

Enterprise IT teams outgrow SolarWinds Service Desk when they need deeper workflow automation, granular role-based access, or a platform that scales across multiple business units. For an in-depth architecture and cost comparison, see our ServiceNow vs SolarWinds Service Desk analysis.

The most common drivers:

• 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.

What Makes This Migration Non-Trivial

Four architectural differences create the most friction:

Request model split. SolarWinds Service Desk stores incidents and service requests in the same object, differentiated by a classification field. ServiceNow splits these across the incident table and sc_req_item (RITM) table with separate workflows. Service requests in ServiceNow also require parent sc_request records and often depend on catalog items, variables, and downstream tasks. (documentation.solarwinds.com)

CMDB structure. SolarWinds uses a parent/child CI hierarchy with inherited fields per CI type. ServiceNow's CMDB uses class inheritance from cmdb_ci with relationship records stored in cmdb_rel_ci. Direct parent/child links do not map 1:1. Each SolarWinds CI type must be mapped to a specific ServiceNow CI class before import, and CI relationships must be loaded after both endpoint CIs exist. (documentation.solarwinds.com)

Comment and journal storage. SolarWinds stores public and private comments as nested objects on the incident record. ServiceNow stores journal entries in the sys_journal_field table with element values of comments (public) or work_notes (internal). Timestamp preservation requires overriding sys_created_on with an import user that has elevated privileges.

State and workflow differences. SolarWinds lets you rename system states and add custom states for incidents, service requests, changes, and assets. ServiceNow uses numeric state codes (1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed). Blindly mapping custom SolarWinds states without a reporting review will break dashboards and SLA logic on day one. (documentation.solarwinds.com)

SolarWinds Service Desk to ServiceNow Object Mapping

Map every SolarWinds object to its exact ServiceNow target before writing extraction logic. Do not assume standard CRM objects apply. For scope control on what to migrate and what to leave behind, see our help desk data migration playbook.

Field-Level Mapping Considerations

Picklist and enum handling. SolarWinds uses string-based picklist values (Priority: "Critical", "High", "Medium", "Low"). ServiceNow incident priority uses numeric codes (1=Critical, 2=High, 3=Medium, 4=Low). Your transform map must convert strings to integers.

State mapping. SolarWinds incident states (New, Assigned, Awaiting Input, In Progress, On Hold, Resolved, Closed) need explicit mapping to ServiceNow's numeric state field (1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed). Custom states in SolarWinds require creating matching sys_choice entries in ServiceNow before loading data.

Custom fields. SolarWinds supports unlimited custom fields per object. In ServiceNow, you must create matching fields on the target table using the correct field type (string, integer, reference, date/time). Reference fields require the referenced record to exist before the referring record is loaded. SolarWinds custom fields often export as dynamic key-value pairs and must be mapped to predefined dictionary columns or variables in ServiceNow.

Timestamps. To preserve original created and updated timestamps, set the glide.sys.date_format property and use the sys_created_on and sys_updated_on fields with an import user that has the import_set_loader or admin role. Normalize all timestamps to UTC in ServiceNow's expected format (YYYY-MM-DD HH:MM:SS).

Import Set string casting. Cast everything to strings before it hits a ServiceNow Import Set. ServiceNow documents string-only request body values for Import Set POST methods. (servicenow.com)

Coalesce field configuration. Coalescing is the mechanism that prevents duplicate records during import. In your Transform Map, mark one or more fields as "Coalesce" — typically correlation_id (mapped to the legacy SolarWinds ID) or email for users. When a transform runs, ServiceNow checks whether a record with that coalesce value already exists. If it does, the transform updates the existing record instead of inserting a duplicate. This is critical for delta syncs, re-runs after error correction, and user deduplication. Without coalesce fields configured, every re-run of your migration creates duplicate records. Set coalesce on sys_user.email, incident.correlation_id, and cmdb_ci.correlation_id at minimum.

What Data Cannot Be Migrated

The following SolarWinds Service Desk elements have no automated migration path:

• Automation rules, triggers, and workflow logic — rebuild in ServiceNow using Business Rules, Flow Designer, or Scheduled Jobs
• SLA policies and business hours — recreate manually in ServiceNow SLA Definitions
• Report configurations and dashboards — cannot be exported; must be rebuilt
• Email templates and notification rules — manual setup in ServiceNow notifications
• Portal branding and catalog workflows — complete reconstruction in ServiceNow Service Portal
• Approval logic and routing behavior — must be redesigned, not field-copied

Even migration vendors that automate ticket and article transfer treat workflow and SLA behavior as follow-up configuration work, not as a direct historical import. (help-desk-migration.com)

Migration Approaches Compared

Four viable approaches exist. The right choice depends on record volume, engineering bandwidth, and tolerance for risk.

Native CSV Export + ServiceNow Import Sets

Export data from SolarWinds Service Desk using the Actions > Export > CSV option on each index page. Upload each CSV into a ServiceNow Import Set staging table and use Transform Maps to load records into target tables. (documentation.solarwinds.com)

When to use it: Small environments with fewer than 10,000 records, no CMDB dependencies, and no attachment requirements.

Limitations: CSV exports do not include attachments, inline images, or comment threading. Cells exceeding 32,767 characters cause Excel formatting corruption. No delta sync capability. SolarWinds CSV exports can take hours and the download link is only valid for 14 days.

API-Based Custom ETL

Build a custom extraction pipeline using the SolarWinds Service Desk REST API (api.samanage.com) and load data into ServiceNow via the Import Set API.

When to use it: Mid-size to large environments (10,000–500,000 records) with engineering resources and the need to preserve attachments, comments, and CMDB relationships.

Limitations: High engineering cost. Handling pagination, error retries, rate limits, and relationship rebuilds takes weeks of developer time. Plan for 150–250 hours of engineering effort.

iPaaS / Integration Platform (Zapier, Make, Workato)

Use a no-code connector to sync records between SolarWinds Service Desk and ServiceNow in near-real-time. Zapier lists SolarWinds Service Desk (as Samanage) and ServiceNow as supported platforms with actions like creating or updating records.

When to use it: Ongoing sync scenarios where both platforms run in parallel, or for routing new incidents during a transition period.

Limitations: Not designed for bulk historical migration. Zapier connectors support basic incident creation and updates but not CMDB, problems, or changes. No attachment support in most connectors. Poor fit for replaying years of ITSM history.

Managed Migration Service

A dedicated migration team builds custom extraction scripts, handles field mapping, manages API rate limits, preserves relationships, and runs validation.

When to use it: Enterprise environments with 100,000+ records, multi-level CMDB hierarchies, compliance requirements, or zero-downtime constraints.

Limitations: Requires budget and vendor selection.

API Limits That Shape the Migration Architecture

Understanding both platforms' extraction and load constraints is the only way to prevent failed data loads and plan realistic throughput. For a broader view of ServiceNow ingestion challenges, see 10 ServiceNow Data Migration Challenges.

SolarWinds Service Desk API

• Base URL: https://api.samanage.com
• Authentication: JWT token generated from Setup > Users & Groups, passed via X-Samanage-Authorization: Bearer <token> header. (documentation.solarwinds.com)
• Pagination: Offset-based with page and per_page parameters. Maximum page size is 200 records. Use the X-Total-Count response header to get total record counts per endpoint before beginning extraction — this lets you estimate extraction time and validate completeness.
• Rate limits: SolarWinds enforces rate limiting but does not publicly document specific numeric thresholds. Exceeding limits returns HTTP 429. Plan for conservative throughput of 1 request per second and implement exponential backoff with jitter.
• API access: Gated behind Advanced and Premier plan tiers. Confirm your license level before starting.
• Key endpoints: /incidents.json, /problems.json, /changes.json, /releases.json, /hardwares.json, /configuration_items.json, /users.json, /groups.json, /departments.json, /sites.json, /solutions.json
• Volume estimation: Before starting extraction, call each endpoint with per_page=1 and read the X-Total-Count header. Sum counts across all endpoints to get total record volume and estimate extraction time.

ServiceNow API

• Table API: GET/POST/PUT/DELETE on /api/now/table/{tableName}. Query results default to a maximum of 10,000 records per query, controlled by the glide.db.max_view_records system property. Table API POST inserts only one record at a time — do not use it as your bulk loader. (servicenow.com)
• Import Set API: The recommended path for bulk loads. The insertMultiple method accepts up to 200 records per request. Sending larger chunks risks transaction timeouts. If insertMultiple is not available via REST on your instance, you may need to enable it via the sys_rest_insert_multiple table or use the SOAP insertMultiple method. (servicenow.com)
• Rate limits: Configurable per instance via sys_rate_limit_rules. There is no universal default. Exceeding limits returns HTTP 429 with Retry-After and X-RateLimit-* headers. Do not hard-code an assumed rate limit — check your instance configuration. (servicenow.com)
• REST payload size: Controlled by glide.pf.rest.response_payload_max_size. If your attachment payloads exceed the configured limit, you must chunk the binary data.
• Attachment uploads: Use the Attachment API (/api/now/attachment/file) — one file per request. Maximum single file upload of 25 MB via REST. (servicenow.com)
• Required roles for migration user: The integration user account needs import_transformer, import_set_loader, and admin roles to override system fields like sys_created_on and sys_created_by. For attachment uploads, add the attachment_admin role. Restrict these elevated roles to the migration service account and revoke them after go-live.
• Scoped vs. global application context: Decide before building transform maps whether your migration artifacts (import set tables, transform maps, custom fields) live in a scoped application or the global scope. Scoped applications provide cleaner lifecycle management and easier cleanup post-migration, but transform maps in scoped apps cannot access global business rules or script includes without explicit cross-scope access. For most migrations, the global scope is simpler. If your ServiceNow governance requires scoped apps, test transform behavior in a sub-production instance first.
• MID Server considerations: For attachment-heavy migrations (50,000+ files), consider routing API calls through a ServiceNow MID Server deployed in your network. This avoids browser-based upload timeouts and provides better throughput for large binary transfers. A MID Server is not required for record-only migrations.

Throughput Math

With SolarWinds capped at 200 records per page and a conservative 1-request-per-second extraction rate, the theoretical maximum is 720,000 records per hour on the source side. In practice, expect 400,000–500,000 records per hour after accounting for HTTP latency, 429 retries, and JSON parsing overhead. The real bottleneck is the ServiceNow load side.

Using Import Set insertMultiple at 200 records per request with a 5-second cycle (including transform processing), you can stage roughly 144,000 records per hour. With a 10-second cycle, that drops to 72,000. Transform maps, journal replay, and attachment uploads pull the real throughput lower.

Attachments are the slowest stream. The Attachment API uploads one file per request, so a migration with 40,000 tickets and 60,000 files behaves like a file-transfer project long after the ticket rows are loaded.

For environments with 500,000+ records, plan for 30–50 hours of raw data transfer time on the ServiceNow side, not counting transform processing.

Step-by-Step Migration Process

Data must be loaded into ServiceNow in a strict dependency order. If you load an incident before the assigned user exists, the reference field will be blank. There is no way to retroactively populate reference fields via Import Sets without re-running the transform.

Step 1: Extract from SolarWinds Service Desk

Use the REST API to paginate through each object type. Store raw JSON responses locally or in a staging database. Before extracting, call each endpoint with per_page=1 to capture the X-Total-Count header — this gives you total record counts for progress tracking and post-migration validation.

import requests
import time
 
SWSD_TOKEN = "your-jwt-token"
BASE_URL = "https://api.samanage.com"
HEADERS = {
    "X-Samanage-Authorization": f"Bearer {SWSD_TOKEN}",
    "Accept": "application/vnd.samanage.v2.1+json"
}
 
def get_total_count(endpoint):
    resp = requests.get(
        f"{BASE_URL}/{endpoint}.json?per_page=1&page=1",
        headers=HEADERS
    )
    return int(resp.headers.get("X-Total-Count", 0))
 
def extract_all(endpoint):
    page = 1
    all_records = []
    total = get_total_count(endpoint)
    print(f"{endpoint}: {total} total records")
    while True:
        resp = requests.get(
            f"{BASE_URL}/{endpoint}.json?per_page=200&page={page}",
            headers=HEADERS
        )
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            time.sleep(retry_after)
            continue
        if resp.status_code != 200:
            break
        data = resp.json()
        if not data:
            break
        all_records.extend(data)
        page += 1
        time.sleep(0.5)  # conservative rate limiting
    return all_records
 
incidents = extract_all("incidents")
users = extract_all("users")

Step 2: Clean and Transform

• Deduplicate users by email address (watch for variations like john.doe@company.com vs. jdoe@company.com)
• Map SolarWinds picklist strings to ServiceNow integer codes (state, priority, impact, urgency)
• Split incidents from service requests based on the classification field
• Normalize timestamps to UTC in ServiceNow's expected format (YYYY-MM-DD HH:MM:SS)
• Build a lookup table mapping SolarWinds record IDs to ServiceNow sys_id values (populated during load)
• Assign orphaned records (referencing deleted users or groups) to a "Migration Archive" user
• Normalize inconsistent category values caused by renamed categories mid-lifecycle
• Cast all field values to strings before loading into Import Sets

Step 3: Prepare ServiceNow Target Schema

Create external ID fields, staging tables (Import Sets), choice list entries for custom picklists, catalog structure, and Transform Maps before loading any data. Freeze SolarWinds configuration changes while you finalize mapping.

Update Set management: Package all ServiceNow configuration changes — import set table definitions, transform maps, custom dictionary fields, choice list entries, and business rules — into a dedicated Update Set. Name it clearly (e.g., SWSD_Migration_Config_v1). This allows you to promote your migration configuration from dev to test to production without manual recreation, and provides a clean rollback path by backing out the Update Set if needed. Capture the Update Set in your dev instance, move it to test for validation, then promote to production only after a successful test migration.

Configure coalesce fields on every transform map: set correlation_id (mapped to the SolarWinds legacy ID) as the coalesce field for incidents, problems, changes, and CIs. Set email as the coalesce field for users. This prevents duplicates during delta syncs and re-runs.

Step 4: Load in Dependency Order

The load sequence that prevents orphaned references:

1. Locations — SolarWinds Sites → cmn_location
2. Departments — → cmn_department
3. Users — → sys_user, referencing location and department
4. Groups — → sys_user_group and group membership → sys_user_grmember
5. Knowledge Base structure — → kb_knowledge_base and kb_category
6. Knowledge articles — → kb_knowledge
7. CMDB CI classes — → cmdb_ci subclasses, starting with parent CIs
8. CMDB relationships — → cmdb_rel_ci
9. Assets — → alm_asset, linked to CIs and users
10. Incidents — → incident, referencing users, groups, CIs
11. Service Requests — → sc_request + sc_req_item
12. Problems — → problem, linking related incidents
13. Changes — → change_request
14. Comments / journal entries — → sys_journal_field, linked by element_id
15. Attachments — → sys_attachment, linked to parent records

Capture the newly generated ServiceNow sys_id for every record and map it back to the legacy SolarWinds ID in your lookup table. Use the Identification and Reconciliation Engine (IRE) when loading CIs to prevent duplicates — IRE matches incoming CIs against existing records using identifier rules you configure (typically serial number, name + class, or a custom correlation ID).

import requests
import time
import random
 
def backoff_with_jitter(attempt, base=2, max_wait=120):
    wait = min(base ** attempt + random.uniform(0, 1), max_wait)
    return wait
 
def load_import_set_chunk(records, target_table, instance, auth):
    url = f"https://{instance}.service-now.com/api/now/import/{target_table}/insertMultiple"
    headers = {"Content-Type": "application/json", "Accept": "application/json"}
 
    chunk_size = 200
    for i in range(0, len(records), chunk_size):
        chunk = records[i:i + chunk_size]
        # Cast all values to strings per ServiceNow Import Set requirements
        sanitized = [{k: str(v) if v is not None else "" for k, v in r.items()} for r in chunk]
        attempt = 0
        while attempt < 5:
            response = requests.post(url, auth=auth, headers=headers, json={"records": sanitized})
            if response.status_code == 429:
                time.sleep(backoff_with_jitter(attempt))
                attempt += 1
                continue
            if response.status_code in [500, 502, 503]:
                time.sleep(backoff_with_jitter(attempt))
                attempt += 1
                continue
            break
        log_response(response)

429 handling is not optional. ServiceNow documents rate-limit response headers and retry behavior, so your loader should treat throttling as normal control flow, not as a surprise outage. (servicenow.com)

Step 5: Rebuild Relationships

After loading primary records, use the ID lookup table to:

• Link incidents to parent problems
• Associate CIs with incidents, problems, and changes via cmdb_rel_ci
• Connect service requests to their parent request records
• Map user assignments (caller, assigned_to, resolved_by)

Step 6: Validate

Run record count reconciliation for every object type. See the validation section below for the full testing protocol.

Step 7: Run Delta Sync and Cut Over

Extract records created or modified after the initial bulk migration using the updated_at filter on SolarWinds API endpoints (e.g., ?updated_at_gte=2026-07-01T00:00:00Z). Load the delta set into ServiceNow — coalesce fields on your transform maps ensure existing records are updated rather than duplicated. Validate counts, then switch agent operations and email routing to ServiceNow.

Timeline, Phases, and Risk Register

A realistic timeline depends on record volume and CMDB complexity, not raw row count alone.

Use a phased rollout when multiple departments share the desk or when service catalog logic is deep. Use a big-bang cutover when one central team owns the desk and the workflow model is simple. Use a delta model when the desk runs 24/7. Our zero-downtime help desk migration guide covers that pattern in detail.

Risk Register

Rollback Plan

Before go-live, take a full instance clone of your ServiceNow production instance to a sub-production environment. Instance cloning is preferred over XML exports for environments with more than 100,000 records because it captures the complete database state including attachments. ServiceNow instance cloning typically completes in 2–4 hours for mid-size instances.

Clone vs. XML export decision:

• Clone — use for full rollback scenarios. Restores the entire instance to the pre-migration state. Risk: if new post-cutover tickets were created in production after go-live, a clone restore will destroy them. Mitigate by exporting new post-cutover records before restoring.
• 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.

Keep SolarWinds Service Desk active in read-only mode for 30 days post-cutover so agents can reference the legacy system if critical data is missing. Coordinate SolarWinds contract termination timing: do not cancel your SolarWinds subscription until the 30-day validation window closes and all stakeholders have signed off on data completeness. If SolarWinds enforces a data retention policy upon account closure, export a final full backup before the account is deactivated.

What Agents and End Users Notice During Cutover

If you run a delta cutover, end users mostly notice new URLs, new ticket numbers, and a new portal experience. Agents notice more: new state vocabulary, new assignment logic, rebuilt catalog fulfillment, and a different Activity feed for historical comments.

Agent downtime is the biggest operational risk during cutover. A delta migration syncs only the records created or modified since the initial bulk load. This allows agents to work in SolarWinds on Friday and log into ServiceNow on Monday with all weekend tickets fully synced.

Preserving resolution history matters for compliance and agent context. Auditors require proof of exactly who approved a change request and when. If your migration collapses old comments into a single description field, you lose chronology and make audit review harder. Historical SLA metrics are only meaningful if the underlying incident lifecycle data is intact. Load SolarWinds comments as sys_journal_field entries with original timestamps — public replies as comments, internal analyst history as work_notes.

Searchability is the test many teams forget. Agents should be able to find migrated records by legacy ticket number, requester, CI, and article title within ServiceNow. Store the legacy SolarWinds ticket number in the correlation_id field on the incident table and create a list view column for it. If agents cannot search and find migrated records within the first hour, they will lose confidence in the migration regardless of data completeness.

Edge Cases and Known Limitations

Every SolarWinds-to-ServiceNow migration hits edge cases. Plan for these specifically.

Multi-Level CMDB Dependencies

SolarWinds Service Desk CMDB uses a parent/child CI hierarchy with dependency links. ServiceNow stores CI relationships in the cmdb_rel_ci table using typed relationships (e.g., "Runs on", "Depends on", "Used by"). Each SolarWinds dependency link must be mapped to a specific ServiceNow relationship type. If your SolarWinds CMDB has 4+ levels of nested dependencies, plan for a dedicated CMDB mapping phase that adds 1–2 weeks to the timeline.

If a SolarWinds asset does not fit a predefined ServiceNow CI class, you must extend the CMDB schema by creating a new CI class that inherits from an appropriate parent class (e.g., extend cmdb_ci_hardware for a custom hardware type). Do not dump every CI into generic cmdb_ci unless you are intentionally archiving legacy data with no ongoing management need.

After loading CMDB data, use the CMDB Health Dashboard (navigate to Configuration > CMDB Dashboard in ServiceNow) to validate CI completeness, relationship integrity, and orphan detection. The Health Dashboard scores CIs on completeness (required fields populated), compliance (CSDM alignment), and relationship health. Run this validation before declaring the CMDB migration complete.

Inline Images

Images pasted directly into SolarWinds ticket descriptions are hosted on SolarWinds servers. If you migrate the raw HTML, the image links will break when the SolarWinds instance is decommissioned. You must programmatically download these images, upload them to ServiceNow via the Attachment API, and rewrite the HTML src tags in the ticket body to point to the new ServiceNow attachment URLs. Regex pattern to identify SolarWinds-hosted images: src="https://[^"]*samanage [^"]*".

Attachments

SolarWinds attachments are accessible via the API as downloadable URLs on incident, problem, and change records. ServiceNow stores attachments as chunked binary data in sys_attachment and sys_attachment_doc tables (4KB chunks). Each attachment must be downloaded from SolarWinds and uploaded to ServiceNow via the Attachment API. The ServiceNow inbound REST payload limit means attachments above the configured threshold must be uploaded using the binary file upload endpoint (Content-Type: application/octet-stream) rather than base64-encoded JSON payloads.

Orphaned Records and Duplicates

Common data quality issues in SolarWinds exports:

• Duplicate users created by email address variations. Deduplicate before load by normalizing email to lowercase and choosing the most recent active record.
• Orphaned incidents referencing deleted users or groups. Assign these to a "Migration Archive" user in ServiceNow with a note in the work_notes field indicating the original assignee was deleted in the source system.
• Inconsistent category values caused by renamed categories mid-lifecycle. Build a normalization map before creating sys_choice entries. Example: "Network Issue" and "Network Issues" should resolve to a single value.

ServiceNow Transform Map Failures

The Import Set API's insertMultiple method processes asynchronously by default and may not provide meaningful error feedback in the response. To get transform results, configure synchronous processing: navigate to sys_rest_insert_multiple, find the record for your import set table, and set the synchronous field to true. Monitor the sys_import_set_run table for row-level error details — each failed row gets a status of error with a message column describing the failure. Common failure causes: reference field pointing to a non-existent record, field type mismatch, and mandatory field violations.

Validation and Testing Protocol

A migration is only done when the numbers match. Do not rely on total record counts alone — a count might match while reference fields are completely empty.

Record count reconciliation. Compare total record counts per object type between SolarWinds (from your extraction X-Total-Count headers) and ServiceNow (query each target table with sysparm_count=true). Allow 0% variance tolerance for incidents, users, and CIs. Document any intentional exclusions (e.g., test records, spam tickets).

Field-level spot checks. Sample 50–100 records per object type. Verify every mapped field contains the correct value, especially reference fields (Caller, Assignment Group), timestamps, state, and priority. Use a spreadsheet that maps SolarWinds record ID → ServiceNow sys_id → field-by-field comparison.

Relationship integrity. Confirm that CI-to-incident links, problem-to-incident links, and user group memberships are intact. Query cmdb_rel_ci to verify CMDB relationship counts match the source. Run SELECT count(*) FROM cmdb_rel_ci WHERE parent IS NULL OR child IS NULL to find orphaned relationships.

Attachment verification. Compare attachment counts and byte sizes for a random sample of 50 records. Download and open 10–20 attachments to confirm they are not corrupted or zero-byte.

Comment thread order. Verify that journal entries on migrated incidents appear in correct chronological order with accurate author attribution. Check 20 incidents with 5+ comments each.

Knowledge Base validation. Confirm articles retain formatting and that internal links point to the new ServiceNow URLs. Verify that KB articles are associated with the correct knowledge base and category.

CMDB Health Dashboard. Run the CMDB Health Dashboard after CI and relationship loading. Target a completeness score above 80% and zero orphaned relationships.

UAT with agents. Have 3–5 IT agents perform their standard triage workflow on migrated tickets. Confirm they can view history, add notes, search by legacy ticket number (via correlation_id), and resolve tickets without issues. Document any usability gaps.

For a comprehensive post-migration testing framework, see our help desk migration QA checklist.

Build In-House vs. Use a Managed Service

Build In-House When:

• You have fewer than 50,000 total records across all objects
• Your CMDB is flat or has one level of CI hierarchy
• You have a ServiceNow developer on staff who understands Import Sets, Transform Maps, and coalesce configuration
• You can tolerate a 24–48 hour maintenance window for cutover
• No regulatory audit trail requirements
• Engineering team can dedicate 150–250 hours without impacting product delivery

Use a Managed Service When:

• You have 100,000+ records or a multi-level CMDB with custom CI types
• Zero downtime is a requirement (24/7 IT operations)
• You need to preserve comment timestamps and original author attribution for audit compliance
• Your team cannot absorb 4–8 weeks of engineering time without impacting product work
• Compliance requires a documented chain of custody for migrated data
• You have 50,000+ attachments requiring binary download, upload, and re-linking

The primary risk of DIY is not the initial build — it is the 2–3 re-migration cycles caused by broken references, missed edge cases (inline images, coalesce misconfiguration, transform map async behavior), and errors not caught until agents work in the new system. Each re-migration cycle adds 1–2 weeks.

Frequently Asked Questions

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 — most teams need 2–3 test rounds.

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 (import_set_loader, admin) to override sys_created_on and sys_created_by fields. Each comment becomes a separate journal entry linked by element_id to the parent record's sys_id.

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 (IRE) to prevent duplicate CIs. After loading, validate with the CMDB Health Dashboard. Without strict load ordering, CMDB data will load but relationships will be lost.

How much does a SolarWinds Service Desk to ServiceNow migration cost?

A DIY API-based migration for a small environment (under 50,000 records) costs primarily in engineering time — typically 150–250 hours of developer effort at your internal rate. Managed migration services for enterprise environments with CMDB and attachments typically range from $10,000 to $50,000+ depending on record volume, CMDB complexity, and compliance requirements. Native CSV exports are free but risk significant data loss on attachments, comments, and relationships.

Do I need ServiceNow ITSM Pro for this migration?

Not for the data migration itself. ITSM Standard supports Import Sets, Transform Maps, and the Table/Attachment APIs. However, if your post-migration workflow design depends on Flow Designer (beyond basic flows), the Identification and Reconciliation Engine, or CSDM alignment tools, you need ITSM Pro or Enterprise. Verify your license tier before designing post-migration workflows.

When should I cancel my SolarWinds Service Desk subscription?

Keep SolarWinds active in read-only mode for at least 30 days after cutover. This gives agents a fallback reference and provides a safety net for data validation. Do not cancel until all stakeholders have signed off on data completeness. If SolarWinds enforces data deletion upon account closure, perform a final full data export before deactivation.