Migrate from SolarWinds Service Desk to Gorgias

SolarWinds Incidents migrate as Gorgias Tickets. The source priority field maps to a Gorgias Ticket Priority tag. The source assignee (technician) maps to the Gorgias agent via email lookup. The original Incident description migrates as the first ticket message. Incident history (status changes, assignments) is preserved as internal Gorgias notes rather than a native history log, because Gorgias does not have a structured audit log on individual tickets equivalent to SolarWinds's Activity Log. We flag any ticket referencing a CI (configuration item) as an internal tag since Gorgias has no CMDB.

SolarWinds Service Requests and Incidents both use the same Samanage API ticket schema with a distinct type field. Both migrate to Gorgias Ticket. The original type (Incident vs Service Request) is preserved as a Gorgias Tag so that the customer's admin can filter by source record type post-migration. Approval workflows attached to Service Requests cannot migrate as code; we document them as a manual rebuild item in the Gorgias Automate setup guide.

SolarWinds Problems map to no Gorgias object. Problems are ITIL records tracking the root cause of one or more Incidents and have no direct analog in Gorgias's customer support model. We extract the Problem records as a JSON export, tag each related Incident in the export with its Problem ID, and deliver the export as a reference document for the customer's admin to handle outside Gorgias. If Problems are not enabled in the source SolarWinds instance (they require explicit activation under Setup > Global Settings > Extra Features), we confirm this during discovery and exclude the object from the migration plan entirely.

SolarWinds Change Templates and Change Management workflows have no Gorgias equivalent. We extract the template definitions (approval chains, fields, workflow steps) as a written configuration inventory delivered to the customer's admin. Gorgias Automate supports rule-based routing and macro triggers, but the ITSM change advisory board model is not supported. This is documented in the migration scope as a rebuild item requiring the customer's workflow administrator.

SolarWinds users with the Agent role map to Gorgias Agents via email as the dedupe key. We extract agent name, email, active/inactive status, and group membership. The SolarWinds group structure maps to Gorgias Departments if present, or is flattened if the destination has no equivalent group hierarchy. Inactive SolarWinds agents are migrated as inactive Gorgias agents so that historical ticket assignments remain intact.

SolarWinds requesters (the end users who submit tickets) map to Gorgias Customers via email as the dedupe key. We extract name, email, phone, and company association. If the source SolarWinds instance has Companies attached to the requester, we create a Gorgias Customer with the company name stored in the customer note field. Gorgias Customers do not have a separate organizational container object like SolarWinds Companies—organization membership is implicit in the customer's profile.

SolarWinds Companies (organizational containers for users and assets) do not have a direct Gorgias equivalent because Gorgias does not have a multi-customer organization hierarchy. We extract Companies and their associated user counts, then attach the company name to each related Customer record in Gorgias. If the customer requires a multi-organization view in Gorgias, we propose using Tags (one tag per company) as a workaround since Gorgias does not support hierarchical Account structures.

SolarWinds ITAM assets (hardware, software, licenses, and CI relationships) have no native Gorgias equivalent. Gorgias is not an IT asset management tool. We assess the customer's use case during discovery: if the asset data is primarily for reference during support (for example, linking a customer to their subscription tier or product version), we migrate assets as custom fields on the Gorgias Customer record. If the CMDB relationship data is critical, we propose a Gorgias custom object with name, serial number, purchase date, and a lookup to the related Customer. CMDB dependency graphs from SolarWinds Premier cannot be preserved in Gorgias; we export the dependency graph as a JSON reference document.

SolarWinds Knowledge Base Articles migrate to Gorgias Articles. We extract article title, body content (HTML), category assignments, and publication status. The SolarWinds category hierarchy (folder structure) maps to Gorgias Article sections. Article versioning does not migrate because Gorgias Articles are not versioned by default—we import the current published version as the only version. Article attachments migrate via Gorgias's attachment API. Articles with HTML content containing SolarWinds-specific variable placeholders are flagged for manual review before import because variable substitution is SolarWinds-specific and may render as literal text in Gorgias.

SolarWinds SLA policies (response time and resolution time per priority level) cannot map 1:1 to Gorgias because Gorgias applies SLA at the channel level (email SLA, chat SLA) rather than at the individual ticket level. We extract the SLA definitions as a written configuration inventory and map the source priority level (Critical, High, Medium, Low) to a Gorgias Ticket Priority tag. The customer's admin configures channel-level SLA timers in Gorgias Settings post-migration based on the inventory document we deliver.

File attachments on SolarWinds tickets and assets download via the Samanage API and re-upload to Gorgias Tickets. We handle attachment size limits (SolarWinds allows up to 25 MB per attachment on most tiers) and Gorgias attachment limits during import. Large attachment volumes (over 10,000 files) require batched upload with the Gorgias REST API to avoid timeout. We flag any attachment that exceeds Gorgias's supported size during discovery so the customer can address storage constraints before migration.

SolarWinds Tags applied to tickets, assets, and users migrate as Gorgias Tags. The tag string values copy directly. SolarWinds uses a flat tag model (no tag hierarchy), which matches Gorgias's flat tag model, making this a clean 1:1 migration. We resolve tag assignments at migration time by linking each ticket to its source tag array.

SolarWinds custom fields on Incidents, Service Requests, and Assets require schema mapping to Gorgias custom fields during the discovery phase. We extract the full custom field schema from SolarWinds (field name, type, required/optional, and all picklist options) and map each to the closest Gorgias custom field equivalent. Supported SolarWinds field types (Text, Dropdown, Checkbox, Date, Number, User) map to equivalent Gorgias field types. Attachment fields do not migrate as live attachments; we migrate them as ticket notes with a reference link to the source SolarWinds record. Custom fields on Assets that map to a Gorgias custom object require the custom object to be created first, which we handle as a schema-first step.