Migrate from OpenText ZENworks Service Desk to Zoho Desk

ZSD Incidents map directly to Zoho Desk Tickets. Title, Description, Category, Priority, and Status migrate as standard Zoho fields. The assigned technician maps to a Zoho Desk Agent resolved by email lookup. Affected CI maps to a Zoho Asset lookup if the CI was exported and provisioned in Zoho Desk first. SLA response and resolution timers migrate as metadata fields (sla_response_target__c, sla_resolution_target__c) since Zoho Desk recalculates SLA status on import rather than preserving breach state.

ZSD Service Requests use the same base schema as Incidents but with a distinct workflow type flag (request_type = 'Service Request'). We map them to Zoho Desk Tickets with a custom field zsd_request_type__c set to 'Service Request', allowing agents to filter or report on request fulfillment separately from incidents without splitting into a different Zoho module. Approval chain assignments from ZSD migrate as metadata on the ticket for the admin to reconstruct in Zoho Desk Blueprint.

ZSD Changes (Requests for Change) contain fields not natively present in Zoho Desk Tickets: Change Owner, Change Advisory Board status, Risk/Impact/Urgent flags, and Scheduled Start/End. We map these to Zoho Desk custom fields (change_owner__c, cab_status__c, risk_level__c, impact__c, scheduled_start__c, scheduled_end__c) that the customer configures before migration. The CAB approval chain is documented as a Blueprint step sequence for manual reconstruction. Change-linked Incidents are preserved as related ticket references.

Problem records in ZSD store root cause analysis, linked Known Errors, and associated Incidents. Zoho Desk has no native Problem management module. We map Problem records to Tickets with a custom field problem_record__c = true, carry the root_cause_analysis text into the ticket description, and document the Known Error association as a custom multi-select field (known_error_ids__c) and as a written linkage table for the admin to rebuild using Zoho Desk's linked tickets feature or a custom module if the customer licenses Zoho FSM or a similar add-on.

ZSD Knowledge Articles (title, content, keywords, category, visibility) migrate to Zoho Desk Knowledge Base articles. HTML content may require re-encoding as Zoho Desk uses a different rich-text rendering engine. We flag all articles for post-migration content review and provide a diff report comparing original and rendered versions. Article visibility (public, internal, restricted) maps to Zoho Desk's article status and section permissions. Attachments to Knowledge Articles are not migrated by Zoho's Zwitch and require separate file transfer with article re-linking.

ZSD Configuration Items map to Zoho Desk Assets. CI Class (Hardware, Software, Service), Name, Serial Number, Status, and assigned owner migrate to Zoho Asset fields. CI relationships (linked Incidents, parent-child CI hierarchy) are preserved as Zoho Asset relationship records or as custom fields documenting the linkage. The CI-to-Asset mapping is the most schema-dependent step: if ZSD uses custom CI classes, the customer must pre-create matching Zoho Asset types before migration begins.

ZSD User records (login name, email, full name, phone, location, department, manager hierarchy) map to Zoho Desk Contacts. Because ZSD's Microsoft Entra ID import is known to fail in current releases, we query the source Active Directory or Entra ID directly and map users by UPN or objectGUID, bypassing ZSD's broken import module entirely. We cross-reference the ZSD user table against the AD export to resolve department assignments and manager hierarchies that ZSD failed to populate. Any user without an email match in Zoho Desk goes to a reconciliation queue.

File attachments linked to Incidents, Service Requests, Changes, or Knowledge Articles are exported as binary blobs from ZSD's file storage with their association metadata (parent object type, parent record ID, file name, MIME type). We re-associate attachments to the migrated record in Zoho Desk by matching the source record's external ID carried through the import. Large attachment volumes may require chunking and a separate file transfer pass after the record migration completes.

ZSD approval chains and multi-step workflow definitions are stored as configuration in ZSD's workflow engine. We export the step definitions, approval order, conditions, and responsible roles as structured metadata in a written inventory document. This document describes each workflow's trigger, steps, conditions, approvers, and SLA gate in Zoho Desk Blueprint terms so the customer's admin can reconstruct them. Workflows do not migrate as live configurations.

SLA timer definitions and calendar configurations are stored per ZSD setup. We preserve SLA name, priority mapping, and response/resolution hour targets as custom fields on migrated tickets. Actual SLA breach status is not migrated as it is evaluated dynamically by the destination platform. Zoho Desk's SLA Policies are created by the admin post-migration using the preserved metadata as configuration input.

Post-incident and post-request satisfaction surveys are evaluated by ZSD's built-in survey engine and are tightly coupled to the ZSD survey configuration schema. These records are not migrated because Zoho Desk has its own CSAT survey configuration that is not compatible with ZSD's survey data format. We note the existence and record count of satisfaction ratings in the migration inventory for the customer's awareness, but they do not transfer.

ZSD maintains an immutable audit trail for compliance purposes tied to the source appliance instance. These logs are not migrated as they are not portable in a meaningful way for Zoho Desk to consume, and Zoho Desk maintains its own independent audit trail from go-live forward. Compliance teams should archive the ZSD audit log export separately before decommissioning the source appliance.