Helpdesk migration
Field-level mapping, validation, and rollback between Hesk and Freshdesk. We move data and schema; workflows are rebuilt natively in Freshdesk.
Hesk
Source
Freshdesk
Destination
Compatibility
7 of 10
objects map 1:1 between Hesk and Freshdesk.
Complexity
BStandard
Timeline
1-2 weeks
Overview
Hesk runs on a MySQL database with no public REST API, which is the primary constraint for any migration off the platform. All record extraction happens through direct database queries or XML/Excel UI exports, and all writes to Freshdesk run through the Freshdesk REST API v2. We audit the Hesk MySQL schema first, enumerate custom field definitions, resolve file-system attachment paths, and version-check the Hesk installation to avoid schema mismatches during extraction. Freshdesk's API requires agents to exist before ticket import, so we migrate Agents first, then Contacts, then Tickets with full threading, then Knowledge Base. Custom fields, canned responses, and ticket history are mapped with notes. Freshdesk automations (triggers, SLA policies, macros, scenario automations) do not migrate and are documented for the customer's admin to rebuild post-migration.
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 Freshdesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Hesk
Ticket
Freshdesk
Ticket
1:1Hesk tickets (subject, message, status, priority, owner, category, custom fields) map directly to Freshdesk tickets. The ticket body becomes the ticket description, and Hesk ticket replies become Freshdesk conversation notes or replies. We preserve threading order by importing in chronological sequence and setting the Freshdesk incoming timestamp to match the Hesk created_date. Hesk status values (new, open, pending, resolved, closed) map to Freshdesk status values with a custom mapping table agreed upon during scoping. Priority maps to Freshdesk priority with a defined low/medium/high/critical translation.
Hesk
User (End User / Customer)
Freshdesk
Contact
1:1Hesk end-user accounts (name, email, IP address, creation date) map to Freshdesk contacts. Hesk allows emailless users for phone-only contacts; Freshdesk requires an email for the primary identifier, so emailless Hesk users are flagged during discovery for the customer to either provide a placeholder email or exclude from migration. GDPR anonymisation flags are preserved as a note field on the contact record.
Hesk
Staff Account
Freshdesk
Agent
1:1Hesk staff accounts (name, email, role: administrator/manager/agent) map to Freshdesk agents. Role translation maps Hesk Administrator to Freshdesk Admin, Hesk Manager to Freshdesk Agent with group management permissions, and Hesk Agent to Freshdesk Agent. We create agents via the Freshdesk agents API before any ticket import, because Freshdesk requires an agent association for ticket assignment. Hesk password hashes (bcrypt) do not transfer; agents receive Freshdesk provisioning emails to set passwords.
Hesk
Category (Ticket Category)
Freshdesk
Group
lossyHesk ticket categories (name and description) map to Freshdesk groups. We create groups in Freshdesk via the Groups API before ticket import and store the Hesk category ID as a reference field in our migration manifest. If Hesk categories are hierarchical or overlap with department structures, groups are named to reflect the original category intent.
Hesk
Knowledge Base Article
Freshdesk
Solution Article
1:1Hesk KB articles (title, HTML content, category, attachments) map to Freshdesk solution articles within a Freshdesk Help Center folder. We export article content as HTML, import into Freshdesk via the Solutions API, and map Hesk KB categories to Freshdesk folders (created first during KB import). Article status maps to Published/Draft based on the Hesk article's published flag. Inline images require re-hosting; we flag any img tags with relative paths for path remapping before import.
Hesk
Canned Response
Freshdesk
Snippet
1:1Hesk canned responses (title and HTML body) map to Freshdesk snippets. Imported via the Freshdesk snippets API as a flat list. Note that Freshdesk snippets are workspace-scoped and not automatically linked to specific ticket fields; the customer's admin reassigns them to the appropriate contexts after migration. Hesk's per-category canned response associations are preserved as snippet group names in Freshdesk.
Hesk
Custom Field (Ticket)
Freshdesk
Custom Ticket Field
lossyHesk custom ticket fields (type, label, options) are enumerated during discovery and pre-created in Freshdesk via Admin > Ticket Fields before ticket migration. We map field types (dropdown, checkbox, date, text) to Freshdesk field types. Dropdown options are bulk-created before ticket records are imported so that option values are valid on insert. The undocumented Hesk custom field cap is checked during discovery; if the customer is near the limit, we flag which fields may not transfer cleanly.
Hesk
Attachment (file-system)
Freshdesk
Ticket Attachment
1:1Hesk attachments live on the file system with paths stored in MySQL (hesk_attachments table with file_path and db_id). We export the entire attachments directory, re-upload each file via the Freshdesk attachments API using the ticket ID as the parent reference, and replace the Hesk relative URL with the Freshdesk CDN URL in the ticket body. If the destination Freshdesk domain differs from the Hesk server, all embedded image URLs are rewritten. Attachment files exceeding 15MB cannot be migrated through the Freshdesk API; we flag these for manual handoff.
Hesk
Ticket History / Audit Trail
Freshdesk
Ticket Conversation
1:1Hesk ticket history (opened, replied, status change, assignment events) is stored in hesk_ticket_events. We merge these into Freshdesk ticket conversation entries as notes with a timestamp and actor attribution. Not all Hesk event types have a Freshdesk equivalent; we classify Hesk system events as internal notes and customer-initiated events as reply notes to preserve the thread context as faithfully as the destination model allows.
Hesk
Settings and Configuration
Freshdesk
Configuration Notes (document only)
lossyHesk settings (email routing, ticket field labels, status names, branding) are exported as a JSON configuration bundle. We do not apply settings directly to Freshdesk because Freshdesk configuration (status labels, required fields, ticket field ordering) requires manual admin action or separate API calls. The configuration bundle is delivered as a written inventory so the customer's Freshdesk admin can apply equivalent settings post-migration.
| Hesk | Freshdesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| User (End User / Customer) | Contact1:1 | Fully supported | |
| Staff Account | Agent1:1 | Fully supported | |
| Category (Ticket Category) | Grouplossy | Fully supported | |
| Knowledge Base Article | Solution Article1:1 | Fully supported | |
| Canned Response | Snippet1:1 | Fully supported | |
| Custom Field (Ticket) | Custom Ticket Fieldlossy | Fully supported | |
| Attachment (file-system) | Ticket Attachment1:1 | Fully supported | |
| Ticket History / Audit Trail | Ticket Conversation1:1 | Mapping required | |
| Settings and Configuration | Configuration Notes (document only)lossy | Mapping required |
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
Freshdesk gotchas
API access is blocked on the free plan
Per-minute rate limits are account-wide and endpoint-specific
Multi-channel source types do not map 1:1 to all destinations
Custom objects created in-product cannot be accessed by other apps
Contact import requires at least 10 existing tickets in the account
Pair-specific challenges
Migration approach
Discovery and access provisioning
We audit the Hesk MySQL database schema to enumerate all tables, custom field definitions, attachment paths, and Hesk version. We confirm the Freshdesk API is active on the target account (Growth tier or above; API is not available on the free Sprout plan), generate a Freshdesk API key, and verify the target Freshdesk domain. We also check whether the customer has existing Freshdesk data that would trigger duplicate detection. The discovery output is a written scope document confirming record counts per object, any custom field types, attachment file count and total size, and a migration timeline estimate.
Schema pre-creation in Freshdesk
Before any data import, we pre-create Freshdesk objects that are required for referential integrity: groups (from Hesk categories), agents (from Hesk staff), custom ticket fields (from Hesk custom field definitions), and Help Center folders (from Hesk KB categories). Each is created via the Freshdesk REST API and the resulting Freshdesk IDs are stored in our migration manifest alongside the corresponding Hesk IDs for lookup during record import. Freshdesk automations are disabled as a pre-flight gate at this stage.
Database extraction and data cleaning
We connect to the Hesk MySQL database directly and extract all records in dependency order: users, staff, categories, tickets, KB articles, canned responses, attachments metadata, and ticket history. During extraction we apply any data cleaning agreed upon during scoping (anonymisation, duplicate deduping, date range filters). We export the attachments directory from the Hesk file system as a ZIP archive. All extracted data is validated against expected record counts before transformation begins.
Sandbox migration and reconciliation
We run a full migration into the customer's Freshdesk sandbox (or a fresh Freshdesk trial account) using the extracted Hesk data. The customer reconciles record counts, spot-checks 25-50 random tickets for threading fidelity, verifies custom field values, confirms attachment visibility, and checks KB article rendering. We correct any mapping errors identified during sandbox reconciliation before the production migration begins. Sandbox migration typically takes one to two days for small-to-medium Hesk instances.
Production migration and attachment upload
We run production migration in strict dependency order: agents, contacts, groups, custom fields, tickets with conversation threading, KB articles with folder assignment, canned responses, and finally attachments. Attachment upload is the longest step for installations with many files; we chunk uploads in batches and handle API rate-limit responses with exponential backoff. Each object import emits a row-count reconciliation report before the next object begins. Ticket history is merged into conversation notes in chronological order with actor attribution preserved.
Cutover, validation, and automation rebuild handoff
We freeze Hesk writes during the cutover window, run a delta migration of any records created or updated during the migration, and enable Freshdesk as the system of record. Freshdesk automations are re-enabled by the customer's admin. We deliver the automation and canned response inventory document so the admin can reconnect snippets to Freshdesk macros and rebuild Hesk-style workflow equivalents using Freshdesk triggers and scenario automations. We support a 48-hour post-cutover window for reconciliation issues raised by the support team.
Platform deep dives
Hesk
Source
Strengths
Weaknesses
Freshdesk
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 Freshdesk.
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 Freshdesk migration scoping. Not seeing yours? Book a call.
Walk through your Hesk to Freshdesk 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 Freshdesk
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.