SolarWinds Service Desk to InvGate Service Management Migration Guide

SolarWinds Service Desk to InvGate Service Management Migration Guide

A SolarWinds Service Desk (SWSD) to InvGate Service Management migration moves your ITSM data — incidents, problems, changes, service requests, users, groups, knowledge articles, attachments, and custom fields — between two ITIL-aligned platforms. Because both systems share ITIL DNA, the core data model mapping is closer than most ITSM migrations. The safe pattern is: extract via the SWSD REST API (api.samanage.com), transform into InvGate's request-centric schema, load via InvGate's REST API, then run a delta cutover for records created during migration.

Why Teams Move from SolarWinds Service Desk to InvGate

The most common drivers for this migration path:

• Cost structure. InvGate Service Management is offered at tiered per-agent pricing (verify current rates at invgate.com/pricing, as pricing changes periodically). SWSD pricing has historically been higher for comparable feature sets, especially once you factor in add-on modules.
• Deployment flexibility. InvGate supports both cloud and on-premise deployment. SWSD is cloud-only. Organizations with data residency requirements or air-gapped environments need the on-prem option.
• Workflow builder. InvGate's visual, no-code workflow builder supports multi-stage approval chains, conditional branching, parallel paths, and native connectors for Microsoft Entra ID. SWSD's automation rules are more constrained — trigger-action patterns without multi-step orchestration. (documentation.solarwinds.com)
• AI features. InvGate has invested in AI-powered ticket summarization, suggested responses, sentiment analysis, and a virtual agent for Microsoft Teams and WhatsApp.
• Vendor trajectory. SolarWinds has shifted strategic focus toward its observability and security portfolio. Some IT leaders prefer a vendor whose primary product is the service desk.

The trade-off is easy to miss: InvGate can be a cleaner fit for visually managed workflows and tighter alignment with InvGate Asset Management, but SWSD's existing CMDB and hardware relationships do not become native InvGate CIs by default. If you are not implementing the asset side in parallel, plan for an archive or reference-only treatment of that data. (documentation.solarwinds.com)

For a broader comparison of SWSD migration targets, see our SolarWinds Service Desk to ServiceNow migration guide, our SWSD to Dixa migration guide, and our detailed data export methods guide.

Data Model Mapping: SWSD → InvGate Service Management

This is an ITIL-to-ITIL move. Most core objects have a direct counterpart.

What Doesn't Transfer

• SLA clock history and compliance data. InvGate tracks its own SLA metrics from the moment records are created. Historical SLA compliance percentages from SWSD don't carry over.
• Audit logs. SWSD audit trails are platform-internal and not exportable via API.
• Dashboard and report configurations. Must be rebuilt in InvGate's analytics module.
• Email templates and notification rules. InvGate has its own notification engine; SWSD templates don't map.
• Approval workflow state. Active approvals in-flight during migration will lose their state. Close or complete them before cutover.
• Automation rules and triggers. SWSD automation rules cannot be exported via API. They must be rebuilt intentionally in InvGate's workflow builder.

Extracting Data from SolarWinds Service Desk

SWSD exposes a REST API at api.samanage.com (US region), apieu.samanage.com (EU), or apiau.samanage.com (APJ). Authentication uses a Bearer token (JSON Web Token) generated from Setup → Users & Groups → [Your Name] → Action → Generate JSON Web Token. Only a Service Desk administrator can generate a token, and SolarWinds requires TLS 1.2 or higher for transport. (documentation.solarwinds.com)

Pagination and Rate Limits

SWSD uses offset-based pagination with page and per_page parameters. The response includes X-Total-Count, X-Total-Pages, and Link headers for navigation. Rate limits are plan-based: Advanced plans allow 1,000 calls/minute and Premier plans allow 1,500 calls/minute. (apidoc.samanage.com)

Build resumable extraction with exponential backoff for 429 or 503 responses — not firehose loops.

# Paginated incident extraction
curl -s "https://api.samanage.com/incidents.json?page=1&per_page=100" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/vnd.samanage.v2.1+json" | jq '.'

