Migrate from OpenText ZENworks Service Desk to Salesforce Service Cloud

ZSD Incidents map to Salesforce Case. The ZSD incident title becomes Case Subject, description maps to Description, and Category maps to a custom picklist or Salesforce Category depending on the target org's configuration. Priority maps to Case Priority with a value-mapping table. Assigned technician resolves by email to Salesforce User; unresolved owners enter a reconciliation queue. SLA response and resolution timers migrate as informational custom fields (zsd_response_hours__c, zsd_resolution_hours__c) because Salesforce SLA milestones are recalculated from the Case creation date on import rather than carried as running clocks.

ZSD Service Requests map to Salesforce Case using a dedicated Record Type (e.g., 'Service Request') that separates the workflow from Incidents. The request type, linked Catalog Category, and Approval Workflow reference migrate as custom fields. Request definitions and approval chain assignments are preserved as metadata for rebuild in Salesforce Flow approval processes rather than as active configurations. We export the approval step sequence as a structured JSON document delivered alongside the migration.

ZSD Change records carry ITIL fields including Change Owner, CAB status, Risk/Impact/Urgent flags, and Scheduled Start/End dates. These map to a Salesforce Case with a 'Change' Record Type or to a custom Change__c object depending on the destination org's schema design. Linked Incidents connect via lookup or a junction object to preserve the Change-Incident association. Risk and Impact scores migrate as custom fields since Salesforce has no native risk classification model.

Problem records store root cause analysis, linked Known Errors, and associated Incidents. Since Salesforce Service Cloud has no native Problem object, we create a custom Problem__c object during schema design. The Known Error association migrates as a custom field or related list. Linked Incidents resolve via the ZSD incident reference number, which we cross-reference to the migrated Salesforce Case by external ID. The Problem-Known Error link requires explicit mapping because ZSD stores this as a separate association table.

ZSD Knowledge Articles map to Salesforce Knowledge ArticleVersion records. Article title, summary, keywords, and visibility flags migrate directly. HTML content migrates as rich text preserved in Salesforce's knowledge article body field, but HTML entities, embedded image references, and non-standard character encodings may render differently in Salesforce's editor. We flag all articles for post-migration review, provide a content diff report comparing the ZSD source HTML to the Salesforce-rendered output, and note any broken links for editorial correction.

ZSD Configuration Items store CI Class (Hardware, Software, Service), Name, Serial Number, Status, and linked owner. Salesforce Service Cloud has no native CMDB object, so the mapping requires a design decision: hardware CIs map to Salesforce Asset, software and service CIs require a custom CI__c object. We export the CI class hierarchy and map it to the Asset record type or custom object accordingly. CI relationships (parent-child, dependency, network connectivity) are stored as custom fields or junction objects (CI_Relationship__c) to preserve the ZSD relationship map in the target.

ZSD User records contain login name, email, full name, phone, location, department, and manager hierarchy. We bypass ZSD's broken Microsoft Entra ID import module by querying Active Directory directly and resolving users by UPN or ObjectGUID. The manager hierarchy migrates as the ReportsTo field on User. Any users provisioned directly in ZSD that do not exist in AD enter a reconciliation queue for the customer's identity team to resolve before migration. Service Cloud agents require an active Salesforce User license; non-agent users may be stored as Contact records.

ZSD attachments are stored as file blobs in the database linked to Incidents, Requests, Changes, or Knowledge Articles. We export the binary file data alongside the association metadata. Files are uploaded to Salesforce as ContentVersion records (creating ContentDocument entries) and linked to the parent Case or Knowledge Article via ContentDocumentLink. Large attachment volumes (individually exceeding 25 MB or totaling over 10 GB) require batch chunking and memory-managed extraction to avoid database timeout.

ZSD SLA timers and calendar definitions carry the SLA name, priority-to-tier mapping, and response/resolution hour targets. We preserve these as custom fields on Case (zsd_sla_name__c, zsd_response_hours__c, zsd_resolution_hours__c) for reporting against the historical ZSD SLA tier. Any ZSD timer state data (time remaining before breach at migration time) migrates as informational fields only. Actual SLA breach calculation requires rebuilding as a Salesforce Entitlement Process post-migration, which we document as a separate handoff item.

Approval chains and multi-step workflows are stored as ZSD workflow engine configurations and do not migrate as live Salesforce Flow definitions. We export the step sequence, condition logic, approval routing assignments, escalation tiers, and field triggers as a structured JSON metadata document. This document maps directly to Salesforce Flow record-triggered and approval process components for the customer's admin or a Salesforce partner to rebuild post-migration.