Migrate from iTop to Zoho Desk

iTop UserRequest is the primary ticket object and maps directly to Zoho Desk Ticket. We export title, description, functional_ci, services, priority, status, and assignee fields via OQL. The iTop ticket status (New, Assigned, Resolved, Closed) translates to Zoho Desk ticket status (Open, Pending, On Hold, Resolved, Closed) with a status mapping table defined during scoping. Priority mapping preserves iTop's 1-4 priority levels as Zoho Desk priority values.

iTop Incident class inherits from Ticket and includes caller, impacted_ci, and assignment fields that map to Zoho Desk Ticket fields. The incident timeline (created on, last update, resolution time) migrates as ticket timestamps. We preserve the incident's linked knowledge base article references as custom fields on the Zoho Desk ticket since Zoho Desk handles KB articles separately.

iTop ChangeRequest includes type (Normal, Urgent, Emergency), approval statistics, rollback plan, and CI linkage. Zoho Desk does not have a native change management object, so we create a custom module called 'Change Requests' in Zoho Desk (Enterprise tier required for custom modules) to store these records. Change request status, approval chain, and rollback plan fields migrate as custom fields on the custom object. If the destination Zoho Desk is on a lower tier without custom module access, Change Requests are stored as tickets with a custom field flagging their change request origin.

iTop FunctionalCI objects linked to services map to Zoho Desk Product records. The service name, description, and associated SLA definitions migrate to Product name, description, and custom SLA reference fields. Service subcategories in iTop map to Product categories in Zoho Desk. If the iTop instance uses the itop-service-mgmt extension, service providers and customer contracts link to the Zoho Desk Account as custom fields.

iTop CMDB CI classes (Server, Network Device, Application, Database, Storage) map to a custom 'Assets' module in Zoho Desk. Each CI class becomes a separate record type within the Assets module if the destination is Enterprise tier. CI-to-CI relationships (depends on, runs on, connects to) migrate as custom lookup fields between Asset records. If Enterprise tier is not available, CIs store as custom fields on related Tickets for basic linking purposes.

iTop Contact records (person details, email, phone, organization membership) map to Zoho Desk Contacts with organization membership preserved via the AccountExtId linking to Zoho Desk Accounts. We export iTop Contact via OQL and map First Name, Last Name, Email, Phone, Mobile, and Street/City/State/Country fields directly. Any role-specific Contact fields (e.g., team role) migrate as custom fields on the Contact record.

iTop Organization records map to Zoho Desk Accounts. Organization name, website, phone, and address fields migrate directly. We preserve the hierarchical parent-child organization structure using Zoho Desk's account hierarchy feature where available, mapping iTop's parent organization reference to the Account's parent account lookup.

iTop User accounts (login, profile assignments, contact information) export as agent metadata. Direct migration of user credentials is not supported because iTop password hashes use PHP-based encryption specific to its authentication module. We export User first name, last name, email, and profile (role) assignments for the customer's admin to manually provision Zoho Desk agents. Agents must be created in Zoho Desk with matching email addresses before ticket import begins so that assignee resolution succeeds.

iTop allows custom class definitions via XML extensions that vary widely between instances. We export each custom object with its full schema during scoping, then review the schema with the customer to define destination equivalents. If Zoho Desk Enterprise is in use, custom classes become custom modules in Zoho Desk with equivalent field types (text, picklist, date, lookup). For lower tiers, custom fields are appended to existing modules. Each custom class requires individual mapping and cannot be auto-detected without customer input on field meaning.

iTop stores attachments in a local file system path structure that includes the object's class name and ID. These file URLs are invalid after migration to a cloud platform. We export the attachment metadata (filename, size, linked object class, linked object ID) alongside the raw files from the file system, then re-upload each file to Zoho Desk's cloud storage and relink it to the correct ticket or contact record using Zoho Desk's attachment API. This requires read access to the iTop file storage directory during export.

iTop FAQ and KB articles (title, content, category) migrate to Zoho Desk Knowledge Base articles. Article content exports in HTML format via OQL. Category structures differ between platforms; we map iTop categories to Zoho Desk sections or root categories during scoping, and the customer confirms the mapping before import. Articles without an existing Zoho Desk category are created under a default 'Imported Articles' section for manual reorganization post-migration.

iTop SLA definitions include escalation matrices and response or resolution time targets that we export from the itop-sla-computation module. SLA escalation rules (trigger conditions, escalation actions, notification chains) are platform-specific and cannot transfer directly. We document the SLA configuration in a written inventory specifying response time, resolution time, and priority mapping so the customer's admin can re-implement SLAs in Zoho Desk using its SLA configuration tool (available from Professional tier and above).