SWSD also supports layout=short and layout=long parameters; the long layout exposes richer record detail including nested comments and attachments. (apidoc.samanage.com)

Extraction Order

Extract entities in dependency order to preserve relationships:

1. Users — GET /users.json
2. Groups / Departments — GET /groups.json, GET /departments.json
3. Categories — GET /categories.json
4. Solutions (KB) — GET /solutions.json
5. Incidents — GET /incidents.json
6. Problems — GET /problems.json
7. Changes — GET /changes.json
8. Service Requests — GET /service_requests.json
9. Assets / Hardware — GET /hardwares.json (if migrating to InvGate Asset Management)

For each record type, paginate until you receive an empty response or fewer than per_page results. Store raw JSON with the original SWSD IDs — you'll need them for relationship mapping.

Rich Text and Inline Images

SWSD stores ticket descriptions and comments as HTML. When users paste images directly into the text editor, SWSD stores them as inline base64 strings or hosted image links requiring authentication.

If you migrate authenticated image URLs directly into InvGate, they will appear as broken links to anyone not logged into the legacy SWSD instance. Your middleware must parse the HTML, download the images, upload them to InvGate as attachments, and rewrite the <img> tags in the HTML payload to point to the new InvGate URLs.

Loading Data into InvGate Service Management

InvGate Service Management exposes a REST API documented at https://[your-instance].cloud.invgate.net/public-api/swagger/v2/ (cloud) or via the on-premise equivalent. The API supports CRUD operations across all core entities — but enforces strict referential integrity. You cannot create a request without valid customer_id, creator_id, and category_id references. (releases.invgate.com)

InvGate API throughput observed in practice: At a sustained rate of 2–3 API calls/second with ~200–400ms mean response times under normal load, a migration of 100,000 ticket records (excluding attachments) requires approximately 9–14 hours of continuous API activity. Attachment uploads are the dominant time variable — a 500 GB attachment corpus will add days, not hours. Coordinate with InvGate support before starting large migrations to confirm your instance's concurrency limits and whether they can temporarily raise rate ceilings for the migration window. There is no published bulk-import endpoint in the public API.

Load Order

1. Companies — POST /companies with name and optional external_id
2. Groups — POST /groups with name, then POST /groups.users to assign members
3. Locations — POST /locations with name and optional parent_id
4. Users — POST /user with email, name, lastname (all required). Match on email to deduplicate against AD/SCIM-synced users.
5. Categories — POST /categories with parent-child hierarchy via parent_category_id
6. Custom Fields — Pre-create all field definitions in the admin UI; capture the uid for each field; populate allowed values via API.
7. KB Articles — POST /kb.articles with title, content, author_id, category_id
8. Requests — POST /incident with required fields (see below)
9. Comments — POST /incident.comment with request_id, author_id, comment, and customer_visible
10. Custom Field Values — POST /incident.custom_field per request
11. Attachments — Upload via the request attachment mechanism
12. Request Links — POST /incident.link to restore problem-to-incident and related-ticket relationships

InvGate Help Desk Levels: InvGate's routing model is organized into help desks — logical groupings that define agent assignment pools, visibility rules, and SLA applicability. Each request must be assigned to a help desk. Within a help desk, levels (e.g., Level 1, Level 2) define escalation tiers. You must create help desks and their levels before importing any requests, because helpdesk_id is a required or implicitly required field depending on your instance configuration. If you import requests without a valid help desk assignment, routing and SLA rules will not fire correctly.

// Example: creating a request with preserved original date
POST /incident
{
  "title": "VPN outage for remote users",
  "customer_id": 4811,
  "creator_id": 12,
  "category_id": 77,
  "type_id": 1,
  "priority_id": 3,
  "date": "1726761600",
  "description": "<p>Imported from SWSD #12345</p>"
}

type_id reference: 1=Incident, 2=Service Request, 3=Question, 4=Problem, 5=Change, 6=Major Incident

priority_id reference: 1=Low, 2=Medium, 3=High, 4=Urgent, 5=Critical

