HappyFox is ticket-first; LiveChat is chat-first with HelpDesk for ticketing. No native migration path. Extract via HappyFox API v1.1, transform, load via HelpDesk API. CSV exports miss replies and notes.
Migrating from HappyFox to LiveChat involves no native migration path and requires a full API-based extract-transform-load effort. HappyFox is a ticket-centric help desk whose data model centers on threaded tickets, categories, contacts, and custom fields, while LiveChat is a conversation-first platform whose legacy ticketing system was retired on January 6, 2025 and replaced by HelpDesk, a separate companion product. HappyFox's native CSV export captures only the initial ticket message, omitting staff replies, client replies, and private notes, making API extraction via the HappyFox REST API v1.1 mandatory for any migration requiring full conversation fidelity. Custom work is required to transform ticket threads into HelpDesk-compatible payloads, handle rate limits of 500 GET and 300 POST requests per minute, remap categories to HelpDesk teams, and manually rebuild Smart Rules, SLAs, and canned actions in the target environment.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR: HappyFox → LiveChat + HelpDesk Migration
HappyFox is a ticket-centric help desk. LiveChat is a conversation-first live chat platform — its legacy ticketing system was sunset on January 6, 2025 and replaced by HelpDesk, a separate companion product by the same parent company (Text). No native migration path exists between the platforms. HappyFox's native CSV export only includes the initial ticket message — staff replies, client replies, and private notes are excluded (support.happyfox.com). You must extract data through the HappyFox REST API (v1.1), transform ticket threads into HelpDesk-compatible payloads, and load them via the HelpDesk API (v1). HappyFox enforces rate limits of 500 GET and 300 POST requests per minute, with a 10-minute lockout on 429 errors. A mid-size migration (10,000–30,000 tickets) takes 2–4 weeks including validation. Smart Rules, SLAs, and canned actions must be rebuilt manually. Quick Links: - Help Desk Data Migration Checklist - Post-Migration QA Checklist - HappyFox to Zendesk Migration Guide Last updated: July 2026. API behaviors verified against HappyFox API v1.1, HelpDesk API v1, and LiveChat Agent Chat API v3.5 documentation as of this date.
Knowledge base gap
LiveChat does not include a native knowledge base. If you use HappyFox's KB, you need a separate solution (KnowledgeBase.ai from Text, or a third-party tool like Confluence or Notion). KB articles cannot be migrated into LiveChat directly.
Timestamp backdating — tested result
In our testing against the HelpDesk API v1 (as of mid-2026), the created_at field on POST /v1/tickets is not writable — the server ignores any client-supplied value and returns the server-generated timestamp. The LiveChat Agent Chat API v3.5 behaves the same way for event created_at. This means all migrated records will display the import date as their creation date unless you implement a workaround. Verify this on your own instance, as API behavior may change. See the Timestamp Preservation section for concrete fallback strategies.
Practical tip
Run the full pipeline against a test HelpDesk instance first. Create a free trial HelpDesk instance, run your migration, and validate before touching production. This catches schema errors, mapping bugs, and rate-limit issues before they matter.
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 LiveChat can hold your support model
Walk your current workflow through LiveChat: 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 → LiveChat 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.
-
Record count comparison
Total tickets, contacts, and tags in source vs. target
HappyFox → LiveChat specifics
- Small team, <1,000 tickets, no dev resources
- Third-party migration service, accepting minor data loss on edge cases.
- Transition period, need both platforms running
- Middleware for new data + API migration for history.
- One-time migration, conversation history required
- API-based custom or managed migration service.
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 -
Request counting
track calls per window and pause proactively before hitting limits
HappyFox → LiveChat specifics
- Exponential backoff with jitter
- on 429 responses — HappyFox's 10-minute lockout means you cannot just retry immediately
- Queue-based architecture
- decouple extraction from loading so a rate-limit pause on one side does not block the other
- Conservative throttling
- stay at 70–80% of published limits; occasional bursts from other integrations can push you over, especially since HelpDesk rate limits are per-license across all tokens
- Categories
- → needed to map tickets to HelpDesk teams
- Attachment audit
- Download 20 random attachments from HelpDesk and verify they match source files (file size, filename)
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 → LiveChat 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 → LiveChat 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 LiveChat 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 → LiveChat specifics
- Custom field definitions
- → needed to create corresponding fields in HelpDesk
- Custom field accuracy
- Spot-check 20 tickets for correct field values
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 LiveChat sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a LiveChat 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 LiveChat'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 LiveChat, 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 LiveChat'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 → LiveChat specifics
- Thread depth check
- For sampled tickets, count replies in HappyFox vs. messages in HelpDesk
- Field-level spot check
- Verify 5% of tickets for correct category→team mapping, custom field values, priority, and status
- Agent assignment check
- Verify assigned agent survived the mapping
- Timestamp check
- Verify original dates are preserved in custom properties or message prefixes
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 LiveChat 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 LiveChat, 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
Total tickets in HappyFox vs. total in HelpDesk
-
Contact linkage
Confirm tickets are linked to the correct requester
HappyFox → LiveChat specifics
- Thread completeness
- Sample 50 tickets across categories; verify reply count matches
- Attachment presence
- Verify attachments are accessible and downloadable
- If the HappyFox ticket ID exists in the crosswalk
- → the ticket was already migrated. Fetch the HelpDesk ticket ID and append any new messages/updates that occurred after the initial migration timestamp.
- If the HappyFox ticket ID does not exist
- → it is a new ticket created during the migration window. Run the full transform-and-load pipeline for it.
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.
Concept / HelpDesk Equivalent
| HappyFox field | LiveChat field | Notes |
|---|---|---|
| Ticket | HelpDesk Ticket | Direct mapping, but thread structure differs |
| Category | HelpDesk Team / LiveChat Group | One-to-one mapping not guaranteed; requires structural decisions |
| Contact | HelpDesk Requester / LiveChat Customer | Fields differ; HappyFox contacts carry more metadata |
| Contact Group | No direct equivalent | Recommended: use tags on tickets (see Contact Groups section) |
| Staff Member | Agent | Role mapping needed |
| Custom Fields (Ticket) | HelpDesk Custom Fields | HelpDesk supports custom fields but with fewer types |
| Custom Fields (Contact) | Limited support | LiveChat customer properties are key-value only |
| Knowledge Base | No native KB | LiveChat has no knowledge base; must use KnowledgeBase.ai or another tool |
| Smart Rules | HelpDesk Automations | Must be rebuilt manually |
| SLAs | HelpDesk SLA Policies | Must be rebuilt manually |
| Canned Actions | HelpDesk Canned Responses | Must be recreated |
| Tags | HelpDesk Tags / LiveChat Tags | Direct mapping possible |
| Attachments | HelpDesk Attachments | Must be re-uploaded via API |
| Satisfaction Surveys | LiveChat Post-chat Surveys | Different mechanism; no migration path for historical data. Export aggregate CSAT data from HappyFox Reports before cutover for archival. |
| Webhooks | HelpDesk Webhooks / LiveChat Webhooks | Must be reconfigured — see Webhook Reconfiguration section |
HappyFox HelpDesk
| HappyFox field | LiveChat field | Notes |
|---|---|---|
| id | external_id (custom) | Store as reference; HelpDesk generates its own IDs |
| subject | subject | Direct mapping |
| text (initial message) | First message body | Preserve HTML formatting |
| status | status | Map: New→Open, On Hold→Pending, Resolved→Solved, Closed→Closed |
| priority | priority | Map: 1(Low)→Low, 2(Medium)→Medium, 3(High)→High, 4(Urgent)→Urgent |
| category | team_id | Map via lookup table |
| assigned_to | assignee | Map via agent lookup |
| user (contact) | requester | Match by email address |
| created_at | Not writable (see note) | Server-generated on import; store original in custom property |
| last_updated_at | updated_at | Same constraint as created_at; test on your instance |
| tags | tags | Direct mapping |
| update.text | Message body | Each update becomes a message in the thread |
| update.is_private | Internal note | Map true to internal note so it is not exposed to customer |
| Custom dropdown | Custom field | Validate picklist values exist |
| Custom text | Custom field | Direct mapping |
| Custom date | Custom field | Format as ISO 8601 |
| attachments | Attachments | Download from HappyFox, re-upload to HelpDesk; files >10 MB must be externalized |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets | medium | Tickets map directly to HelpDesk tickets at the record level, but the thread structure differs and requires transformation; risk is manageable with API extraction but non-trivial. |
| Conversation Threads (Replies & Notes) | high | Staff replies, client replies, and private notes are entirely excluded from HappyFox's CSV export and must be individually extracted and restructured via API, with high risk of data loss if pagination or rate limits are mishandled. |
| Attachments | high | Attachments must be downloaded from HappyFox and re-uploaded to HelpDesk via API with a 10 MB per-file limit, and any attachment linked inline to a message body requires additional cleanup. |
| Contacts | medium | HappyFox contacts carry more metadata than HelpDesk requesters or LiveChat customer properties support, meaning some contact fields will be truncated or lost during mapping. |
| Contact Groups | high | Contact groups have no direct equivalent in LiveChat or HelpDesk and must be approximated using ticket tags, resulting in a structural loss of the original grouping model. |
| Custom Fields (Tickets) | medium | HelpDesk supports custom fields but with fewer field types than HappyFox, so some custom field types may require type coercion or manual remapping during transformation. |
| Custom Fields (Contacts) | high | LiveChat customer properties are key-value only with limited structure, meaning rich HappyFox contact custom fields will lose their type fidelity and relational context. |
| Categories | medium | HappyFox categories do not map one-to-one to HelpDesk teams or LiveChat groups, requiring deliberate structural decisions before migration that cannot be automated. |
| Knowledge Base Articles | high | LiveChat has no native knowledge base, so all HappyFox KB content has no migration target within the platform and must be redirected to a third-party tool entirely outside the migration scope. |
| Smart Rules, SLAs, and Canned Actions | medium | These automation and workflow configurations have no automated migration path and must be manually recreated as HelpDesk Automations, SLA Policies, and Canned Responses in the target environment. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
No Native Migration Path
No built-in export-import pipeline exists between HappyFox and LiveChat or HelpDesk, requiring all data movement to be engineered through the respective REST APIs.
Incomplete CSV Export Coverage
HappyFox's native CSV export omits staff replies, client replies, and private notes, capturing only the initial ticket message and making API extraction mandatory for full conversation history.
Ticket Thread to HelpDesk Payload Transformation
HappyFox's threaded ticket model must be flattened and restructured into HelpDesk API v1 payloads, requiring custom transformation logic to preserve reply order, authorship, and note types.
HappyFox API Rate Limit Enforcement
HappyFox enforces hard rate limits of 500 GET and 300 POST requests per minute, with a 10-minute lockout on 429 errors, requiring robust retry logic and request throttling in any migration script.
Timestamp Backdating Limitation
The HelpDesk API v1 does not accept a writable created_at field on ticket creation, meaning the server overwrites original timestamps with the import time and requiring workaround strategies to preserve historical date context.
No Knowledge Base Migration Target
LiveChat does not include a native knowledge base product, so HappyFox KB articles have no direct migration destination and require a separate tool such as KnowledgeBase.ai, Confluence, or Notion.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate HappyFox tickets to LiveChat using CSV export?
Not effectively. HappyFox's CSV export only includes the initial ticket message — staff replies, client replies, and private notes are excluded. You need the HappyFox REST API (v1.1) to extract complete conversation history. LiveChat's ticketing system has been replaced by HelpDesk, which also lacks a native CSV import tool.
Does LiveChat still have a built-in ticketing system?
No. LiveChat's legacy ticketing system was sunset on January 6, 2025. Ticketing now runs through HelpDesk (helpdesk.com), a separate product by the same parent company, Text. HelpDesk integrates directly into the LiveChat agent app and shares the same authentication system.
What are the API rate limits for HappyFox and HelpDesk during migration?
HappyFox enforces 500 GET and 300 POST requests per minute, with a 10-minute lockout on 429 errors. HelpDesk enforces 1,000 requests per 10-minute window per license, shared across all tokens and integrations. Both require exponential backoff with jitter in your migration scripts.
How long does a HappyFox to LiveChat migration take?
A mid-size migration (10,000–30,000 tickets) typically takes 2–4 weeks including planning, extraction, transformation, loading, and validation. The largest time sinks are API extraction (due to rate limits and pagination) and post-migration validation. Smart Rules, SLAs, and canned actions must be rebuilt manually.
Can LiveChat preserve the original HappyFox reply timestamps?
Not reliably. The LiveChat Agent Chat API does not document writable event timestamps — it returns server-generated created_at values. If loading into HelpDesk, test whether its API supports backdating created_at with a single ticket first. As a fallback, store original timestamps in custom properties or message prefixes.