SolarWinds Service Desk to Salesforce Service Cloud Migration Guide

SolarWinds Service Desk to Salesforce Service Cloud Migration Guide

Migrating from SolarWinds Service Desk (SWSD) to Salesforce Service Cloud means converting an ITIL-centric service management platform — built on the Samanage data model — into Salesforce's object-relational architecture centered on Cases, Accounts, Contacts, and the Lightning file system. This is not a lift-and-shift. SWSD stores incidents, problems, changes, releases, assets, CMDB configuration items, users, groups, and knowledge articles in a flat REST-accessible model with shallow nesting. Salesforce stores support data across a deep object graph: Account → Contact → Case → EmailMessage → ContentDocumentLink → ContentVersion. Every record relationship must be explicitly rebuilt using external ID matching.

The proven pattern: extract from SWSD via the Samanage REST API, transform and stage in an intermediate data store, load into Salesforce using Bulk API 2.0, rebuild relationships via external ID matching, then run a delta sync for records created during the migration window.

Why Teams Migrate from SolarWinds Service Desk to Salesforce Service Cloud

The move is typically driven by platform consolidation and capability gaps, not dissatisfaction with basic ticketing. While teams looking for a simpler external support model might migrate from SolarWinds Service Desk to Enchant, enterprises move to Salesforce to unify their CRM and support data. When sales, account management, and external customer support are already on Salesforce, keeping internal IT or specialized support in a siloed SWSD instance creates visibility gaps and redundant data syncing.

Common drivers:

• CRM unification. Organizations already running Salesforce Sales Cloud want support data in the same org. Having Cases, Accounts, Contacts, and Opportunities in one platform eliminates cross-system syncing and gives agents full customer context without switching tools. A customer issue logged by Sales can transition to an IT incident without webhook integrations.
• Advanced case routing. SWSD supports basic assignment rules. Salesforce Omni-Channel provides skills-based routing, capacity-based assignment, and presence-aware distribution across channels (email, chat, phone, messaging).
• Entitlement and SLA management. SWSD has SLA management, but Salesforce Entitlements and Milestones offer multi-tier SLA structures with per-customer and per-product entitlement rules — critical for B2B support organizations managing different contractual SLAs per account.
• Automation depth. Salesforce Flow supports complex branching, subflows, scheduled paths, and platform events — substantially beyond SWSD's trigger-action rule model. Einstein for Service adds case classification, recommended replies, and knowledge suggestions natively without additional configuration.
• Custom object extensibility. While SWSD allows custom fields, Salesforce allows entirely custom relational objects with their own page layouts, validation rules, and API access — making it easier to build bespoke asset tracking or compliance modules that integrate natively with Cases.
• Reporting consolidation. Teams want support metrics in the same reporting layer as sales and marketing data. Salesforce Reports, Dashboards, and CRM Analytics provide this without third-party BI connectors.
• Scale constraints. SWSD works well for small-to-mid IT teams. Organizations growing past several hundred agents or managing external customer support alongside internal ITSM often hit workflow and customization ceilings.

Data Model Mapping: ITSM to Service Cloud

Understanding the structural gap between these two platforms is the single most important step before writing any migration code. Salesforce Service Cloud is historically a Case management system built for customer support. The Salesforce Customer Service Incident Management (CSIM) feature — generally available as of Spring '23 (API version 57.0) and included with Service Cloud licenses at no extra cost — adds native Incident, Problem, and ChangeRequest standard objects for organizations requiring strict ITIL object separation. Most migrations still land on Cases because the Case object has deeper ecosystem support across Entitlements, Omni-Channel, and AppExchange integrations.

The CaseComment vs. EmailMessage Decision

This is where most SolarWinds-to-Salesforce migrations silently lose data.

CaseComment stores plain text only. The standard CommentBody field has a 4,000-character limit (Salesforce CaseComment object reference). If your SWSD incident comments contain HTML formatting, inline images, or long technical notes, CaseComment will truncate or strip that content without warning during the load.

EmailMessage supports HTML via the HtmlBody field, accommodating up to 131,072 characters for inbound email bodies (Salesforce EmailMessage object reference). Set Incoming = true for customer messages and Incoming = false for agent replies. This preserves rich formatting, inline images, and long messages. The trade-off: EmailMessage requires Email-to-Case to be enabled in your org, and it adds structural complexity to the load.

Recommendation: Use EmailMessage for all public-facing correspondence and CaseComment only for internal notes. This prevents silent data truncation and keeps the Case Feed readable. If you use CaseComment for everything, expect data loss on any comment exceeding 4,000 characters — and SWSD incident descriptions regularly exceed this in technical environments.