Preserving Original Timestamps

InvGate's POST /incident endpoint accepts a date parameter (epoch format) that sets the "occurred on" date. This preserves the original SWSD creation date in the record's reported date field. However, created_at in InvGate is system-generated and will reflect the actual import time — it is not writable via the public API.

If exact original-creation-date visibility is a reporting requirement, store the SWSD original created_at in a dedicated custom field (e.g., legacy_created_at).

For comments, POST /incident.comment does not expose a writable created_at. Comments carry the timestamp of when they were imported. Because you cannot override this, import comments in ascending chronological order within each request — this ensures that even though all comment timestamps reflect import time, the ordering within the ticket is correct.

If your instance does not support timestamp overrides at all, prepend the original metadata to the ticket description as a standard migration practice:

<p><strong>Legacy ID:</strong> INC-10455</p>
<p><strong>Original Creator:</strong> Jane Doe</p>
<p><strong>Original Date:</strong> 2023-10-12 14:32:00</p>
<hr>
<p>Original ticket description goes here...</p>

InvGate Pagination Differences

InvGate does not use a single pagination model across all endpoints. Some endpoints use offset and limit parameters; detailed view exports use next_page_key cursor pagination with up to 1,000 requests per page; /users.by returns 10 objects per page by default and excludes disabled users unless you add include_disabled=true. Your importer must implement endpoint-specific pagination logic — a single generic paginator will silently miss records on endpoints that use a different model. (releases.invgate.com)

Custom Field Migration: The Hidden Complexity

Custom fields are where most SWSD-to-InvGate migrations stall. The table below maps every SWSD custom field type to its closest InvGate equivalent and flags where the match is imperfect.

List-type fields in InvGate use a key-value structure managed via /cf.field.options.list. You must:

1. Create the custom field definition in InvGate (via admin UI only — there is no public API endpoint to create field definitions)
2. Populate the allowed values via POST /cf.field.options.list with uid, type: "key-value", and a key_values dictionary
3. Set the value per request via POST /incident.custom_field

Tree-type fields add hierarchy. InvGate's /cf.field.options.tree endpoint supports parent_hash for nesting. If your SWSD custom fields use cascading selects, tree-type fields are the closest equivalent.

Critical gotcha — UID stability: InvGate custom field UIDs are integers assigned at creation time. If you delete and recreate a field during testing, the UID changes and your mapping table becomes stale. Lock down custom field definitions after your first test migration pass and do not recreate them. There is no "upsert by name" — only by UID.

Critical gotcha — category scoping: Custom fields in InvGate are scoped to categories. If you create fields without assigning them to the correct categories, records will pass API validation but behave incorrectly in the UI and in workflow logic. Assign category scope to every custom field during initial setup, before importing any records. (releases.invgate.com)

The ITAM Split: Service Management vs. Asset Management

SolarWinds Service Desk handles both tickets and assets within a single platform — you query /incidents.json for tickets and /hardwares.json for assets against the same API.

InvGate splits these into two products: InvGate Service Management (ITSM) and InvGate Asset Management (ITAM). They integrate natively — requests can be linked to CIs — but asset data lives in ITAM with its own API surface, its own data model, and its own import requirements.

This means what appears to be one migration is actually two migrations running in parallel:

Migration 1: SWSD tickets → InvGate Service Management Migration 2: SWSD hardware/CMDB → InvGate Asset Management

These migrations have a hard sequencing dependency: you must complete the asset migration and capture the new InvGate Asset Management CI IDs before you can load tickets with valid CI references into Service Management. If you load tickets first, CI relationships will be null or broken and cannot be retroactively bulk-corrected via API.

If you are not implementing InvGate Asset Management in parallel, declare that decision explicitly and early. The practical fallback is to store SWSD asset references as custom field values on the migrated tickets — this preserves the association as readable metadata without requiring a live CI link. Scope the ITAM migration separately from the ITSM migration with its own timeline, resource allocation, and acceptance criteria.

Step-by-Step Migration Execution

