Migrate from Sunrise ITSM to Zendesk

Sunrise Incidents map directly to Zendesk Tickets. We carry forward priority (Sunrise priority 1-5 maps to Zendesk priority low/normal/high/urgent), category, assignee (resolved via email match to Zendesk User), status, and any organisation-level custom Incident fields as Zendesk custom_fields. The Sunrise Incident number is preserved as a custom field src_incident_id__c for cross-reference. SLA breach timestamps carry forward as custom fields if Zendesk Enterprise SLA policies are not yet configured at migration time.

Sunrise Service Requests map to Zendesk Tickets with request_type distinguished via a custom ticket field. Requestor information migrates as the Zendesk Ticket requester (via email lookup or new user creation). Approval chain status from Sunrise carries forward as a custom field; the Zendesk admin rebuilds approval workflows using Zendesk Triggers and Macro conditions post-migration.

Zendesk has no native Change management object. We map Sunrise Changes to Zendesk Tickets with a custom field change_type, risk_level, approval_status, and related_incidents (stored as a comma-separated list or custom object reference). CI linkage from Sunrise Change records carries forward as a custom field referencing the migrated CI ID. The customer must decide whether Changes live alongside Incidents in the same Ticket view or require a separate Tag filter for Change-specific reporting.

Zendesk Asset management is available only on Enterprise+ plans. If the destination Zendesk plan includes Assets, we map Sunrise Configuration Items to Zendesk Assets with hostname, serial_number, ci_type, and relationship fields. For Starter or Team plan migrations, we map Sunrise CIs to a Zendesk v2 Custom Object with lookup relationships to the Ticket records where the CI was referenced, and the customer accepts the reduced CI visibility post-migration.

Sunrise KB Articles with HTML body content migrate to Zendesk Guide articles. We extract the article title, body (converted from Sunrise richtext format to HTML compatible with Zendesk Guide), category structure, status flags, and any linked article references. Articles are published to the relevant Zendesk Guide section during migration. Draft status articles migrate as drafts requiring admin review before publishing.

Sunrise Users and Agents map to Zendesk Users. Agents are provisioned with the agent role in Zendesk; end users are provisioned as end-users. We match by email address as the dedupe key. If a Sunrise Agent references an Active Directory sync identity, we map that to the Zendesk User email and flag for the customer's Zendesk admin to configure SSO mapping post-migration if Zendesk SSO is not yet set up.

Sunrise Teams map to Zendesk Groups. Team membership order and escalation hierarchy are preserved as Group membership assignments. We create Zendesk Groups before any Ticket import so that Ticket group assignments resolve correctly at insert time.

Sunrise Service Catalog items with linked workflows and approval matrices migrate as Zendesk Request Categories or custom ticket fields that capture the service type. Workflow references that cannot be carried forward are flagged as broken references in the migration inventory for manual re-linkage by the Zendesk admin post-migration.

Sunrise's 30+ configurable modules with bespoke schemas require a pre-migration schema audit from Sunrise Software before we can map fields. We extract the full live schema including all custom field names, types, and relationships, then design Zendesk equivalents: standard custom_fields for simple properties, Zendesk v2 Custom Objects for structured data with lookups, and Tags for classification-style fields. The mapping approach is determined per module during discovery based on Zendesk plan tier and data relationship requirements.

Sunrise stores attachment file paths rather than inline binary data, and some customers host files on internal network drives. We resolve each file path reference, download the file, and re-attach to the equivalent Zendesk Ticket. If the source file server is decommissioned before migration completes, unreferenced attachments become unrecoverable—flagged as a risk during discovery. Inline images in KB articles are extracted and re-uploaded as Help Center article attachments.