Migrate from SolarWinds Service Desk to Salesforce Service Cloud

SolarWinds Incidents migrate to Salesforce Case using an Incident Record Type to preserve the distinction from Service Requests. The mapping carries Priority, Status, Assignee (resolved by email to Salesforce User), Requester (WhoId on Case), and Description. Incident history, comments, and SLA timers transfer to Salesforce CaseHistory and EmailMessage records. Status state transitions (New, In Progress, Pending, Resolved, Closed) map to Salesforce Case Status values configured during schema design. The Record Type assignment is the first field set during import to ensure consistent routing rules apply throughout the migration.

SolarWinds Service Requests use the same API schema as Incidents with a distinct type field. We map them to a separate Salesforce Case Record Type (Service Request) to preserve organizational separation between break-fix incidents and fulfilled service catalog items. Approval workflows attached to service requests in SolarWinds migrate as metadata in a custom Approval_History__c field since Salesforce Approval Processes are architecturally different. The customer rebuilds active approval flows in Salesforce Flow post-migration.

SolarWinds assets (hardware, software, Configuration Items with serial numbers, purchase dates, assignment history, and CI relationships) present a significant architectural difference. Salesforce Service Cloud has no native ITSM asset management module; Field Service Management (FSM) is required for purpose-built asset management. We assess the destination FSM license status during scoping. If FSM is available, we map to Field Service Asset and related product objects. If not, we create a custom Asset object in Salesforce with custom fields for serial_number__c, purchase_date__c, assignment_history__c, and CI_relationship__c. CMDB dependency graphs from SolarWinds Premier map to custom lookup fields on the custom object because Salesforce standard relationship objects are not available without FSM.

SolarWinds user roles (Agent, Requester, Administrator) map to Salesforce User records. Role and group assignments in SolarWinds translate to Salesforce Profile assignments and Permission Set groups during migration. We resolve users by email match. Active and inactive status is preserved; inactive SolarWinds users map to inactive Salesforce Users with their original licenses to maintain assignment history. Any SolarWinds user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

SolarWinds Companies serve as organizational containers for users and assets and map directly to Salesforce Account. Company address, phone, and associated user counts migrate to standard Account fields. The Company name becomes Account Name and is used as the dedupe key during import. Account is imported before any Contact or Asset that references it to satisfy the lookup relationship at insert time.

SolarWinds Knowledge Base Articles migrate to Salesforce Knowledge with Article Type (FAQ, Troubleshooting, How-To) matching the source category structure. Article body content migrates as rich text. Attachments migrate as ContentDocumentLink records attached to the Knowledge Article. Category and subcategory hierarchy in SolarWinds may not map 1:1 to Salesforce Knowledge data categories; we migrate the full category path as a text field and flag orphaned articles requiring manual reassignment in Salesforce Setup.

SolarWinds SLA policies (response and resolution deadlines per priority level) map to Salesforce Entitlement Processes and Entitlements. This is a multi-object configuration: each SolarWinds SLA policy becomes a Salesforce Entitlement Process with Milestones for First Response and Resolution Time. Entitlements are attached to Cases via the EntitlementId lookup field, which is available on Enterprise and Unlimited editions only. Business Hours alignment from SolarWinds maps to Salesforce Business Hours object. Timer-reset behavior on business-hours calendars in SolarWinds may not map directly to Salesforce milestone pause behavior and requires validation during sandbox testing. We flag any SLA timer logic that cannot be preserved natively.

File attachments on Incidents, Service Requests, and Assets in SolarWinds are downloadable via the Samanage API and re-uploaded to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case or Asset. Inline images embedded in Knowledge Base article bodies also migrate as ContentDocument records. Salesforce file size limits (25 MB per file via API) may require chunking for larger attachments, and destination org storage quotas affect total attachment volume capacity.

Custom fields on Incidents, Service Requests, Assets, and Users require field-level mapping work because naming conventions and data types vary between the two platforms. We extract the full custom field schema from SolarWinds via the API, map each field to the appropriate Salesforce field type (Text, Number, Picklist, Checkbox, Date, DateTime), and pre-create all custom fields in the destination org before any data import begins. The mapping document includes Salesforce API field names (lowercase, underscores) and validation rule implications.

Tags applied to Incidents, Service Requests, Assets, and Knowledge Base Articles in SolarWinds migrate to Salesforce Topics with TopicAssignment records linked to the parent record. Alternatively, for flat tagging schemes, tags migrate to Salesforce multi-select picklist fields on the Case object. The customer chooses the tagging strategy during scoping based on whether hierarchical topic navigation is required in the destination.

Change management templates and approval workflows from SolarWinds are exported as configuration metadata and documented in a written handoff. Salesforce does not have a native change management object; teams requiring change approval workflows rebuild them in Salesforce Flow Approval Processes. We provide a Change Template Inventory document listing each source template with its name, description, workflow steps, and recommended Salesforce Flow equivalent, plus the associated Approver group mappings. Active change approval chains require admin rebuild post-migration.

Problems require explicit enablement under SolarWinds Setup > Global Settings > Service Desk Settings > Extra Features; if never enabled, the API returns empty sets and no problem records exist to migrate. We verify this during discovery and flag in the pre-migration audit. If Problems are enabled, they map to Salesforce Cases using a Problem Record Type to preserve the distinction from Incidents, or to a custom Problem object with a lookup to related Cases if the destination org uses a separate tracking model. We do not assume Problems are populated without enablement confirmation from the source instance.