Migrate from Hornbill Service Manager to Zendesk

Hornbill Incidents map directly to Zendesk Tickets. We preserve the Hornbill incident_id in a custom ticket field hsm_incident_id__c for audit traceability. Status, Priority, and Assigned Analyst from Hornbill map to Zendesk Status, Priority, and Assignee. The Hornbill customer field maps to Zendesk Requester. Incident-specific fields (impact, urgency, resolution category) migrate to Zendesk custom ticket fields. Incident conversations and work notes map to Zendesk Comments (public and private respectively).

Hornbill Requests (the primary service desk entity) map to Zendesk Tickets with the Hornbill request type preserved in a custom field hsm_request_type__c. The catalog item reference from Hornbill (a GUID-linked entity) is stored as text in hsm_catalog_item__c to preserve service catalog context without expecting Zendesk to resolve the GUID. Workflow stage from Hornbill maps to a custom field hsm_workflow_stage__c, and the original workflow name maps to hsm_workflow_name__c.

Hornbill ServiceRequests are tied to the service catalog with workflow GUID associations. We export the full record including custom form fields. Catalog item references are stored as text in hsm_catalog_item__c. Workflow GUIDs are stripped and the original workflow name is stored in hsm_workflow_name__c. Because Zendesk has no native catalog item concept, the catalog context is preserved as structured text for the customer's admin to build a Zendesk Product or Category equivalent.

Hornbill ChangeRequests carry CAB approval history, risk assessments, and implementation schedules. We map these to Zendesk Tickets with custom fields hsm_change_type__c (Standard/Normal/Emergency), hsm_risk_assessment__c, hsm_cab_approval_status__c, and hsm_implementation_schedule__c. The approval chain status and calendar entries are stored as structured text in a custom field rather than as Zendesk native approval workflows, which are not migrated. CAB meeting dates and blackout window references migrate as text fields for admin review.

Hornbill Problem records include root cause analysis and impact assessment. We map Problem records to Zendesk Tickets with the status preserved in hsm_problem_status__c and root cause text in hsm_root_cause__c. Linked KnownErrors are stored in hsm_known_errors__c as a text list. Zendesk does not have a native Problem-KnownError relationship model, so we preserve the association via custom fields and a ticket linking strategy.

Hornbill KnownErrors store accepted solutions and workarounds linked to Problems. If the customer migrates the Knowledge Base to Zendesk Guide, KnownErrors migrate as Articles under a dedicated 'Known Errors' section. If the Knowledge Base is not migrated, KnownError workaround text migrates as an internal Zendesk Comment on the linked Problem Ticket with a tag hsm_known_error for retrieval.

Hornbill Assets carry hardware and software inventory, CI relationships, and owner assignments. Zendesk does not have a native Configuration Item object in Support (ITSM features are in a separate product tier). We migrate asset records as Zendesk User fields (for assets assigned to a person) or Organization fields (for assets assigned to a location or department), with CI type, status, and serial number stored in custom fields. CI-to-CI relationships are stored as text in a custom field for manual recreation in Zendesk Explore or a Marketplace CI app post-migration.

Hornbill Suppliers are first-class entities with associated contacts and contracts. We map Supplier records to Zendesk Organizations, with the supplier type and category preserved in custom Organization fields org_supplier_type__c and org_category__c. SupplierContacts migrate as Zendesk Users attached to the Organization.

Hornbill SupplierContract records reference linked Suppliers and carry renewal dates, SLA terms, and cost information. Contract metadata migrates to custom fields on the corresponding Zendesk Organization (contract_end_date__c, contract_sla_tier__c, contract_value__c). Contract document attachments require a separate file export from Hornbill's document repository and upload to Zendesk's file attachments API, handled as a parallel migration workstream.

Hornbill KB articles have approval workflows and category assignments tied to the service catalog. We export article content, title, and category associations. Article approval states (Draft, Published, Archived) do not migrate directly; we set migrated articles to Published status in Zendesk Guide with the original approval state stored in a custom field hsm_article_status__c. Category hierarchy from Hornbill maps to Zendesk Guide Section and Category structures. Note that Zendesk Guide is a separate product activation requiring the customer's Zendesk admin to enable it before article migration begins.

Hornbill Users with assigned Roles and team memberships map to Zendesk Users. Hornbill Teams map to Zendesk Groups. We resolve users by email match. Any Hornbill user without a matching Zendesk User goes to a reconciliation queue for admin provisioning before ticket migration. Hornbill Role definitions do not map directly to Zendesk's Agent roles (Admin, Agent, End User) because the permission models differ; we document the closest Zendesk role as a recommendation for the admin to finalize.