Migrate from SysAid to Zendesk

SysAid Service Records map to Zendesk Tickets as the primary ticket entity. The SysAid subject field maps to the Zendesk Ticket subject; status maps to the closest Zendesk status value (New, Open, Pending, Solved, Closed); priority maps to Zendesk priority (Low, Normal, High, Urgent); the SysAid assignee maps to a Zendesk Agent via email lookup; the requester maps to a Zendesk User (requester_id); impact and urgency from SysAid become custom fields or comments on the ticket since Zendesk natively uses priority rather than a separate impact/urgency matrix. Category levels in SysAid can map to Zendesk tags or to a custom field capturing the full category path. All public and internal notes on Service Records migrate as ticket comments with visibility preserved via the public attribute.

SysAid Companies map to Zendesk Organizations. The company name maps to the Zendesk Organization name; contact fields map to organization-level custom fields; multi-company segmentation in SysAid becomes Zendesk organizational tags or a dedicated custom field. Organizations are created before User records so that the requester-to-organization relationship is satisfied at import time.

SysAid Users (end users, agents, and administrators) map to Zendesk End Users, Agents, and Admins based on role. The SysAid role assignment determines the Zendesk role. We resolve users by email as the dedupe key. The mapping preserves contact fields, active/inactive status, and language/locale settings. Permission logic tied to SysAid roles must be rebuilt in Zendesk Admin permission sets, which we scope as a manual step in the handoff document.

SysAid Assets (CI records, catalog items, and agent-based inventory) require destination configuration before migration. Zendesk Explore includes a lightweight asset management capability for Support Suite and Enterprise plans. If the destination Zendesk plan does not include Explore, we create a custom Zendesk object with custom fields to hold asset_type, status, assigned_user, serial_number, and relationship data. Catalog items from SysAid map as separate records in the same object with a type flag. We extract asset relationship data (parent-child CI dependencies) as a separate linked table for the customer to configure post-migration.

SysAid Projects are standalone task containers that do not have a direct Zendesk equivalent on Team and Growth plans. For those plans, we create tickets tagged with the project name and preserve the project start date, end date, and description as custom fields on the parent ticket. For Enterprise plans with the Projects beta feature, we map Projects to native Zendesk Projects with milestone tasks migrated as subtasks. Project-level custom fields migrate as ticket-level custom fields.

SysAid custom fields on Service Records map to Zendesk ticket custom_fields. Each SysAid field type (dropdown, checkbox, numeric, text, date) is mapped to the equivalent Zendesk field type, with the SysAid field ID captured during extraction and the Zendesk field ID obtained from the target environment. Dropdown fields in SysAid map to Zendesk dropdown or tag-based fields depending on the field cardinality. Multi-select SysAid fields map to Zendesk tag fields. We create all destination custom fields in the Zendesk Admin panel before any records are imported to avoid field-not-found errors during the bulk import.

SysAid Tasks (sub-items associated with Service Records, Projects, or other entities) map to Zendesk subtasks as child Ticket records with a custom parent_ticket_id field linking to the parent. Task title, status, assignee, due date, and parent entity reference are all preserved. Task dependencies in SysAid are documented as a relationship table in the handoff document since Zendesk subtasks do not natively support dependency chains.

SysAid KB articles map to Zendesk Guide articles. The SysAid article title maps to the Zendesk article title; body content migrates as HTML with formatting preserved where possible; SysAid article categories map to Zendesk Guide sections. Zendesk Guide must be activated before article import (Go to Zendesk Products > Guide > Build your knowledge base). We do not migrate SysAid's article-level permissions directly; these are rebuilt as Guide permission settings in Zendesk Admin. Embedded media in SysAid articles is extracted and re-uploaded to Zendesk's file storage during import.

SysAid attachments (files on Service Records, comments, and notes) map to Zendesk Ticket attachments. We extract file references from SysAid and re-upload them to Zendesk's file storage. The Zendesk API accepts attachments up to 20 MB per file; files exceeding this limit are flagged for manual handling or alternative storage. Attachment visibility (public versus internal) is preserved using the Zendesk comment public attribute. We re-link attachments to the correct ticket using the SysAid service_record_id as the cross-reference.

SysAid Action Items are lightweight checklist or task-type objects that can be associated with multiple entity types. We map Action Item title and status to Zendesk ticket comments with a structured checklist format using the Zendesk comment API. Assignee information is preserved as a comment mention. Custom triggers associated with Action Items in SysAid do not migrate (as with all SysAid automations) and are documented in the automation inventory for the customer to rebuild in Zendesk.