Migrate from Sunrise HR Case Management to Zendesk

Sunrise HR Cases map to Zendesk Tickets. Case subject becomes the Ticket subject, description maps to the Ticket comment body, status (Open, In Progress, Resolved, Closed) maps to Zendesk ticket status (Open, Pending, Solved, Closed), priority maps to priority (Low, Normal, High, Urgent), and category maps to a custom field or tag. The Sunrise-linked employee record becomes the Zendesk Ticket requester via the HRIS employee mapping. Case audit history migrates as chronological comments on the Zendesk ticket.

Sunrise HR Queries are lightweight request objects. We map them to Zendesk Tickets using a custom field query_type set to Query, preserving query text, submitter, assigned handler, and resolution status. If the customer used Queries as sub-issues within Cases, we set the Zendesk ticket as a child via the parent_id field on Ticket. Queries with no parent Case link become standalone Zendesk Tickets flagged with the query_type custom field.

Sunrise HR Requests (absence approvals, equipment requests, onboarding tasks) map to Zendesk Tickets created via request forms. Request type, custom fields, approval chain, and current stage migrate as Zendesk ticket fields. We configure Zendesk request forms during the schema design phase to match the Sunrise request categories. Approval chain metadata is preserved in a custom field approval_chain__c as a text record for the Zendesk admin to rebuild as a Zendesk trigger or approval workflow.

Sunrise Employees linked to Cases as the subject map to Zendesk End Users. We extract name, email, employee_id, and department from the HRIS integration. If the customer uses Infor HCM, the employee-to-case linkage migrates cleanly because we resolve the employee record by employee_id or email match. If the HRIS is a non-Infor integration (Workday, BambooHR, ADP), we establish a new employee-data mapping strategy during discovery before case migration begins, as Sunrise's Infor-specific employment fields may not have a direct Zendesk equivalent.

Sunrise Agents (HR staff who own and resolve cases) map to Zendesk Agents. We extract agent name, role, and team assignment from Sunrise and map them to Zendesk agents by email match. Sunrise team structures may differ from Zendesk groups; we document the team-to-group mapping during discovery and create a Zendesk groups and subgroups schema before migration. Agents without a matching Zendesk account go to a reconciliation queue.

Sunrise SLA definitions are tied to the Infor OS configuration layer and are not in the exportable schema. We export SLA names, target resolution times, breach timestamps, and the case-category-to-SLA mapping as data. During migration we create a written SLA inventory document listing each Sunrise SLA with its category, target, and breach action. The Zendesk admin rebuilds these as Zendesk SLA policies attached to the relevant ticket forms and request types. Historical SLA breach timestamps migrate as read-only custom fields on Zendesk tickets to preserve compliance reporting continuity.

Escalation rules in Sunrise are stored as Infor workflow engine configuration, not as records in the database, and therefore do not export as data. We document every visible escalation rule during discovery — including trigger conditions, escalation recipients, delay actions, and notification types — and deliver a written escalation inventory. The Zendesk admin rebuilds these as Zendesk Triggers (event-driven) and/or Macros (agent-initiated). The customer should treat escalation rule rebuild as a post-migration implementation task and budget for it accordingly.

Documents attached to Sunrise cases (policies, evidence, correspondence) are extracted as binary blobs via the Infor API. We download each attachment with its original filename and timestamp, then re-attach it to the corresponding migrated Zendesk Ticket. Filenames and original upload timestamps are preserved. If any attachment exceeds Zendesk's 50 MB per-file limit, we flag it during discovery and discuss splitting or archiving options with the customer.

Sunrise case categories and tags export as flat label lists. We map them to Zendesk Tags on the corresponding tickets. Where duplicate categories exist across Sunrise (e.g., case category and query type overlapping), we consolidate into a single tag taxonomy. Any tag that maps to a Zendesk reserved tag name is renamed with a prefix. We deliver a tag mapping table showing the source Sunrise label and the resulting Zendesk tag.

Historical SLA breach events stored as audit entries on Sunrise cases migrate as read-only custom fields on the corresponding Zendesk ticket (e.g., sla_breached__c boolean, sla_breach_timestamp__c datetime, sla_breach_name__c text). We do not create Zendesk native SLA policies from historical breach records because Zendesk SLA policies apply to open tickets, not historical ones. The custom fields preserve the compliance audit trail for any reporting period that predates the migration.

Sunrise HR Cases, Queries, and Requests may contain custom fields beyond the standard schema (e.g., legal entity, union representation, investigation status). We export the full custom field schema during discovery and create equivalent Zendesk custom ticket fields of matching types (text, dropdown, date, boolean). Dropdown fields are rebuilt as Zendesk dropdown or tag fields with the same option list. Required-field constraints are noted and configured in Zendesk after the admin validates the field mapping.