Migrate from OpenText ZENworks Service Desk to HubSpot Service Hub

ZSD Incidents map to HubSpot Tickets. Title maps to ticket subject, Description maps to the initial ticket body, Priority maps to HubSpot ticket priority (high/medium/low), and Status maps to the HubSpot pipeline stage. Affected CI reference migrates to a custom ticket property if the customer configures a CI custom object, or remains as a text reference. Assigned technician maps to the HubSpot ticket owner by email match against the User table. We preserve the original ZSD incident ID as a custom property for audit traceability.

ZSD Service Requests follow the same schema as Incidents but use a distinct workflow type. Request type maps to a HubSpot ticket property or pipeline tag, and the Catalog Category reference migrates to a custom field. Approval assignments on requests are exported as structured metadata in the ticket notes rather than as live approval configurations, since HubSpot does not have a direct approval chain engine equivalent to ZSD's workflow engine.

ZSD Changes have no direct HubSpot equivalent. We map Change records to HubSpot Tickets with a set of custom properties: Change Owner becomes ticket owner, CAB status becomes a single-select property, Risk/Impact/Urgent flags become checkbox or multi-select properties, and Scheduled Start/End dates map to date properties. Linked Incidents are preserved as ticket associations. The customer's admin rebuilds the change review workflow in HubSpot using Workflows or a custom object. We deliver a written Change inventory document listing every ZSD Change, its fields, and its linked records.

ZSD Problem records with root cause analysis and linked Known Errors have no native HubSpot equivalent. We create a HubSpot custom object named Problem during migration scope setup, with fields for root_cause, known_error_reference, and linked_incident_count. If the customer does not license HubSpot custom objects, Problems are consolidated into Ticket notes with a structured prefix (PROBLEM: root cause...). The Problem-Known Error association migrates as a custom property reference.

ZSD Knowledge Articles map to HubSpot Knowledge Base articles. Title, body (HTML), keywords, and category migrate. We flag articles with complex HTML structures (nested tables, embedded scripts, or non-relative image URLs) for post-migration review because HubSpot's Knowledge Base renders a subset of HTML and image references may break on cutover. We provide a content diff report for the customer's knowledge base team to review article integrity after migration.

ZSD Configuration Items with CI Class (Hardware, Software, Service), Name, Serial Number, Status, and owner map to a HubSpot custom object named CI. CI relationship maps migrate as a custom relationship property linking two CI custom object records. If the customer does not license custom objects, CI data is appended to the relevant Company record as text properties. CI Class hierarchy is preserved as a multi-select property on the CI custom object.

ZSD User records (login name, email, full name, phone, location, department, manager hierarchy) map to HubSpot Contacts. We bypass ZSD's broken Entra ID import module by querying the source Active Directory or Entra ID directly and matching users by UPN or object GUID. Manager hierarchy migrates to HubSpot's manager association property if the customer has configured it, or as a text reference. Inactive users who are still ticket assignees are preserved as Contacts with a deactivated-owner flag.

Attachments linked to Incidents, Service Requests, Changes, or Knowledge Articles migrate as HubSpot Files attached to the parent record. We export file blobs from ZSD's storage volume alongside association metadata. Large attachment volumes (over 10 GB) may require chunked transfer and are flagged during scoping. Inline images in Knowledge Articles migrate separately as Content documents and are re-linked in the article body post-migration.

SLA timers, priority mapping, and calendar definitions from ZSD migrate as metadata. SLA name and response/resolution hour targets are written to a custom HubSpot SLA configuration document for the customer's admin to configure as HubSpot SLA objectives. The live breach state at migration time is not migrated because HubSpot recalculates SLA status on record creation. We preserve the ZSD SLA configuration as a written specification rather than an active object.

Approval chains and multi-step workflows from ZSD's workflow engine are exported as structured JSON metadata listing step order, approver, condition, and action. HubSpot Workflows are a different automation model (record-triggered property changes and internal notifications) and do not accept migrated workflow definitions. We deliver a written Workflow and Approval inventory document for the customer's admin to reference when rebuilding approval chains in HubSpot.

Post-incident and post-request satisfaction surveys are tightly coupled to ZSD's survey engine and do not port to HubSpot Service Hub's feedback tools. Survey response history, CSAT scores, and survey configuration are not migrated. We flag survey records in the data inventory so the customer's admin knows to configure HubSpot's post-conversation surveys in Service Hub Professional or Enterprise after cutover.

ZSD maintains an immutable audit trail tied to the source appliance instance for compliance purposes. These records are not migrated as they are bound to the ZSD database context and have no operational meaning in HubSpot. We document the existence of audit log data and its retention period so the customer's compliance team can determine whether the logs need to be archived separately before ZSD decommissioning.