Migrate from SolarWinds Service Desk to Zoho Desk

SolarWinds Incidents map directly to Zoho Desk Tickets with the ticket type set to Incident. Priority, status, assignee, requester, description, and created/updated timestamps transfer via the API. Incident history comments map to Zoho Ticket Comments and Threads, preserving author and timestamp. We preserve the original incident ID as a custom field sw_incident_id__c for audit trail. Approval workflows on incidents are extracted as metadata and documented for the customer's admin to rebuild in Zoho Desk Blueprint; we do not migrate approval logic as executable configuration.

SolarWinds Service Requests use the same API schema as Incidents with a distinct type field. We map them to Zoho Desk Tickets with type set to Request, preserving the service catalog item name and any associated custom fields from the catalog request form. Approval workflow status (approved, pending, rejected) transfers as a custom field. The Zoho Desk Blueprint process replaces the SolarWinds service catalog workflow logic.

SolarWinds Problems track root cause and known error records and require explicit enablement under Setup > Global Settings > Service Desk Settings > Extra Features. Zoho Desk has no native Problems module. We create a custom Problem Type field in Zoho Desk and map all SolarWinds problem records to tickets of type Problem, carrying root cause description and known error resolution into custom fields problem_root_cause__c and problem_known_error__c. We verify during discovery whether Problems are enabled; if not, we exclude the object from scope and note this in the scoping report.

SolarWinds Agent and Administrator roles map to Zoho Desk Agents by email address as the dedupe key. We extract the role permission matrix and translate it into Zoho Desk department and role assignments. Active/inactive status transfers; inactive SolarWinds agents are provisioned as inactive Zoho Desk agents so that historical ticket assignment is preserved without sending notifications. Group assignments map to Zoho Desk Teams.

SolarWinds Requester users map to Zoho Desk Contacts. First name, last name, email, phone, and department transfer directly. Contact type (employee, vendor, customer) maps to Zoho Desk's contact type field. We batch contacts by department for Zoho Desk department association so that ticket assignment rules can use department context.

SolarWinds Company records map to Zoho Desk Accounts. Company name, address, phone, website, and associated user count transfer. Account is created before Contact import so that the Account-Contact relationship is satisfied at insert time. The Zoho Desk Account-Customer field scope replaces SolarWinds' company-to-user linking model.

KB Articles migrate as Zoho Desk Help Center articles with content, author, and category assignments preserved. Article versioning in SolarWinds is flattened to the latest published version in Zoho Desk. We flag that SolarWinds KB article attachments (images, documents embedded in articles) are excluded from the Zoho Desk import API and Zwitch; we download these as a separate file archive and deliver it post-migration for manual re-attachment to Zoho Help Center articles. Category hierarchy may require manual re-parenting in Zoho Desk after migration.

SolarWinds SLA policies defining response and resolution deadlines per priority level map to Zoho Desk SLA Policies with First Response Due and Next Response Due fields. We map priority-to-SLA assignment and transfer business-hours calendar references. Timer-reset behavior on business-hours calendars requires validation in Zoho Desk because the two platforms calculate working hours differently; we test SLA timer behavior in a Zoho Desk trial account before production migration.

Tags applied to tickets and assets migrate as Zoho Desk Tags. The tag model in both platforms is flat string arrays, so no transformation is required. Tag names are preserved exactly, and tags are re-associated with their target tickets after the ticket import phase completes.

SolarWinds custom fields on Incidents, Service Requests, Assets, and Users require field-level mapping to Zoho Desk equivalent types. Text, number, date, dropdown, and checkbox map directly; user and user-multi-select map to Zoho Desk Agent lookup fields. We extract the full custom field schema pre-migration, verify each field type has a Zoho Desk equivalent, and flag any fields without a direct type match for the customer to resolve before migration. Service Desk limits on filterable and sortable custom fields (lower tiers have tighter limits) may affect how many custom fields can be indexed in Zoho Desk; we flag this during scoping.

SolarWinds change management templates and approval workflow definitions export as configuration data, not executable code. We deliver the template definitions in a structured JSON inventory so the customer's Zoho Desk admin can recreate them as Blueprint flows. We do not migrate change templates as code because the Zoho Desk Blueprint engine uses a different action model from SolarWinds' change workflow builder.

File attachments on tickets and assets download from SolarWinds via the API and re-upload to Zoho Desk on the corresponding ticket or account. Ticket attachments migrate automatically as child records of the ticket import. Asset attachments require manual association post-import since Zoho Desk does not have a native asset management module. Attachment size limits and storage quotas at the destination may constrain high-volume migrations; we verify storage availability during discovery and throttle uploads accordingly.