Mapping Users and Requesters

SWSD Requesters must be mapped to Salesforce Contact records, while SWSD Assignees (Agents) map to Salesforce User records.

How to Export Data from SolarWinds Service Desk

SWSD offers two extraction paths: CSV export from the UI and the Samanage REST API. The Samanage REST API is documented at https://api.samanage.com/.

CSV Export (UI)

You can export incidents, problems, changes, users, and assets to CSV directly from the index pages. This works for quick audits but has hard limits:

• No relational context — you get flat rows, not parent-child links
• Comments and attachments are not included in CSV exports
• Cells with over 32,767 characters cause misaligned rows in Excel
• No attachment binary data

CSV export is useful for record counts and field inventory. It is not a reliable migration source.

Samanage REST API (Recommended)

The API is the only reliable extraction path for a complete migration. Key constraints:

• Base URL: https://api.samanage.com/
• Authentication: Bearer token generated from the SWSD Admin portal under API Settings. Tokens are scoped to admin-level accounts only.
• Pagination: Page-based, maximum 200 records per page. No cursor-based pagination. Use page and per_page query parameters.
• Rate limits: Not publicly documented by SolarWinds. In practice, throttle to 2–3 requests per second and implement exponential backoff on 429 responses. This is an empirical safe threshold, not a guaranteed limit.
• API access tiers: API access requires the SWSD Advanced or Premier plan. Confirm your license level before starting extraction.

Core endpoints for extraction:

GET /incidents.json?per_page=200&page=1
GET /incidents/{id}/comments.json
GET /incidents/{id}/attachments.json
GET /problems.json?per_page=200&page=1
GET /changes.json?per_page=200&page=1
GET /users.json?per_page=200&page=1
GET /groups.json
GET /hardwares.json           # Assets
GET /configuration_items.json # CMDB CIs
GET /solutions.json           # Knowledge articles
GET /categories.json

Extraction Script Pattern

import requests
import time
import json
 
BASE_URL = "https://api.samanage.com"
TOKEN = "your-bearer-token"
HEADERS = {
    "X-Samanage-Authorization": f"Bearer {TOKEN}",
    "Accept": "application/json"
}
 
def extract_all(endpoint, params=None):
    records = []
    page = 1
    while True:
        resp = requests.get(
            f"{BASE_URL}/{endpoint}",
            headers=HEADERS,
            params={"per_page": 200, "page": page, **(params or {})}
        )
        if resp.status_code == 429:
            time.sleep(int(resp.headers.get("Retry-After", 5)))
            continue
        resp.raise_for_status()
        batch = resp.json()
        if not batch:
            break
        records.extend(batch)
        page += 1
        time.sleep(0.4)  # ~2.5 req/sec
    return records
 
incidents = extract_all("incidents.json")
users = extract_all("users.json")

For each incident, you need a second pass to extract comments and attachments by incident ID — approximately 2–3 API calls per incident for full data extraction. On a dataset of 50,000 incidents, that yields roughly 150,000 API calls. At 2.5 requests/second with a 0.4-second sleep, extraction runs approximately 16–17 hours. Budget accordingly.

For large datasets (100,000+ records), offset pagination degrades in performance as page numbers increase because the API must skip progressively more records server-side. To mitigate this, use time-windowed extraction: query records in date-range chunks using created_at or updated_at filters to keep page numbers low throughout the run.

Preparing Salesforce for Ingestion

Before loading a single record into Salesforce, you must prepare the environment. Skipping this phase causes governor limit exceptions, API timeouts, invalid cross-reference errors, and corrupted data that is difficult to clean up after the fact.

Create External ID Fields

The key to maintaining referential integrity across the load sequence is external ID fields. Create these custom fields before migration begins and mark each as both External ID and Unique in Salesforce Setup:

External ID fields allow you to use the Salesforce UPSERT operation and resolve relationships (such as assigning a Case to a Contact) using the SWSD source ID in your CSV, rather than querying for newly generated Salesforce 18-character record IDs. During the delta sync, UPSERT against the external ID ensures records are created or updated correctly without duplicates. Without external IDs, you must perform two-pass loading: insert records in one batch, query back their Salesforce IDs, then insert child records referencing those IDs — a significantly slower and more error-prone process.

Enable Audit Field Permissions

Disable Automations Before Loading

Salesforce evaluates every inserted record against all active automations. Loading 100,000 historical tickets with active Flows and email alerts will fire those automations 100,000 times — potentially sending thousands of unwanted "Case Created" notifications to customers.

Before loading, temporarily disable:

