Migrate your OpenText ZENworks Service Desk data

Incidents are the core object in ZENworks Service Desk and are stored with standard ITIL fields: Title, Description, Category, Priority, Status, Assigned Technician, Affected CI, and SLA timers. We extract incident records via database query or REST API and map them directly to the target platform's ticket or case object.

Service Requests follow the same schema as Incidents but use a distinct workflow type in ZSD. Request definitions are linked to Catalog Categories and Approval Workflows. We preserve the request type, linked workflow steps, and requestor information during migration.

Changes are stored with full ITIL change management fields: Change Owner, Change Advisory Board status, Risk/Impact/Urgent flags, Scheduled Start/End, and linked Incidents. We extract change records with their full lifecycle history and map them to the target's change or release object.

Problem records store root cause analysis, linked Known Errors, and关联 Incidents. The Problem-Known Error association requires explicit mapping to the target platform's problem management schema, as not all ITSM tools maintain a separate Known Error object.

Knowledge Articles in ZSD are stored with title, content, keywords, category, and visibility flags. HTML content and embedded links may require re-encoding during migration. We preserve the article body text and keyword metadata; formatting parity depends on the target platform's rich-text handling.

Configuration Items are stored with CI Class (Hardware, Software, Service), Name, Serial Number, Status, and linked owner. We export CIs with their class hierarchy and relationship map to the target platform's CMDB, noting that CI relationship types may not map 1:1 across platforms.

User records include login name, email, full name, phone, location, department, and manager hierarchy. We handle Microsoft Entra ID import failures by cross-referencing the AD source directly, since ZSD's built-in import is known to have synchronization gaps.

Attachments are stored as file references linked to Incidents, Requests, Changes, or Knowledge Articles. We export the file blobs alongside their association metadata. Large attachment volumes may require chunked extraction to avoid timeouts.

Approval chains and multi-step workflows are stored as configuration in ZSD's workflow engine. We export workflow step definitions and approval assignments as structured metadata rather than live configurations, since the target platform's workflow engine will re-evaluate routing rules independently.

SLA timers and calendar definitions are stored per ZSD configuration. We preserve the SLA name, priority mapping, and response/resolution hour targets as metadata fields. Actual SLA breach status is not carried forward since the target platform will recalculate based on its own calendar.

Post-incident and post-request satisfaction surveys are evaluated by ZSD's built-in survey engine. These records are tightly coupled to the ZSD survey configuration and are not migrated, as the target platform will manage its own satisfaction workflows independently.

ZSD maintains an immutable audit trail for compliance purposes. These logs are not migrated as they are tied to the source instance and are not portable in a meaningful way for the target platform to consume.