Migrate from Hesk to Intercom

Hesk Tickets map to Intercom Conversations. Hesk subject becomes Conversation title, Hesk message and thread become Conversation Parts in chronological order. Hesk ticket status (open, pending, resolved, closed) maps to Intercom Conversation state (open, resolved, closed). Priority from Hesk migrates as a custom conversation attribute. We extract the full ticket thread from Hesk's ticket_messages table and replay it as Intercom Conversation Parts with correct author attribution (Contact vs Teammate) resolved from the user_id reference.

Hesk Categories are flat ticket-routing labels with no hierarchy. Intercom Inboxes are the assignment container for Conversations and require pre-creation in the destination workspace before migration begins. We map each Hesk Category to an Intercom Inbox (or to Inbox plus tag if the team uses fewer Inboxes than Hesk Categories) and document the mapping. The customer configures their Inbox structure before migration so that the inbox_id foreign key is satisfied during import.

Hesk end users (the customers who submit tickets) map to Intercom Contacts. Email, name, phone, IP address (flagged for GDPR review), and creation date migrate. Hesk allows emailless users for phone-only contacts — we handle these by creating Contacts with a placeholder email domain and flagging them for the customer's review post-migration. Hesk custom fields on users map to Intercom custom attributes on the Contact object.

Hesk Staff accounts (administrator, manager, agent roles) map to Intercom Teammates. The Hesk role hierarchy maps to Intercom's teammate permissions (admin, agent, viewer). Password hashes from Hesk's MySQL bcrypt storage cannot migrate to Intercom — staff receive invite emails to set passwords in the new workspace. We map Hesk staff IDs from ticket ownership to Intercom teammate IDs by email match.

Hesk KB articles (title, HTML body, category association, attachments) map to Intercom Articles in the Knowledge Hub. Hesk KB categories map to Intercom Collections. We preserve article body as HTML where supported and fall back to plain text for sections that use non-migratable markup. Intercom's article state (published, draft) maps from Hesk's article visibility flag. Articles are imported into Intercom's API and then linked to Collections via the workspace's Collection structure configured before migration.

Hesk KB categories are simple name-description rows referenced by article and ticket foreign keys. Intercom Collections are containers for Articles with optional sub-collection nesting. We map each Hesk KB category to an Intercom Collection, preserving the category name and creating a Collection for each. If the customer has a flat Hesk category structure, we create a single-level Collection hierarchy; if they have nested categories, we replicate the hierarchy as parent and child Collections in Intercom.

Hesk custom fields are stored as field definitions in a custom fields table with values linked to tickets or users. Intercom custom attributes must be pre-created in the workspace before data import because the API requires the attribute to exist before data can be written to it. We enumerate all Hesk custom field definitions during discovery, map their data types (string, boolean, date, number, select, multi-select) to equivalent Intercom attribute types, and pre-create them via the Intercom API before the main migration pass.

Hesk canned responses are stored as title and HTML content rows in the database. Intercom Saved Responses are pre-written templates accessible to teammates during conversation resolution. We export Hesk canned responses as a flat list, clean any non-HTML markup, and import them to Intercom via the Saved Responses API. Ordering and category grouping from Hesk (if used) maps to Saved Response tags in Intercom for discoverability.

Hesk attachments live on disk with file paths stored in MySQL. The files directory must be exported alongside the database records. We copy the files to a staging location accessible to the migration process, upload each file to Intercom via the Attachments API, and link the resulting Intercom attachment URL to the correct Conversation Part or Article. If the destination Intercom workspace uses a different domain or subdomain than the source Hesk installation, attachment URLs are re-mapped post-import to point to the correct Intercom-hosted location.

Hesk logs ticket events (opened, replied, status changed, assigned) in a ticket_history table. Intercom represents every action in a Conversation as a Conversation Part. We export the full Hesk ticket history, map each event type to an Intercom Conversation Part type (comment, note, assignment, status_change, open, close), preserve the original timestamp, and attribute it to the correct Teammate or Contact based on the user_id reference. Note-type parts from Hesk become note-type parts in Intercom.