Migrate from Hornbill Service Manager to Gorgias

Hornbill Incidents map to Gorgias Tickets. The Hornbill incident ID is preserved as a text custom field h_hornbill_incident_id__c on the Ticket for audit traceability. Priority and status from Hornbill (New, InProgress, Pending, Resolved, Closed) map to Gorgias Ticket status values. The assigned analyst from Hornbill resolves to a Gorgias Agent by email match. Incidents without a Hornbill SLA record linked are imported without SLA context; those with SLA records require the SLA pre-seeding step to complete before the incident import phase begins.

Hornbill Requests (the primary service desk entity) map to Gorgias Tickets. Hornbill's h_summary maps to Gorgias Ticket subject, h_description maps to the first message body. Request type and category are stored as Ticket tags or custom fields since Gorgias lacks a native Request type concept. Hornbill workflow stage associations embedded in the request record are stripped; the current workflow stage is stored as a text tag for the customer's admin to recreate in Gorgias Rules post-migration.

Hornbill ServiceRequests carry catalog item associations and workflow GUIDs that are not portable. We export the ServiceRequest record and store the catalog item name as a text tag on the destination Ticket, preserving the service catalog context without attempting to create Hornbill GUIDs in Gorgias. Workflow associations are documented in the migration inventory for the customer's admin to rebuild as Gorgias Rules or Macros.

Hornbill ChangeRequests carry CAB approval history, risk assessments, and implementation schedules. Gorgias has no ChangeRequest equivalent. We create a Ticket with type Change and store CAB approval status, risk level, and implementation date in custom fields. The change calendar and blackout window configurations are system-level settings in Hornbill and do not transfer; we flag them as manual configuration items in the destination.

Hornbill Problems with root cause analysis and linked KnownErrors do not have a Gorgias equivalent. We evaluate each Problem record: if it has active linked Incidents, we create a Ticket in Gorgias and store the root cause analysis as ticket notes; if it represents a resolved known error with a documented workaround, we create a Help Center article in Gorgias with the solution content. The decision is made per Problem during scoping.

KnownError records store accepted solutions and workarounds linked to Problems. We export the workaround text, solution details, and linked incident references, then create Gorgias Help Center articles with this content. KnownError approval states and Hornbill KB article workflow statuses do not transfer; articles are created in draft state for the customer's admin to review and publish.

Release records tied to Hornbill's release calendar and blackout window configurations are not migratable to Gorgias. Gorgias has no release calendar or deployment scheduling concept. We export release record metadata (name, target date, status) as a CSV delivered to the customer's admin for manual entry into any third-party release management tooling they adopt alongside Gorgias.

Hornbill Assets carry hardware and software inventory, CI relationships, and owner assignments. Gorgias has no asset management module. We export the asset inventory as a structured CSV (asset name, type, status, assigned user, linked configuration items) for the customer to import into a dedicated ITAM tool or to reference manually within customer support interactions. CI relationships do not transfer.

Hornbill Suppliers are first-class entities with associated contacts, contracts, and supplier-managed assets. Gorgias has no Supplier or vendor management concept. We export Supplier records as a CSV (supplier name, contact name, contact email, contract renewal date) for the customer to manage outside Gorgias or to create as Customer records if the supplier is also a support contact.

Hornbill SupplierContract records reference linked Suppliers and carry renewal dates, SLA terms, and cost information. Document attachments on contracts live in Hornbill's file repository and require separate file transfer via Hornbill's document API. We export contract metadata as a CSV and handle file attachment export separately, associating exported files with the corresponding contract CSV row by filename matching. Contract metadata does not enter Gorgias.

Hornbill KB articles have approval workflows and category assignments. We export article content and category associations, but approval states reset on migration. Articles are imported into Gorgias Help Center in draft state. The customer's admin reviews and publishes them. Hornbill article GUIDs and workflow associations are stripped; category assignments map to Gorgias Help Center sections if a matching section exists, otherwise articles are placed in an Uncategorized section.

Hornbill analysts are mapped to Gorgias Agents by email address. Display name, team assignment, and role are preserved in Agent metadata. Hornbill role definitions (Service Desk Admin, Analyst, etc.) do not transfer directly; Gorgias has agent and admin roles only. Team structures are mapped to Gorgias teams where a matching team exists or is created, otherwise agents are assigned to a default team.

Hornbill request conversation threads are imported as Ticket messages in chronological order. Each message carries the sender (analyst or customer), timestamp, channel (email, portal, phone logged as note), and message body. Thread integrity is preserved by sorting on the Hornbill message timestamp before insert. Attachments within threads are handled via the document API export step.