Migrate from iTop to Zendesk

iTop UserRequest maps to Zendesk Ticket as the primary ticket object. We map title (from UserRequest title), description (from UserRequest description), requester (from UserRequest caller_id -> Contact -> Zendesk End User), assignee (from UserRequest agent_id -> User), priority (from UserRequest priority with value-mapping: priority 1->urgent, 2->high/normal, 3->normal, 4->low, 5->low), and status (from UserRequest status with value-mapping: new->open, assigned->pending, resolved->solved, closed->closed). The OQL export preserves the requester email and org linkage that becomes the Zendesk requester and organization fields.

iTop Incident inherits from Ticket and adds impacted_ci and root cause fields. Incidents map to Zendesk Tickets with a custom incident_priority__c field carrying the original impact/urgency values and a custom incident_type__c tag set to Incident. The Incident timeline (status changes, comments) migrates as Zendesk Ticket comments in chronological order. Incidents without a linked caller use the organization's primary contact as the Zendesk requester.

iTop ChangeRequest has no native Zendesk equivalent. We map ChangeRequests to Zendesk Tickets with a custom changerequest__c checkbox field, a change_type__c dropdown (normal/urgent/emergency from iTop), and a change_approval_status__c field carrying the iTop approval state. The iTop rollback plan text migrates to a Zendesk internal note. ChangeRequests linked to specific CI records carry the CI identifier as an organization tag so the change context is preserved for auditors.

iTop Contacts (person records with name, email, phone, organization membership) map to Zendesk End Users. Email becomes the primary identifier and dedupe key. Organization membership maps to Zendesk Organization via the Contact's organization_id reference. Phone number migrates to the End User's phone field. For Contacts without an email (e.g., walk-in requesters), we generate a placeholder email from name and org to satisfy Zendesk's required requester field.

iTop Organizations map to Zendesk Organizations with name and any parent organization hierarchy preserved via Zendesk's parent organization field. Organization type (customer, provider, partner) migrates as a custom organization field. iTop organizations without a name receive a generated name from their primary domain or CI ownership.

iTop CI classes (Server, NetworkDevice, Application, Database) do not have a direct Zendesk equivalent. We extract CI records and flatten them: CI name, class type, and primary attributes become tags on the linked Zendesk Organization (e.g., #server-prod-web01, #application-erp-crm). If the customer requires CI auditability, we create a Zendesk custom object (Enterprise Suite) called CI_Record with fields for name, class, serial number, and organization lookup. The CI-to-CI relationship table (iTop links between CIs) is exported as a separate relationship CSV for manual documentation.

iTop Services linked to SLA definitions map to Zendesk Service Catalog items if the destination is on Enterprise Suite. We export the service name, description, category, and linked SLA. Service catalog categories require manual creation in Zendesk Admin before import because the category structure differs from iTop's service hierarchy. On Team and Professional Suite tiers (which lack Service Catalog), services migrate as Zendesk tags for reporting.

iTop User accounts (login, profile, role) map to Zendesk Agents. We export account metadata (name, email, role) for manual recreation in Zendesk Admin. Direct credential migration is not supported because iTop password hashes are PHP-based and incompatible with Zendesk's authentication. Agents are created with the same names and roles as iTop users, but each user must set a new Zendesk password during onboarding.

iTop SLA definitions include response time, resolution time, and escalation targets. We export SLA configurations and map them to Zendesk SLA Policies, which require Professional Suite or above. Each iTop SLA maps to a Zendesk SLA Policy with the same calendar (business hours) and the same metric (first response time, next agent reply, resolution time). Escalation actions in iTop do not migrate; we document each escalation trigger for the customer to re-implement as Zendesk triggers.

iTop attachments are stored in a local file system path and linked to tickets and CIs by object class and ID. We export the attachment metadata (filename, size, linked ticket ID, MIME type) and the raw files separately. During Zendesk import, we upload each file to Zendesk's file storage and link it to the corresponding ticket. The original file URLs become invalid in Zendesk, so we re-upload all files. Large attachments (>20MB per file in Zendesk) are flagged for chunking or alternative delivery.

iTop FAQ and KB articles (title, content, category) map to Zendesk Help Center articles if Guide is enabled on the destination account. Article content migrates as HTML with images preserved as inline attachments. Article categories from iTop map to Zendesk article section names. The customer must activate Zendesk Guide before article import and configure article permissions (public, agents-only, or signed-in users) per section.

iTop allows custom class definitions via XML extensions. We export custom object data for each unique class, then review the schema with the customer to define mappings. On Zendesk Enterprise Suite, custom objects migrate to Zendesk Custom Objects with lookup fields to Tickets, End Users, or Organizations. On lower Suite tiers, custom object data migrates to Zendesk custom fields on the most relevant standard object. Each custom class requires individual field-level mapping because iTop custom schemas vary widely between instances.