Migrate from Hornbill Service Manager to Intercom

Hornbill Incidents map to Intercom Conversations if the use case is real-time or threaded customer communication, or to Intercom Tickets if the use case is structured, trackable requests with defined states. We determine the correct target object during scoping based on the customer's ticket volume, channel mix, and whether the Hornbill Incidents are primarily internal IT issues or customer-facing support requests. Priority, status, and assigned analyst from Hornbill become custom attributes or conversation tags in Intercom. SLA breach status migrates as a custom field since Intercom's SLA tracking applies at the inbox rule level rather than on individual records.

Hornbill Requests map to Intercom Conversations or Tickets following the same scoping decision as Incidents. Request type, category, and current workflow stage in Hornbill map to Intercom conversation tags, custom attributes, or Ticket status fields. Hornbill catalog item references (which carry Hornbill-specific GUIDs) are stripped of the GUID and stored as plain text in a custom Intercom field to preserve the service catalog context without carrying non-portable identifiers. We flag any SLA-linked catalog item associations for pre-seeding before the request records are imported.

Hornbill ChangeRequests carry CAB approval history, risk assessments, implementation schedules, and calendar-linked blackout window references. Intercom has no Change Management module, CAB workflow, or risk assessment record type. We do not migrate ChangeRequests as code or process records. We extract the change record metadata (description, dates, affected services) as a plain-text summary document and deliver it to the customer for manual rebuild in their chosen change management system. Change calendar and blackout window configurations are system-level Hornbill settings and are not migratable.

Hornbill Problem records include root cause analysis, impact assessment, and linked KnownErrors. Intercom has no Problem Management entity. We convert Problem records to Help Center articles with the problem description as the article title, the root cause analysis as the article body, and the impact assessment as article metadata or tags. The article is placed in a dedicated collection (e.g., 'Known Issues') that the customer names during scoping. Problem-to-Incident linkage is not preserved in Intercom because Intercom has no mechanism for linking articles to conversation threads by problem relationship.

Hornbill KnownErrors store accepted solutions, workarounds, and linked incidents. We convert KnownError records to Intercom Help Center articles with the known error title as the article title, the workaround text as the body, and the accepted solution as a separate article section or tag. KnownError-to-Problem linkage is not preserved in Intercom. If the customer's Hornbill instance uses the KnownError-KnowledgeBase article relationship, we consolidate the KnownError and linked KB article content into a single Help Center article during import.

Hornbill KnowledgeBase articles migrate to Intercom Help Center articles. Hornbill article category assignments map to Intercom collections and sections. We preserve article body content, attachments, and any custom metadata fields. Hornbill article approval workflow states (Draft, Pending Approval, Published, Archived) do not transfer; all imported articles land in Draft status and require the customer to republish through Intercom's Help Center workflow. Multi-language Hornbill articles require manual language assignment per article in Intercom after import.

Hornbill Assets carry hardware and software inventory, CI relationships, owner assignments, and asset status. Intercom has no asset management module. We extract asset records as structured data and attach the asset context to the relevant migrated Contact or Conversation as a JSON blob in a custom Intercom field. CI relationships (which server relates to which service, which user owns which device) are stored as plain-text notes. If the customer requires a full asset registry post-migration, we recommend a dedicated ITAM tool such as Snipe-IT, Lansweeper, or Hornbill ITAM retained separately.

Hornbill Suppliers and SupplierContracts carry renewal dates, SLA terms, cost information, and supplier-managed asset associations. Intercom has no supplier or contract management entity. We extract supplier name, primary contact, and contract renewal date as custom Contact attributes for any related migrated record. Contract document attachments require separate file handling via Hornbill's document API and are delivered as a named file package for manual association by the customer.

Hornbill Users map to Intercom Admins and Operators. Hornbill user records carry display name, email, manager assignment, and team membership. We map by email match to resolve the destination user. Team membership from Hornbill maps to Intercom Team assignment. Hornbill Rights and Role definitions (which define what a user can do within the ITSM platform) do not have a direct Intercom equivalent and are documented as a permission-gap analysis for the customer to reconcile against Intercom's Admin, Agent, and Operator permission model post-migration.

Hornbill Teams with assigned Roles and Rights map to Intercom Teams. Hornbill team-level assignment rules for Incidents and Requests become Intercom Team assignment rules in the inbox configuration. The mapping preserves team name and operator membership; Hornbill Role-based routing logic requires rebuild as Intercom rules with condition-based assignment. We deliver a written inventory of each Hornbill team routing rule and its recommended Intercom rules-based equivalent.

Hornbill SLA definitions are external Service Level Agreement records linked to Incidents and Requests via catalog item associations, not stored on the request entity itself. We pre-seed Intercom SLA Service Level Agreements before importing any request records. Each Hornbill SLA record (name, target response time, target resolution time, business hours) maps to a corresponding Intercom SLA definition. This pre-seeding step is mandatory and must be completed during the scoping phase; we flag it as a migration-critical dependency in the discovery document.

Hornbill custom fields are defined per entity in Configuration across Summary Fields, Detail Fields, Create Fields, and List Fields tabs. We export all custom field values regardless of tab assignment. Hornbill field types (text, number, date, dropdown, checkbox, multi-select) map to the corresponding Intercom custom attribute types. Hornbill Summary Fields map to conversation attributes visible in the conversation sidebar; Detail Fields map to custom conversation attributes or article metadata depending on the parent entity. We validate type compatibility during the field mapping phase and flag any Hornbill field types that have no direct Intercom equivalent for case-by-case handling.