Helpdesk migration
Field-level mapping, validation, and rollback between Hesk and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
Hesk
Source
Zendesk
Destination
Compatibility
6 of 11
objects map 1:1 between Hesk and Zendesk.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Hesk to Zendesk is a database-first migration to an API-first destination. Hesk has no public REST API, so we connect directly to the MySQL instance to extract Tickets, Knowledge Base articles, Categories, Users, Staff Accounts, Custom Fields, Canned Responses, and Ticket History. Zendesk receives all data via its REST API or CSV import, and we handle the transformation of Hesk's flat ticket structure into Zendesk's Comment-based threading model. Attachment files live on Hesk's file system alongside database path references; we export both together and re-map attachment URLs post-import into Zendesk's media storage. Hesk's flat category hierarchy maps to Zendesk Guide's Section and Category model. Workflows, custom scripts from the Mods-for-HESK community, and Hesk's email piping configuration do not migrate; we document these for the customer's admin to rebuild in Zendesk.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Hesk object lands in Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Hesk
Ticket
Zendesk
Ticket
1:1Hesk tickets map to Zendesk tickets with subject, description, status, priority, and category preserved. Hesk's linear reply history in the ticket-track table transforms into Zendesk's Comment records, splitting each reply into a public or private Comment based on Hesk's iscustomer flag. Original Hesk ticket ID is stored in a Zendesk custom field zesk_original_id__c for cross-referencing. Status values (open, resolved, closed, pending) map to Zendesk ticket Status; custom Hesk statuses are re-created as Zendesk custom field values.
Hesk
Ticket History
Zendesk
Ticket Comments
1:1Hesk logs each ticket event (opened, replied, status change, assignment) as a separate row in the ticket-tracking table. We transform this into Zendesk Comment records ordered by timestamp. Agent replies become public comments; customer replies are imported as requester comments. Event-type entries (status changes, assignment changes) without body content are stored as private Comments with a system-generated note for audit purposes.
Hesk
Knowledge Base Article
Zendesk
Zendesk Guide Article
1:1Hesk KB articles (title, HTML content, category association, attachments) map to Zendesk Guide articles inside Sections. We preserve article HTML as the body, map Hesk category to the corresponding Zendesk Section, and handle inline images by exporting from Hesk's file system and uploading to Zendesk's media service with URL re-mapping in the article HTML. Hesk's article draft/published flag maps to Zendesk's draft/published status.
Hesk
KB Category
Zendesk
Zendesk Guide Section
lossyHesk's flat category structure maps to Zendesk Guide Sections. If the customer uses nested Hesk categories, we flatten them into a single section hierarchy during migration or create a top-level Category in Zendesk Guide as the container. We document the original Hesk category tree as metadata on each article for post-migration restructuring if needed.
Hesk
User (End User/Customer)
Zendesk
End User
1:1Hesk end-user records (name, email, IP address, created date) map to Zendesk End User records. Email is the dedupe key. Hesk's IP address field is stored in a Zendesk custom field hesk_ip__c for GDPR audit purposes. Any Hesk user records without a valid email address are held in a reconciliation queue; Zendesk requires a valid email for End User accounts. GDPR anonymisation requests are processed before migration if the customer has a data-cleanup requirement.
Hesk
Staff Account
Zendesk
Agent
1:1Hesk staff accounts (name, email, role: administrator/manager/agent, password hash) map to Zendesk Agent profiles. Hesk's role hierarchy (admin > manager > agent) maps to Zendesk's agent, admin, and light agent roles. We do not migrate password hashes because Hesk uses bcrypt and Zendesk uses its own authentication; staff accounts are provisioned in Zendesk with temporary passwords set by the customer's admin. The customer's admin maps Hesk staff IDs to Zendesk Agents before migration to preserve assignment history.
Hesk
Custom Field (Ticket)
Zendesk
Custom Ticket Field
lossyHesk per-ticket custom fields map to Zendesk custom ticket fields. Field types are matched: text to text, number to numeric, dropdown to dropdown, checkbox to checkbox. Hesk dropdown values become Zendesk dropdown options. We create the destination fields in Zendesk Admin Center before migration and map Hesk field values to the corresponding Zendesk field IDs. Multi-select checkboxes in Hesk map to Zendesk tag-based fields or multi-select picklists depending on the customer's reporting needs.
Hesk
Custom Field (User)
Zendesk
Custom User Field
lossyHesk per-user custom fields map to Zendesk user fields in Admin Center under People > Configuration > User fields. The same type-matching logic applies (text, numeric, dropdown, checkbox). These fields appear in the Zendesk agent interface when viewing end-user profiles.
Hesk
Canned Response
Zendesk
Macros
1:1Hesk canned responses (title, HTML content) map to Zendesk Macros. Each canned response becomes a Zendesk macro with the title preserved and the HTML body set as the macro body. Macros are created at the account level so all agents can access them. Private versus public visibility is not a Hesk feature, so all migrated macros default to account-level visibility in Zendesk.
Hesk
Attachment
Zendesk
Ticket Attachment
lossyHesk stores attachments on disk with paths (e.g., attachments/ticket_123/file.pdf) stored in MySQL. We export the entire attachments directory alongside the database, then upload each file to Zendesk's media service during the ticket import phase. Each ticket's MySQL attachment rows are matched to the corresponding Zendesk ticket ID post-upload, and the Zendesk attachment URLs are inserted as Comment attachments. If the destination Zendesk domain differs from the source Hesk domain, all attachment URLs are re-mapped in article HTML during KB import.
Hesk
Category (Ticket Category)
Zendesk
Ticket Field (Dropdown)
lossyHesk ticket categories (name, description) map to a Zendesk custom dropdown ticket field named Category. We create the Category field in Zendesk, import all category names as dropdown options, then update every ticket's category reference to use the Zendesk field option ID rather than the Hesk numeric category ID. The original Hesk category tree is documented for the customer to optionally restructure in Zendesk views.
| Hesk | Zendesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Ticket History | Ticket Comments1:1 | Fully supported | |
| Knowledge Base Article | Zendesk Guide Article1:1 | Fully supported | |
| KB Category | Zendesk Guide Sectionlossy | Fully supported | |
| User (End User/Customer) | End User1:1 | Fully supported | |
| Staff Account | Agent1:1 | Fully supported | |
| Custom Field (Ticket) | Custom Ticket Fieldlossy | Fully supported | |
| Custom Field (User) | Custom User Fieldlossy | Fully supported | |
| Canned Response | Macros1:1 | Mapping required | |
| Attachment | Ticket Attachmentlossy | Fully supported | |
| Category (Ticket Category) | Ticket Field (Dropdown)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Hesk gotchas
No REST API means all migrations are database-first
Moving Hesk between servers requires version parity
GDPR anonymisation may conflict with ticket preservation
Attachments are file-system references, not database blobs
Custom field limits are undocumented but exist
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Discovery and database access
We conduct a scoped discovery call with the customer's Hesk admin to confirm the Hesk version, MySQL access details (host, port, credentials, database name), attachment file-system path, custom field definitions, and any GDPR anonymisation requirements. We enumerate all Hesk MySQL tables and document the schema for the specific Hesk version in use. We confirm the Zendesk target account (edition, Guide enabled/disabled, existing custom fields, agent accounts) and verify API access. The discovery output is a written migration scope covering record counts, object mapping, and any pre-migration cleanup items.
Schema extraction and transformation design
We connect to the Hesk MySQL database and extract the full schema: tickets, ticket-tracking history, users, staff accounts, categories, custom field definitions and values, canned responses, and KB articles. We design the Zendesk target schema to include matching custom fields (created as Zendesk ticket fields and user fields before migration), a Category dropdown field, and any required custom fields for preserving original Hesk IDs. For Zendesk Guide, we create the top-level Categories and Sections based on the restructuring strategy agreed during discovery. All schema creation runs in the customer's live Zendesk environment or a staging org before production migration begins.
Attachment export and media preparation
We bundle the Hesk attachments directory (file-system path from MySQL attachment rows) into a structured archive organised by ticket ID. Inline images in KB articles are identified and extracted with their original filenames. We upload attachments to Zendesk's media service and record the Zendesk attachment URL for each file, building a lookup table (hesk_attachment_path -> zendesk_attachment_url) used during ticket and article import. Large directories are chunked to avoid timeout; the customer receives a pre-migration checklist for archiving resolved-ticket attachments if volume is a concern.
Sandbox validation and reconciliation
We run a full migration into the customer's Zendesk Sandbox (or a trial org) using production-equivalent data volume. The customer's Hesk admin reconciles record counts (tickets in, comments in, users in, articles in, agents in), spot-checks 25-50 random tickets against the Hesk source for field accuracy, verifies attachment links, and reviews the KB article rendering in Zendesk Guide. Any mapping corrections, missing dropdown values, or field type mismatches are resolved here before the production run. This phase typically takes three to five business days.
Production migration and delta sync
We run the production migration in dependency order: Zendesk Categories and Sections first, then End Users, then Agents (mapped by email), then Tickets with Comment history (using the original ID custom field for cross-reference), then KB articles with inline image URL re-mapping, then canned responses as Macros. Each phase emits a row-count reconciliation report. Any tickets created or modified in Hesk during the migration window are caught by a delta migration run immediately before cutover. Zendesk triggers and automations are disabled during import to prevent unwanted email notifications to customers.
Cutover, validation, and handoff documentation
We freeze Hesk writes during cutover, run the final delta migration, then re-enable Zendesk triggers and validate a sample of 50-100 tickets for field accuracy and attachment integrity. We deliver a written migration summary covering record counts by object, list of custom fields created in Zendesk, list of Macros created, any unmigrated records with reason, and external link patterns that require manual updating (documented with the original Hesk ticket IDs). We do not rebuild Hesk workflows or Mods-for-HESK custom scripts as Zendesk Triggers or Automations; that work is documented as a rebuild checklist for the customer's Zendesk admin. We offer a one-week hypercare window for reconciliation issues raised during the first week of live Zendesk operation.
Platform deep dives
Hesk
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 2 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Hesk and Zendesk.
Object compatibility
2 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Hesk: Not documented.
Data volume sensitivity
Hesk doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Hesk to Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your Hesk to Zendesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Hesk
Other ways to arrive at Zendesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.