• Apex Triggers (deactivate via Setup → Apex Triggers)
• Record-Triggered Flows (deactivate via Setup → Flows)
• Workflow Rules
• Validation Rules (historical data frequently violates current business rules that didn't exist when records were created)
• Email Deliverability (set to "No Access" in Setup → Deliverability)

Loading Data into Salesforce via Bulk API 2.0

For any volume over 2,000 records, use Bulk API 2.0. It is designed for asynchronous batch processing and handles internal chunking automatically. The Salesforce Bulk API 2.0 developer documentation covers job creation, status polling, and result retrieval in detail (Salesforce Bulk API 2.0 Guide).

Required Load Order

Data must be loaded in dependency order to satisfy foreign key constraints. Loading out of sequence generates INVALID_CROSS_REFERENCE_KEY errors that require re-processing entire batches:

1. Accounts — Create Account records for organizations. Map SWSD site or department to Account.
2. Contacts — Create Contact records linked to Accounts. Map SWSD requester users. Store the SWSD user ID in SWSD_User_Id__c.
3. Users — Provision Salesforce Users for agents/technicians. Requires licenses; cannot be done via Bulk API — use standard User provisioning through Setup or the SOAP-based User object.
4. Queues — Create Queues to match SWSD groups. This is a Setup operation, not a data load.
5. Assets/CIs — Load CMDB data.
6. Cases — Load Cases with ContactId, AccountId, and OwnerId references resolved via external ID matching.
7. CaseComments / EmailMessages — Load child records linked to Cases via ParentId.
8. ContentVersion + ContentDocumentLink — Upload file binaries via REST, then insert ContentDocumentLink records to attach them to Cases.
9. Knowledge Articles — Load via the Knowledge REST API if in scope.

Bulk API 2.0 Limits Reference

Source: Salesforce Bulk API 2.0 Limits

Preventing Row Lock Errors

When inserting Cases that reference the same parent Account or Contact, Salesforce locks the parent record to recalculate roll-up summary fields. If multiple parallel Bulk API batches insert Cases linked to the same Account concurrently, you will encounter UNABLE_TO_LOCK_ROW errors on some records.

Prevention strategies:

1. Sort your CSV files by AccountId or ContactId (the external ID column) before upload. This causes Salesforce to process Cases sharing a parent in the same internal batch, reducing inter-batch contention.
2. If sorting is insufficient for your data distribution, switch the Bulk API job from Parallel to Serial processing mode by setting lineEnding: CRLF and concurrencyMode: Serial in the job creation request. Serial mode eliminates row lock contention at the cost of significantly slower throughput — use it as a last resort.

SOQL Validation Queries

After each load phase, verify record counts before proceeding to the next phase:

-- Verify Cases loaded
SELECT COUNT() FROM Case WHERE SWSD_Incident_Id__c != null
 
-- Verify Contact relationships resolved
SELECT COUNT() FROM Case WHERE SWSD_Incident_Id__c != null AND ContactId != null
 
-- Identify Cases with missing Contact references (load failures)
SELECT SWSD_Incident_Id__c, Subject, CreatedDate
FROM Case
WHERE SWSD_Incident_Id__c != null AND ContactId = null
LIMIT 200
 
-- Verify CaseComments loaded
SELECT COUNT() FROM CaseComment WHERE Parent.SWSD_Incident_Id__c != null
 
-- Verify attachments linked
SELECT COUNT() FROM ContentDocumentLink
WHERE LinkedEntityId IN (SELECT Id FROM Case WHERE SWSD_Incident_Id__c != null)

Field Mapping: Incidents to Cases

Every field requires an explicit mapping decision. Below is the core mapping table for SWSD Incidents to Salesforce Cases:

Handling CMDB and Assets

SWSD has a proper CMDB with configuration items organized in hierarchical types — servers, workstations, switches, software licenses — with defined relationships between CIs, incidents, problems, and changes.

Salesforce has a native Asset object, but it is designed for customer-facing product tracking (serial numbers, warranties, account relationships), not IT configuration management. The structural mismatch is significant:

Decision guidance:

• Fewer than 5 CI types, no deep hierarchies: Use the native Asset object with Record Types for Hardware, Software, and Network Device. Add custom fields for SWSD-specific attributes. This is a data migration, not a development project.
• 5–10 CI types with parent/child relationships: Use Asset with custom fields and the ParentId field for hierarchy. Plan for 2–4 weeks of configuration work beyond the core migration.
• 10+ CI types with multi-level dependencies or cross-CI relationship mapping: Require custom Salesforce objects. This pushes the engagement from a data migration into a platform design project. Scope and timeline separately.

For organizations with complex CMDB requirements, also evaluate whether Salesforce is the right long-term home for CMDB data. Many teams migrate incidents and knowledge to Salesforce while maintaining CMDB in a dedicated tool (ServiceNow, Device42, Lansweeper) with a lightweight API integration for CI-to-Case lookups, or they bypass Salesforce entirely and migrate from SolarWinds Service Desk to ServiceNow for unified ITSM.

Knowledge Base Migration

SWSD knowledge articles (called "Solutions") map to Salesforce Knowledge articles (KnowledgeArticleVersion). The Salesforce Knowledge REST API handles article creation and publication (Salesforce Knowledge REST API Reference).

Migration steps:

1. Enable Salesforce Knowledge in Setup → Knowledge Settings. This is a one-time, irreversible org configuration.
2. Create article Record Types on KnowledgeArticleVersion matching your SWSD knowledge categories.
3. Map fields: SWSD title → Title, body → custom Rich Text Area field, category → Salesforce Data Category assignments.
4. Create articles via REST API:

POST /services/data/v62.0/sobjects/Knowledge__kav
Content-Type: application/json

{
  "Title": "Article Title",
  "UrlName": "article-url-name",
  "Summary": "Short description",
  "Body__c": "<p>Article HTML content</p>"
}

5. Publish articles by calling the Knowledge publish action:

POST /services/data/v62.0/knowledgeManagement/articleVersions/masterVersions/{articleId}
Content-Type: application/json

{"publishStatus": "Online"}

Note: The Knowledge API requires the "Manage Articles" permission in addition to standard API access. Verify this is enabled for your integration user before starting the knowledge migration phase.

Migrating Attachments

Attachment migration is consistently the most complex and time-consuming phase of a help desk migration. SWSD stores attachment binaries in Amazon S3 and provides expiring download URLs via the API response payload.

Salesforce handles files using a three-object architecture (Salesforce Files and Content documentation):

1. ContentVersion — The actual file binary and version metadata.
2. ContentDocument — The parent container for all ContentVersion records (auto-generated on ContentVersion insert, cannot be created directly).
3. ContentDocumentLink — The junction object linking the ContentDocument to a specific Case, Incident, or other record.

The Attachment Migration Workflow

For each SWSD attachment:
1. Parse attachment URL from SWSD API response
2. Download binary to local/staging storage
3. POST to Salesforce ContentVersion (REST API, multipart form)
4. Query ContentDocumentId from newly created ContentVersion
5. INSERT ContentDocumentLink (LinkedEntityId = Case Salesforce ID, ContentDocumentId from step 4)

import requests
 
SF_BASE = "https://yourorg.my.salesforce.com"
SF_TOKEN = "your-salesforce-access-token"
SF_HEADERS = {"Authorization": f"Bearer {SF_TOKEN}"}
 
def upload_attachment(file_path, file_name, case_id):
    # Step 1: Upload file as ContentVersion
    with open(file_path, "rb") as f:
        response = requests.post(
            f"{SF_BASE}/services/data/v62.0/sobjects/ContentVersion/",
            headers=SF_HEADERS,
            files={"entity_content": (
                None,
                '{"Title":"' + file_name + '","PathOnClient":"' + file_name + '"}',
                "application/json"
            ), "VersionData": (file_name, f, "application/octet-stream")}
        )
    content_version_id = response.json()["id"]
 
    # Step 2: Get the auto-generated ContentDocumentId
    cv = requests.get(
        f"{SF_BASE}/services/data/v62.0/sobjects/ContentVersion/{content_version_id}",
        headers=SF_HEADERS,
        params={"fields": "ContentDocumentId"}
    ).json()
    content_document_id = cv["ContentDocumentId"]
 
    # Step 3: Link to Case
    requests.post(
        f"{SF_BASE}/services/data/v62.0/sobjects/ContentDocumentLink/",
        headers={**SF_HEADERS, "Content-Type": "application/json"},
        json={"ContentDocumentId": content_document_id, "LinkedEntityId": case_id,
              "ShareType": "V"}
    )

What Cannot Be Migrated

This list is as important as the mapping table. These items must be manually rebuilt in Salesforce before go-live:

Budget the automation rebuild work separately from the data migration effort. For a SWSD instance with 50+ active automation rules, expect 2–4 additional weeks of Flow development and testing work.

Delta Sync and Cutover

A zero-downtime migration requires a delta sync strategy. You cannot freeze IT support operations for the duration of the full data load.

Executing the Delta

1. Initial Load: Extract all data up to a defined cutoff timestamp (e.g., Friday at 5:00 PM UTC) and load it into Salesforce over the weekend. SWSD remains live for agents throughout.
2. Freeze: On cutover night, set SWSD to read-only or restrict agent access to stop new record creation.
3. Delta Extraction: Query the SWSD API using updated_at_gte for all records modified since the initial load cutoff timestamp.
4. Upsert: Push delta records into Salesforce using the UPSERT operation against your external ID fields. This creates new tickets logged during the freeze window and updates the status of tickets modified since the initial load.
5. Final Validation: Run SOQL record count comparisons (see queries in the load section above) and spot-check 50+ records for data fidelity.
6. DNS/Routing Cutover: Update MX records or email routing to redirect support@company.com from SWSD Email-to-Case to Salesforce Email-to-Case.
7. Enable Salesforce for agents and re-enable automations, Flows, and Validation Rules.

Post-Migration Validation Checklist

Once the data is in Salesforce, validate before re-enabling automations and granting agent access:

• Count verification: Total records per object in SWSD must match totals in Salesforce. Use the SOQL queries in the load section above.
• State mapping check: Verify SWSD custom states (e.g., "Pending Vendor") mapped correctly to Salesforce Case Status picklist values.
• Comment content check: Spot-check at least 50 records across different time periods. Verify comment content is not truncated, particularly if CaseComment was used for any content over 3,500 characters.
• Attachment accessibility: Open attachments on older closed tickets to confirm files are accessible and not corrupted. Verify ContentDocumentLink.ShareType is set correctly.
• Timestamp verification: Confirm CreatedDate values on migrated Cases reflect original SWSD creation dates, not the migration run date.
• Owner assignment verification: Confirm OwnerId references resolved correctly for both active User records and Queues. Cases with failed owner lookups default to the running user — identify these with: SELECT Id, CaseNumber, SWSD_Incident_Id__c FROM Case WHERE OwnerId = 'your-migration-user-id'
• Re-enable automations only after all validation checks pass.

Common Failure Modes

These are the specific issues that most frequently derail SolarWinds-to-Salesforce migrations:

• Loading records out of dependency order. Creating Cases before Contacts exist breaks the ContactId lookup and generates INVALID_CROSS_REFERENCE_KEY errors. Salesforce either rejects the record or nulls the relationship depending on your allOrNone setting. Always load in the sequence defined above.
• Ignoring the 4,000-character CaseComment limit. SWSD comments longer than 4,000 characters are silently truncated. Validate comment lengths during extraction and route long comments to EmailMessage instead.
• Forgetting audit field permissions before the load. Every record gets the migration run date as CreatedDate. You only discover this post-load, and correcting it requires re-running the entire migration from scratch.
• Underestimating attachment upload time. Binary uploads to ContentVersion are single-threaded via REST API and cannot use Bulk API. Underestimating this phase by 2–3x is the most common timeline failure.
• Unmapped picklist values causing silent nulls. SWSD allows freeform text in some fields. Build a complete value mapping table and define all custom picklist values in Salesforce Setup before loading. Use the Bulk API results file to identify rows where the field was accepted but silently nulled.
• Duplicate Contact records from user-requester overlap. SWSD users who are both ticket requesters and agents need deduplication logic at extraction time. If you create both a Contact and a User record for the same person without linking them, case history will be fragmented.
• Row lock errors on parallel batch jobs. Multiple parallel batches writing Cases to the same parent Account trigger UNABLE_TO_LOCK_ROW errors. Sort CSV by AccountId external ID column before upload.

Bulk API Error Code Reference

When to DIY vs. When to Get Help

DIY is viable when:

• Total record volume under 100,000 across all objects
• No CMDB or asset migration in scope
• Only one or two SWSD object types (incidents + users)
• You have an engineer with hands-on experience with both the Samanage REST API and the Salesforce data model
• Timeline is flexible (4+ weeks available)
• No hard requirement to preserve original timestamps

Get specialized help when:

• Record volume exceeds 250,000
• CMDB, change management, and knowledge base are all in scope
• Original timestamps and agent assignments must be preserved exactly
• Zero-downtime cutover is a hard requirement
• Migration must complete in under 3 weeks
• Your team does not have Salesforce Bulk API 2.0 experience

These thresholds are based on the complexity inflection points where data model edge cases, API rate constraints, and Salesforce governor limits compound. Below 100K records, a skilled engineer can manually handle exceptions. Above 250K, the volume of edge cases makes manual exception handling impractical without tooling built specifically for this migration pattern.

Summary: Key Technical Facts for This Migration

For quick reference, the most citation-worthy specifics from this guide: