Migrate from Hesk to Gorgias

Hesk Tickets map to Gorgias Tickets via subject, message body, status, priority, owner (Staff), and category references. Hesk ticket ID is stored as external_id in Gorgias for reconciliation. Status values (New, Waiting, Replied, Resolved, Closed) map to Gorgias status labels. Priority values map to Gorgias priority (Low, Normal, High, Urgent). Custom field values stored in Hesk's hesk_ticket_custom_fields table are read per ticket and written to Gorgias custom fields by object type (Ticket or Customer) and field label match.

Hesk Users (end customers) map to Gorgias Customers by name, email, and phone. Hesk stores IP address and creation date; these migrate to Gorgias as custom fields or metadata if needed for GDPR scope. Hesk allows emailless users for phone-only contacts; Gorgias Customer requires at least an email or phone, so phone-only Hesk users are created with a placeholder email and flagged for admin review.

Hesk Staff accounts (name, email, role: administrator/manager/agent) map to Gorgias Agents. Hesk password hashes (bcrypt) cannot be migrated to Gorgias because Gorgias uses its own authentication system; agents receive invitation emails to set passwords post-migration. Role mapping: Hesk administrator and manager map to Gorgias admin; Hesk agent maps to Gorgias agent. Owners without an email match in Gorgias are held in a reconciliation queue for the customer to provision.

Hesk ticket categories map to Gorgias Teams. Teams in Gorgias are used for routing and ticket assignment, not just grouping. We preserve Hesk category names and descriptions as Team names, and optionally create a separate Category label mapping if the customer needs both routing teams and subject-matter categories. Category assignment on tickets is preserved as a custom field if Teams are used for routing instead.

Hesk KB articles (title, HTML content, category association, attachments) map to Gorgias Knowledge Base articles. HTML content migrates as article body. Hesk KB categories map to Gorgias article categories. Inline images are extracted from Hesk's file-system paths, uploaded to a temporary CDN or directly to Gorgias, and URL references are updated in the article body before import. Article publication status maps from Hesk's article visibility flag.

Hesk canned responses (title, HTML content) map to Gorgias Macros. Because Hesk stores canned responses as flat database rows without conditions or actions, they import as Gorgias macros with default conditions set to 'always applies' for the customer's admin to add conditions and ticket rules post-migration. We deliver a written inventory of all migrated macros with the original Hesk content so the admin can enrich them in Gorgias's macro editor.

Hesk ticket custom fields are read from hesk_ticket_custom_fields and mapped to Gorgias Ticket custom fields by label match. Hesk field types (text, number, checkbox, dropdown, date) are matched to Gorgias field types (text, number, boolean, dropdown, date). If Hesk uses a type that Gorgias does not support natively, we store the value as a text custom field and flag it for the customer's admin. Custom field definitions must be created in Gorgias before ticket import begins because Gorgias requires the field to exist before values can be written.

Hesk user custom fields (hesk_user_custom_fields table) map to Gorgias Customer custom fields following the same type-matching logic as ticket custom fields. Customer custom fields are created in Gorgias during the schema phase before any customer records are imported. Values are written during the customer import phase.

Hesk stores attachments on the file system with paths in MySQL (hesk_attachments table). We export the entire attachments directory alongside the database extract, upload files to a temporary storage endpoint, and write the corresponding URLs into the ticket message body and any inline image references before importing into Gorgias. Path remapping is required if the destination Gorgias domain differs from the Hesk hostname.

Hesk logs ticket events (opened, replied, status change, assignment) in hesk_ticket_history. We export the full history and merge it into Gorgias ticket events. Not all Hesk history event types have a direct Gorgias equivalent, so we collapse Hesk-specific internal log entries into a single 'Note' event on the ticket and flag the merged entries in the delivery report. Historical reply content migrates as additional messages on the Gorgias Ticket.

Hesk settings (email routing, ticket field visibility, status labels, branding) are exported as a configuration bundle. We map equivalent settings to Gorgias (email integration settings, ticket field configuration, company branding). Settings that have no Gorgias equivalent (server-level mail configuration, PHP cron-based reminders) are documented as manual-configuration items for the admin to address post-migration.

If the customer requests GDPR anonymisation before migration, we apply Hesk's built-in anonymisation to strip PII (name, email, IP address) from selected records. This decision must be made before database extraction because anonymisation alters the source data. We clarify the GDPR scope with the customer upfront, document which records are anonymised, and flag any ticket subjects or thread content that may still contain indirect identifiers after anonymisation.