Migrate from ITSM 365 to Zendesk

ITSM 365 Incident records map to Zendesk Ticket with type set to Incident. The source incident_id is preserved as a custom field zendesk_migration_incident_id__c for cross-system reference. Priority mapping follows: Critical maps to Urgent, High maps to High, Normal maps to Normal, Low maps to Low. Status mapping: New and In Progress map to Open, Resolved maps to Solved, Closed maps to Closed. The original incident category or subcategory from ITSM 365 becomes a Zendesk custom dropdown field. SLA breach timestamps migrate as custom datetime fields if the ITSM 365 SLA was breached at export time.

ITSM 365 Service Request records map to Zendesk Ticket with type set to Request. The service catalog item reference from ITSM 365 becomes a Zendesk custom text field or maps to a Help Center article if the customer has a Zendesk Guide plan. Request category and subcategory from ITSM 365 map to Zendesk custom dropdown fields. If the Service Request has an attached approval chain, the sign-off history migrates as internal comments tagged [Approval Record].

ITSM 365 Problem records have no native Zendesk equivalent. We address this gap through a configuration step before migration: we create a Zendesk custom object called Problem_Record__c (if the customer's Zendesk plan supports custom objects) or use structured custom fields on each Incident ticket (problem_id, problem_title, problem_status) to preserve the linkage. Each Problem record is migrated first, then its related Incidents are updated with the problem linkage field at migration time.

ITSM 365 Change records with their approval stage (Draft, Submitted, Assessed, Approved, Scheduled, Implemented, Closed) have no native Zendesk equivalent. We create a Zendesk custom object called Change_Record__c (Enterprise plan) or map Change fields onto Incident tickets as custom fields (change_id, change_type, change_risk_level, change_approval_status). The risk classification (Low, Medium, High, Critical) from ITSM 365 maps to a Zendesk custom dropdown. Approval stage history migrates as internal comments tagged [Change Approval Stage].

ITSM 365 agent profiles with their role (First Line, Second Line, Problem Manager, Change Manager) map to Zendesk User records. We match by email address. The ITSM role becomes a Zendesk custom user field. Any ITSM 365 agent without a matching Zendesk User is placed in a reconciliation queue for the admin to provision before production migration.

ITSM 365 end users who submit incidents and service requests map to Zendesk End Users. We match by email. The end user's department, location, and cost center from ITSM 365 become Zendesk custom user fields if the customer requires this data in Zendesk's user profile.

ITSM 365 organizations or departments map to Zendesk Organizations. The organization name, domain, and any custom properties (business unit type, cost center) migrate as Zendesk Organization fields. If ITSM 365 uses a flat user structure without organizations, we discuss with the customer whether to create Zendesk Organizations based on department or location fields or to leave requesters unorganized.

ITSM 365 CIs linked to Incidents via the CMDB have no native Zendesk equivalent. We create a CI_Record__c custom object in Zendesk (Enterprise plan) or use Zendesk Organizations as a fallback CI host. The CI type (Hardware, Software, Network, Service) becomes a custom field on the CI object. Incidents reference their CI via a lookup relationship built during the migration schema phase. The customer chooses the CI strategy during scoping.

ITSM 365 internal notes and public comments map to Zendesk public comments. If ITSM 365 has a separate internal note type, those migrate as Zendesk internal comments visible only to agents. Timestamps, author email, and HTML body (if present) are preserved. Comment attachments migrate as Zendesk ticket attachments linked to the comment record.

File attachments on ITSM 365 incidents, service requests, and change records migrate to Zendesk ticket attachments. We extract the file name, MIME type, size, and URL from ITSM 365, download each file, and attach it to the corresponding Zendesk ticket via the Zendesk Attachments API. Attachments over 50 MB are flagged for the customer to handle via file share because Zendesk's direct attachment API has a 50 MB per-file limit.

ITSM 365 SLA policies with calendar-based breach rules, escalation stages, and business-hours definitions require Zendesk SLA policies to be pre-configured with the correct metric (First Reply Time, Next Reply Time, Resolution Time), target in hours or minutes, and business-hour schedule before records are imported. Zendesk SLA policies do not support the same conditional escalation branching available in ITSM 365 Standard; if the customer uses SLA policies with multiple escalation stages per priority, we document the gap and recommend splitting into separate Zendesk SLA policies per priority tier.

ITSM 365 Standard's multi-step approval chains with sign-off records have no native equivalent in Zendesk. We migrate approval request records as internal ticket comments tagged [Approval Record: Stage Name, Approver, Date, Decision]. The customer's admin rebuilds the approval workflow using Zendesk macros and business rules post-migration. We provide the approval chain inventory document listing every approval chain with its stages, approvers, and decision outcomes.