Migrate from Siit to Zendesk

Siit Requests map directly to Zendesk Tickets. The src.status maps to Zendesk ticket Status (new, open, pending, hold, solved, closed); src.priority maps to Zendesk Priority (low, normal, high, urgent). The submitted_from channel field (employee_portal, slack, mail, ms_teams) sets the Zendesk ticket channel attribute at import. The assignee_admin_uid resolves to a Zendesk Agent via the User mapping; if the target_uid refers to an end-user, it maps to the Ticket requester field.

Siit People records with Admin seat type map to Zendesk Agent (end-user-type: full). Siit People records without Admin seat type map to Zendesk End User (end-user-type: end-user). We extract department, team, office location, legal entity, employment type, and lifecycle stage from the People record and store them as Zendesk user fields. Group memberships from Siit People export map to Zendesk Group membership for agents.

Siit Services catalog items map to Zendesk Guide articles organized by category. Each service's configuration metadata, category assignments, and workflow associations migrate as article metadata. If Zendesk Guide is not activated on the destination account, we provision it during migration setup. The account owner must activate Guide from the Zendesk Products icon before article migration begins.

Siit Applications inventory (software assets with ownership, lifecycle status, and category metadata) has no native Zendesk equivalent. We map Applications to a Zendesk custom object named Applications__c with lookup relationships to the relevant end-user or equipment record. The equipment-to-application associations migrate as lookup field values. If the customer does not require a separate custom object, we serialize the application data as structured JSON attached to the owning user's Zendesk profile.

Siit Equipment records (physical and virtual devices with lifecycle attributes and ownership details) have no native Zendesk equivalent. We map Equipment to a Zendesk custom object named Equipment__c with lifecycle status, ownership, and key configuration fields. Device-to-person associations migrate as lookup field values pointing to the Equipment__c record from the owning User.

Siit Communication records (outbound messages and satisfaction survey responses linked to Requests) map to Zendesk Ticket Comments. Public messages migrate as public comments; internal notes migrate as private comments. Satisfaction ratings (CSAT scores) from Siit Communication records migrate to Zendesk Ticket satisfaction ratings if available in the destination tier, or to a custom ticket field siit_csat_score__c for audit.

Siit custom_form_inputs are arbitrary label/value pairs with no stable schema per request type. We scan all unique labels during migration discovery, create Zendesk custom ticket fields of matching type (text, dropdown, checkbox, date, etc.) using the label as field name, and populate each migrated Ticket with the corresponding custom field values. Fields with values that Zendesk cannot represent natively (e.g., nested objects) are serialized as a JSON blob in a fallback text field.

Tags associated with Siit Requests via tag_uids arrays migrate as Zendesk Ticket Tags. The tagging taxonomy and tag names are preserved. Zendesk automatically creates tags that do not exist at migration time; no pre-provisioning of the tag list is required.

Siit Inboxes route requests to specific teams or queues. They map to Zendesk Groups, which serve the same routing function. We create Zendesk Groups matching the Siit Inbox names during schema setup and route the migrated Tickets to the appropriate Group based on the original Inbox assignment.

Siit Request records include first_replied_at and first_completed_at timestamps. SLA timers and escalation configurations export as workflow and request metadata. We map these to Zendesk SLA Policies using the destination tier's SLA support (Suite Professional and above). Historical SLA breach data migrates as custom ticket fields sla_first_reply_at__c and sla_resolved_at__c for reporting continuity.

Siit Admin users map to Zendesk Agents. We resolve by email match against the Zendesk destination User table. Admin role-based access control assignments map to Zendesk roles (Light Agent, Agent, Admin) based on the customer's Zendesk plan tier. Only Admins in Siit should be provisioned as billable Zendesk Agents; non-Admin employees map to End Users to avoid inflating the Zendesk agent count.