HappyFox to Freshdesk migration requires API extraction — CSV exports drop all replies. Plan 10 to 17 days for 10K–50K tickets. Biggest risk: losing conversation history.
There is no native migration path from HappyFox to Freshdesk; HappyFox's built-in CSV export drops all staff replies, client replies, and private notes, making it unsuitable for ticket migration. The two platforms differ fundamentally in how they organize data — HappyFox Categories serve as classification and routing containers, while Freshdesk Groups function only as agent assignment queues — requiring deliberate structural mapping decisions. Full conversation history must be extracted via the HappyFox REST API and replayed into Freshdesk's Ticket Import API with individual conversation entries created per update, and configuration objects such as Smart Rules, SLAs, Canned Actions, and satisfaction surveys must be manually rebuilt.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR: HappyFox to Freshdesk Migration
A HappyFox to Freshdesk migration is moderately complex and typically takes 10 to 17 business days for a mid-size dataset of 10,000 to 50,000 tickets. The single biggest risk is losing ticket conversation history because HappyFox's native CSV export only includes the initial message and subject — not staff replies, client replies, or private notes. You must use the HappyFox REST API to extract full thread data and Freshdesk's Ticket Import API (/api/v2/imports/tickets, available on Estate/Pro plans and above) to recreate tickets with original timestamps. HappyFox Categories do not map 1:1 to Freshdesk Groups, requiring structural mapping decisions. Smart Rules, SLAs, Canned Actions, and satisfaction surveys cannot be migrated programmatically. Teams with fewer than 5,000 tickets and simple custom fields can self-serve with API scripting (60 to 120 engineer-hours). For larger datasets or zero-downtime requirements, a managed migration service is the safer path.
Do not treat Contact Groups as Companies by default
If a HappyFox Contact Group is a domain-based cohort or an entitlement bucket, mapping it straight to a Freshdesk Company will distort reporting and permissions. Keep a decision log for every group with the rationale for its target mapping.
Do not use HappyFox's CSV export for ticket migration
It drops all replies and private notes. Use the HappyFox API (/api/1.1/json/tickets/) to extract full conversation history.
Attachment mismatch is a real data-loss path
HappyFox allows up to 25 MB per update while Freshdesk caps at 20 MB. Pre-scan for oversized files and decide whether to externalize, compress, or archive them outside Freshdesk before migration day.
Order of operations rule
Always create Agents → Companies → Contacts → Custom Fields → Groups → Tickets → Conversations → KB. Breaking this order creates orphaned references that are painful to fix. Keep a crosswalk table (dictionary or database) for every source-to-target ID pair — it powers delta syncs, makes replays idempotent, and gives you a rollback map if cutover slips. For more on preventing broken relationships, see our help desk data migration playbook.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of HappyFox
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Freshdesk can hold your support model
Walk your current workflow through Freshdesk: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated HappyFox → Freshdesk timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
HappyFox → Freshdesk specifics
- Integration ecosystem
- Freshdesk's marketplace offers over 1,000 pre-built integrations across CRM, e-commerce, and BI tools. HappyFox has roughly 15 native integrations. Teams outgrow HappyFox when they need connections to Shopify, Salesforce, or Jira without building custom middleware.
- Pricing structure
- Freshdesk offers a free tier for up to 2 agents (previously 10; reduced in 2023) and a Growth plan starting at $15/agent/month billed annually, priced lower than HappyFox's entry-level $29/agent/month for growing teams that need basic automation.
- Omnichannel routing
- Freshdesk Omni unifies email, chat, phone, and social under one routing engine. HappyFox handles email ticketing well but requires a separate product (HappyFox Chat) for live chat, creating data silos between ticketing and real-time conversations.
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full HappyFox export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the HappyFox export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in HappyFox where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing
HappyFox → Freshdesk specifics
- List tickets
- GET /api/1.1/json/tickets/?size=50&page=1 — paginated results, maximum page size of 50.
- Ticket detail
- GET /api/1.1/json/ticket/<ticket_id>/ — returns the full ticket including the updates array with all replies, notes, and attachments.
- Contacts
- GET /api/1.1/json/users/?size=50&page=1 — same pagination ceiling.
- KB Sections
- GET /api/1.1/json/kb/sections/ — returns all knowledge base sections.
- KB Articles
- GET /api/1.1/json/kb/article/<article_id>/ — returns article content including HTML body and metadata.
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass HappyFox → Freshdesk field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the HappyFox → Freshdesk field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Freshdesk has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
HappyFox → Freshdesk specifics
- Custom field audit
- Export Freshdesk ticket data for 100 records using the API and compare custom field values against HappyFox source data. Verify dropdown values, dates, multi-select fields, and numeric fields. Pay special attention to fields where HappyFox uses IDs and Freshdesk uses string labels.
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Freshdesk sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Freshdesk sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Freshdesk's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Freshdesk, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while HappyFox stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Freshdesk's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze HappyFox and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep HappyFox read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
HappyFox → Freshdesk specifics
- Portal URL
- changes if you used HappyFox's customer portal. Communicate the new Freshdesk portal URL in advance. Consider setting up a redirect from the old URL.
- Ticket numbers
- will change. Freshdesk assigns new ticket IDs. If customers reference old ticket numbers, agents can search the cf_happyfox_id custom field.
- Email reply behavior
- may differ. Freshdesk uses its own email parsing. Test that email replies from customers thread correctly into existing tickets.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile HappyFox and Freshdesk record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Freshdesk, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep HappyFox read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
-
Record count reconciliation
Compare total tickets, contacts, companies, and KB articles between HappyFox source data (from your extraction logs) and Freshdesk. Tolerance: zero missing records on contacts and tickets. Account for any tickets deliberately excluded from scope (e.g., spam, test tickets). Also reconcile total conversation count: sum of all updates across all HappyFox tickets vs. total conversations in Freshdesk.
HappyFox → Freshdesk specifics
- Conversation integrity check
- Sample 50 tickets across different categories, date ranges, and conversation lengths (include tickets with 1 reply and tickets with 20+ replies). Verify that every reply and private note appears in the correct chronological order in Freshdesk. Use the dedicated conversations endpoint (GET /api/v2/tickets/{id}/conversations) for verification — the include=conversations parameter on the ticket endpoint only returns up to 10 entries.
- Attachment verification
- Open 20 random attachments in Freshdesk and confirm they render correctly. Check file count per ticket, filename, and file size against the extraction log. Specifically verify that no files >20 MB were silently dropped. Check that inline images in HTML bodies load correctly.
- Agent UAT
- Have 3 to 5 agents perform real lookups — search by customer name, search by old ticket ID (via the custom field), review a full conversation history, check a KB article, open an attachment — and report discrepancies. Trigger each rebuilt automation rule and SLA to confirm correct behavior with a test ticket.
- Timestamp verification
- For 20 sample tickets, compare created_at and updated_at in Freshdesk against the HappyFox source. They should match to the minute. If using the standard API instead of the Import API, verify that the custom date field contains the correct original timestamp.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object Object
| HappyFox field | Freshdesk field | Notes |
|---|---|---|
| Tickets | Tickets | Status values differ. HappyFox uses named statuses (New, On Hold, Open, Pending, Resolved, Closed). Freshdesk uses numeric codes (2=Open, 3=Pending, 4=Resolved, 5=Closed). Custom statuses require pre-creation in Freshdesk admin. Preserve the original HappyFox ticket ID in a Freshdesk custom field for reconciliation. |
| Staff/Contact replies, private notes | Conversations | HappyFox exposes these inside the updates array with type values: "staff_reply" → Freshdesk note with private: false; "client_reply" → Freshdesk reply; "private_note" → Freshdesk note with private: true. Each must be created individually via API after the parent ticket exists. |
| Contacts | Contacts | Direct mapping. Email is the primary unique identifier. HappyFox contact custom fields must be recreated in Freshdesk before import. |
| Contact Groups | Companies (partial) | Not a clean equivalent. HappyFox Contact Groups carry tagged_domains and access behavior that Freshdesk Companies do not mirror. Decision tree: if the group represents a business entity with a domain, map to a Company. If it represents an entitlement tier or access cohort, map to a tag or custom contact field. If it controls portal visibility, evaluate Freshdesk's company-based access controls. |
| Staff | Agents | Agents must be created in Freshdesk before importing tickets. Agent roles and category-level permissions differ. Freshdesk uses role_ids and group_ids. Build an agent crosswalk early, especially for inactive or deleted assignees — they still appear on historical tickets. Map them to a placeholder agent or preserve via a custom field. |
| Categories | Groups (partial) | No 1:1 equivalent. HappyFox Categories drive classification and permissions. Freshdesk Groups are assignment queues. Requires a mapping decision per category. See decision framework above. |
| Tags | Tags | Direct 1:1 mapping. Tags are plain strings on both platforms. |
| Ticket Custom Fields | Ticket Fields | Field types must match exactly. See field-type crosswalk below. HappyFox dropdown fields export as value names; Freshdesk expects exact string matches against pre-created choices. |
| Contact Custom Fields | Contact Fields | Must be pre-created in Freshdesk admin UI before API writes. |
| Knowledge Base (Sections, Articles) | Solutions (Categories, Folders, Articles) | HappyFox uses a two-level hierarchy (Sections > Articles). Freshdesk uses three levels (Category > Folder > Article). Article body HTML transfers directly, but embedded images referencing HappyFox URLs must be re-hosted. |
| Attachments | Attachments | HappyFox API returns attachment URLs with a 5-minute expiry. Files must be downloaded immediately and re-uploaded to Freshdesk as multipart/form-data. |
| Smart Rules | Automation Rules | Cannot be migrated. Must be rebuilt manually using Freshdesk Dispatch'r (ticket creation triggers), Supervisor (time-based triggers), and Observer (ticket update triggers). |
| SLA Policies | SLA Policies | Cannot be migrated. Must be recreated manually. |
| Canned Actions | Canned Responses | Cannot be migrated programmatically. Manual recreation required. |
| Satisfaction Surveys | Satisfaction Surveys | Configuration does not transfer. Must be set up fresh. |
Cus m Field Type Crosswalk
Field types must match exactly between platforms, dropdown choice values must be pre-created in Freshdesk admin before API writes, and regex-validated fields require manual pattern recreation.
| HappyFox field | Freshdesk field | Notes |
|---|---|---|
| Text | custom_text | Direct mapping. Max 255 characters in Freshdesk. |
| Textarea | custom_paragraph | Direct mapping. |
| Dropdown | custom_dropdown | All choice values must be pre-created in Freshdesk admin. API rejects unrecognized values. |
| Multi-select | custom_checkbox (multi-select dropdown) | Freshdesk multi-select expects an array of strings. |
| Checkbox | custom_checkbox | Boolean mapping. |
| Date | custom_date | Freshdesk expects ISO 8601 format (YYYY-MM-DD). |
| Number | custom_number | Direct mapping. Integer only in Freshdesk. |
| Decimal | custom_decimal | Direct mapping. |
| Regex-validated | custom_text with validation | Regex patterns must be manually recreated in Freshdesk field settings. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets | medium | Tickets transfer via API but status values must be mapped from HappyFox named statuses to Freshdesk numeric codes, custom statuses require pre-creation, and original ticket IDs should be preserved in a custom field for reconciliation. |
| Conversation History | high | Full thread data (replies and private notes) is completely lost in CSV export and must be individually reconstructed via the HappyFox API updates array and separate Freshdesk conversation endpoints with correct type mapping. |
| Contacts | low | Contacts map directly between platforms using email as the unique identifier, though any HappyFox contact custom fields must be pre-created in Freshdesk before import. |
| Contact Groups | high | HappyFox Contact Groups carry tagged domains and access behaviors with no clean Freshdesk equivalent, risking distorted reporting and permissions if blindly mapped to Companies. |
| Custom Fields | medium | Field types must match exactly between platforms, dropdown choice values must be pre-created in Freshdesk admin before API writes, and regex-validated fields require manual pattern recreation. |
| Attachments | high | HappyFox attachment URLs expire after 5 minutes, requiring immediate download and re-upload as multipart/form-data, which adds significant complexity and timing constraints to the migration pipeline. |
| Tags | low | Tags are plain strings on both platforms and map 1:1 with no transformation required. |
| Knowledge Base Articles | medium | HappyFox uses a two-level hierarchy (Sections > Articles) while Freshdesk uses three levels (Category > Folder > Article), and embedded images referencing HappyFox URLs must be re-hosted. |
| Agents | medium | Agents must be created in Freshdesk before ticket import, roles and category-level permissions differ structurally, and inactive or deleted assignees on historical tickets require placeholder mapping. |
| Automation Rules | high | HappyFox Smart Rules cannot be migrated programmatically and must be manually rebuilt across Freshdesk's three separate rule engines (Dispatch'r, Supervisor, and Observer). |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Conversation History Extraction Gap
HappyFox's CSV export only includes the initial ticket message and subject, requiring API-based extraction of the full updates array to preserve staff replies, client replies, and private notes.
Category-to-Group Structural Mismatch
HappyFox Categories drive classification, permissions, email assignments, and reporting, but Freshdesk Groups are only agent assignment queues, requiring per-category mapping decisions to Groups, custom dropdowns, or tags.
Attachment URL Expiration
HappyFox API returns attachment URLs with a 5-minute expiry, requiring immediate download and re-upload to Freshdesk as multipart/form-data within tight timing windows.
Contact Group Mapping Ambiguity
HappyFox Contact Groups carry tagged domains and access behavior that Freshdesk Companies do not mirror, requiring case-by-case decisions on whether to map each group to a Company, tag, or custom contact field.
Conversation Threading Reconstruction
Each HappyFox update (staff_reply, client_reply, private_note) must be individually created via separate Freshdesk API endpoints after the parent ticket exists, with correct privacy flags and original timestamps.
Non-Migratable Configuration Objects
Smart Rules, SLA policies, Canned Actions, and satisfaction surveys cannot be migrated programmatically and must be manually rebuilt in Freshdesk's Dispatch'r, Supervisor, and Observer rule engines.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a HappyFox to Freshdesk migration take?
A typical migration of 10,000 to 50,000 tickets takes 10 to 17 business days end to end, including discovery, script development, test runs, full migration, delta sync, and validation. Smaller datasets under 5,000 tickets can be completed in 5 to 7 days.
Can I migrate HappyFox to Freshdesk without losing data?
Yes, if you use the HappyFox API for extraction instead of the built-in CSV export. The CSV export drops all staff replies, client replies, and private notes. API-based extraction preserves the full conversation thread, custom fields, tags, and attachments, subject to Freshdesk's 20 MB attachment limit.
What data cannot be migrated from HappyFox to Freshdesk?
Smart Rules, SLA policies, Canned Actions, satisfaction survey configurations, and agent permissions cannot be migrated programmatically. These must be manually recreated in Freshdesk. HappyFox Asset Management data has no native Freshdesk equivalent.
How much does a HappyFox to Freshdesk migration cost?
DIY cost is primarily engineering time: 60 to 120 hours for a developer comfortable with REST APIs. Professional migration services typically range from $3,000 to $15,000 for 5K to 100K tickets, depending on custom fields, attachments, and delta sync requirements.
Should Freshdesk automations stay on during the import?
Usually no for customer-facing rules. Active automation rules can send notifications, assign tickets, or trigger SLA timers during ticket creation. Disable customer-facing automations before running the production import and re-enable them after validation.