Step 1: Audit and Inventory SWSD

Pull counts and samples for incidents, problems, changes, releases, solutions, users, groups, and hardware/CI data. SWSD exposes distinct API surfaces for each of these objects. Decide early which ones are live migration scope versus archive-only. Document all custom fields, automation rules, and SLA policies. For deeper export mechanics, see our SolarWinds export guide.

Step 2: Build the InvGate Target Environment

Create your InvGate instance, configure SSO and AD/SCIM user sync, then build the full taxonomy before importing any records:

• Help desks and their levels (InvGate's routing model requires a valid help desk assignment on every request — see the Help Desk Levels definition above)
• Categories with parent-child hierarchy
• Groups and companies
• Locations
• All custom field definitions with their allowed values, scoped to the correct categories
• KB categories

InvGate enforces referential integrity. Every entity you will reference in an import API call must exist before that call is made.

Step 3: Migrate Users and Groups

Extract all users from SWSD (/users.json). Push them into InvGate. Capture the new InvGate User IDs and map them against the old SWSD User IDs — every subsequent API call requires these new IDs.

When reconciling users, check for existing users by email (GET /user.by?email=...) before creating new ones. If InvGate is synced to AD/SCIM, creating users via API will produce duplicates. InvGate's /users.by endpoint excludes disabled users unless you add include_disabled=true. For former employees whose tickets must be preserved, create placeholder end-user accounts with the original email address rather than collapsing their history into a generic mailbox.

Step 4: Migrate CMDB to InvGate Asset Management

If you're migrating assets: extract Hardware, Software, and Other Assets from SWSD (/hardwares.json, /softwares.json, /other_assets.json). Transform to match InvGate Asset Management's CI schema. Push to Asset Management. Store the mapping of SWSD Asset IDs to new InvGate Asset Management CI IDs — you'll need this when importing tickets that reference CIs.

Complete this step before importing tickets. CI relationships set during ticket import cannot be retroactively bulk-restored via the public API if the CI IDs don't exist at import time.

Step 5: Migrate Historical Tickets

For each ticket:

1. Transform the HTML body (handle inline images and authenticated URLs per the rich text section above)
2. Map the requester and assignee to InvGate User IDs (from your Step 3 ID mapping table)
3. Map the SWSD Category to the InvGate category_id
4. Map attached SWSD assets to new InvGate Asset Management CI IDs (from your Step 4 ID mapping table)
5. Download attachments from SWSD and upload to InvGate
6. POST the request payload to InvGate Service Management
7. Replay comments in chronological order (ascending by original timestamp), preserving customer_visible flag
8. Set custom field values via POST /incident.custom_field

Store the original SWSD ticket number and object ID in dedicated custom fields for traceability.

Step 6: Migrate Knowledge Base

Extract SWSD Solutions (/solutions.json). Create KB categories in InvGate via POST /kb.categories first, then push articles via POST /kb.articles.

InvGate KB articles accept:

• is_private: 0=public, 1=private
• status: 1=Published, 4=Draft, 5=Archived

Map SWSD draft/published states to the appropriate InvGate status value.

Pay attention to internal links: if Article A links to Article B in SWSD, that hyperlink must be rewritten to point to Article B's new URL in InvGate. Failing to do this produces a published KB with broken cross-references that are invisible during API import but obvious to users after launch.

Step 7: Rebuild Automations, SLAs, and Approval Workflows

This is the phase that takes the longest and cannot be automated.

SWSD automation rules (trigger → condition → action) must be manually recreated in InvGate. InvGate's workflow builder supports multi-stage processes, conditional branching, parallel paths, approval gates, and native connectors — but it is a fundamentally different paradigm from SWSD's trigger-action model. You are not porting rules; you are redesigning processes.

Practical approach:

1. Export your SWSD automation rules via the UI (no API endpoint exists for rule definitions). Screenshot or document each rule's trigger, conditions, and actions.
2. Prioritize by actual usage. Most tenants have 30–50 rules but only 10–15 fire regularly. Identify which ones have fired in the last 90 days before rebuilding any of them.
3. Rebuild from intent, not field names. For each rule, write a plain-language description: trigger, conditions, actors, approvals, side effects, notifications, SLA impact. Then build it in InvGate's workflow builder using that description as the specification. This approach preserves business behavior rather than legacy UI structure, and it exposes rules that nobody actually wants to keep.
4. Test with real tickets in a sandbox instance before cutover.

SLA policies must be rebuilt natively. InvGate's SLA model supports variation by service, priority, requester group, help desk, department, and workflow stage — which gives you more granularity than SWSD but requires deliberate configuration, not a port. (invgate.com)

For more on migrating automations, see our guide on automations, macros, and workflows.

Step 8: Run Test Migration and Validate

Load 500–1,000 records into a staging InvGate instance. Validate:

• Record counts by module and by open/closed state
• Field mapping accuracy across 50–100 spot-checked records
• Comments appear in correct chronological order
• Public vs. internal comment visibility (customer_visible) is correct
• Attachments are accessible and downloadable across multiple file types
• Requester, assignee, help desk, category, priority, and legacy ID on each sampled record
• KB keyword searches return imported articles with correct visibility and status
• If migrating assets, CI links work from the request view back into the InvGate Asset Management record
• Triggers, workflows, and SLA rules fire correctly on newly created requests

Fix all mapping errors before running the full migration. Run at least two test migrations — the second pass should produce zero new mapping errors.

Step 9: Delta Sync and Cutover

Historical migrations take days or weeks. During this time, your team is still working in SWSD. To achieve a zero-downtime cutover:

1. Run the full historical data load
2. Freeze SWSD (read-only or by policy — SWSD does not have a native read-only mode, so this is an operational agreement with your team)
3. Query the SWSD API using updated_since to fetch records created or modified since the initial extraction
4. Transform and load the delta into InvGate
5. Switch inbound email routing, portal traffic, and SSO authentication to InvGate
6. Smoke-test new request creation, comments, approvals, workflows, and search
7. Go live — Monday morning is the conventional choice for minimal disruption

Common Failure Modes

Migration Timeline

These estimates include extraction scripting, data mapping, custom field setup, 2–3 test migrations, workflow rebuild, UAT, and cutover.

Attachment volume is the dominant variable. At a sustained upload throughput of 5–10 MB/second (typical for cloud-to-cloud transfers), 100 GB of attachments requires 2.8–5.6 hours of transfer time alone, not counting the per-file API overhead of staging, uploading, and linking each attachment individually. A tenant with 50,000 incidents and 500 GB of attachments will take significantly longer than a tenant with 200,000 incidents and 10 GB of attachments.

DIY vs. Managed Migration

DIY is viable when:

• Total records < 50,000
• Custom fields are simple (text, single-select only)
• No CMDB/asset migration required
• You have an engineer who can dedicate 2–3 weeks full-time
• No compliance or audit requirements for the migration itself

Hire a migration partner when:

• Records exceed 100,000 or attachment volume exceeds 100 GB
• You have tree-type custom fields, multi-level categories, or complex approval chains
• You need to migrate CMDB data alongside service records
• Downtime tolerance is zero
• You need a documented, auditable migration trail for compliance

Making the Move Count

An SWSD-to-InvGate migration is one of the smoother ITSM moves because both platforms share ITIL DNA—unlike the structural transformation required for an AI platform like Ada or a conversation-first system like Kayako. The data model mapping is natural, the APIs on both sides are functional, and InvGate's workflow builder gives you room to improve processes during the transition rather than just replicate them.

The work that trips teams up isn't the data transfer itself. It's the custom field setup (UID management and category scoping), the workflow rebuild (redesigning from intent, not copying trigger syntax), and the user deduplication against directory services. Get those three right in your first test migration and the rest follows.

The ITAM split is the other major scope risk. If you're migrating asset data, treat it as a parallel workstream with its own timeline — not an afterthought to the ticket migration.

If you want more prep material before touching production, start with our best practices for help desk data migration and help desk data migration checklist.