Gladly to HappyFox migration requires translating person-centric data into ticket-centric records via API. Watch for Gladly's 100-conversation and 1,000-item caps, HappyFox's 10-minute 429 lockout, and undocumented per-reply timestamp backdating.
Migrating from Gladly to HappyFox requires a full data-model translation, not a simple export-import: Gladly organizes support history around a person-centric model of lifelong Customer Conversations, while HappyFox uses a discrete ticket-based model where every request is an independent Ticket with its own category, status, and update thread. There is no native migration path between the two platforms; data must be extracted via Gladly's REST API or bulk Export API, transformed into HappyFox-compatible ticket payloads, and loaded through HappyFox's REST API v1.1. The primary structural challenge is that a single Gladly Customer may have dozens of multi-channel Conversations spanning years, each of which must be decomposed into individual HappyFox Tickets with remapped assignees, categories, and update threads. Custom engineering work is required to handle Gladly's silent truncation limits, cursor-based pagination, conversation item initiator mapping, and HappyFox's rate-limit lockout behavior.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR: Gladly to HappyFox Migration
Migrating from Gladly to HappyFox is a data-model translation — person-centric to ticket-centric — not a simple export-import. There is no native migration path. You must extract data through Gladly's REST API (or its bulk Export API for complete history), transform Conversations into ticket payloads, and load them into HappyFox via its REST API (v1.1). The hardest problems: Gladly's API caps at 100 conversations per customer and 1,000 items per conversation, both unpaginated and silently truncated. On the HappyFox side, you get 300 POST requests per minute and 500 GET requests per minute, with a 10-minute lockout on 429 errors. HappyFox supports created_at (ISO 8601 UTC format, e.g., 2023-11-15T14:30:00Z) on ticket creation, but its documented reply and note endpoints do not expose a field for backdating individual updates. For a mid-size dataset of 5,000–25,000 conversations, expect 8–15 business days end to end with one engineer working full-time. Last updated: August 2026. API behaviors verified against Gladly REST API and HappyFox API v1.1 documentation as of this date.
Topics ≠ Categories
Gladly Topics are flexible labels that can be stacked on any Conversation. HappyFox Categories are structural containers — every ticket lives in exactly one Category. If you have been using multiple Topics per Conversation in Gladly, pick a primary Topic → Category mapping and push secondary Topics to HappyFox Tags. Gladly topics can also carry parent-child structure via parentId; HappyFox tags are flat strings. If topic hierarchy matters for reporting or routing, use a custom field or prefixed tag scheme (e.g., topic:billing:refund) to preserve that structure.
Always check Gladly-Limited-Data
If this header returns true for any customer or conversation, your REST extraction is incomplete. Fall back to the Export API for those records, or explicitly document the data loss. Silence is the worst outcome — you will not know what you are missing until an agent reports it weeks later.
Concurrent API calls to the same ticket are not supported
If you are creating a ticket and then immediately adding updates to it, serialize those calls sequentially. Parallel calls to the same ticket number produce unpredictable results.
Run a dry-run first
Create a test Category in HappyFox and load 100 converted tickets before running the full migration. Include representative edge cases: customers with multiple conversations, conversations with many items, records with attachments, merged customers, threads with internal notes, and bot-initiated items. If the sample fails, the full migration will fail more slowly and more expensively.
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 Gladly
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 HappyFox can hold your support model
Walk your current workflow through HappyFox: 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 Gladly → HappyFox 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.
Gladly → HappyFox specifics
- Cost structure
- Gladly's pricing targets mid-market and enterprise. HappyFox starts at $29 per agent per month, with higher tiers adding multi-brand helpdesk capabilities, custom email, custom domain, custom roles and permissions, and custom ticket queues. (Verify current pricing on each vendor's site — these figures shift frequently.)
- Ticket-based workflow preference
- Not every team benefits from Gladly's conversation-first model. Teams that need discrete ticket IDs, strict category-based routing, SLA timers per ticket, and traditional queue management often find HappyFox a better operational fit.
- Asset management and ITSM needs
- HappyFox includes native asset management and task management features on higher tiers that Gladly does not offer natively.
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 Gladly 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 Gladly 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 Gladly 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
Gladly → HappyFox specifics
- Delta Extraction
- Query Gladly for conversations created or modified since the cutoff using timestamp filters on the search API. Gladly webhooks can serve as delta triggers — they send small ID-based payloads, not full conversation data. Your webhook endpoint must respond within 15 seconds; failed deliveries retry on a fixed schedule and can eventually deactivate the webhook if consistently slow. Use webhooks as triggers to queue IDs for extraction, not as the sole data carrier.
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 Gladly → HappyFox 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 Gladly → HappyFox 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 HappyFox 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.
Gladly → HappyFox specifics
- Custom field values
- HappyFox custom fields use numeric IDs for dropdown options. A single mismap corrupts the field silently across every ticket in that category.
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 HappyFox sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a HappyFox 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 HappyFox'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 HappyFox, 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 Gladly 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 HappyFox'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 Gladly 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 Gladly read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
Gladly → HappyFox specifics
- Initial Load
- Migrate all historical data up to a specific cutoff date (e.g., everything older than 7 days). Record the cutoff timestamp.
- Upsert Logic
- Query HappyFox by gladly_conversation_id custom field. If a match exists, append new items as updates. If no match, create a new ticket. Without the deduplication key described in the deduplication section above, this step is unreliable.
- Final Cutover
- On switch day, pause Gladly, run a final delta sync (which should take minutes if the deduplication logic is correct), then route all new traffic to HappyFox.
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 Gladly and HappyFox 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 HappyFox, 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 Gladly 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 counts
Compare total Gladly Conversations extracted vs. HappyFox Tickets created. Every mismatch needs investigation — check the error array from bulk creation responses first.
-
Contact deduplication
Gladly allows multiple emails per Customer profile. HappyFox enforces unique emails on contacts. The primary email decision must be made before loading — changing it after load requires manual correction.
Gladly → HappyFox specifics
- Thread integrity
- Spot-check 50–100 tickets. Verify that message order, sender attribution (staff vs. contact), and initiator types match the Gladly source.
- Deduplication key integrity
- Verify that every migrated ticket has a populated gladly_conversation_id custom field. Missing values break delta sync logic.
- Attachments
- Verify file sizes and counts match. Attachments are the most common source of post-migration support tickets.
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 Equivalent
| Gladly field | HappyFox field | Notes |
|---|---|---|
| Customer | Contact (User) | Map email, phone, name. Custom Attributes → Contact Custom Fields. Gladly allows multiple emails; HappyFox requires a primary email. |
| Conversation | Ticket | Each Conversation becomes one Ticket. |
| Conversation Item | Ticket Update | Messages, notes, replies become staff/contact updates. |
| Topic | Category or Tag | Gladly Topics are labels; HappyFox Categories are structural. Decide which mapping fits your workflow. |
| Agent | Staff | Map agent IDs to HappyFox staff IDs. Must be created before ticket import to preserve assignment history. |
| Team | (No direct equivalent) | HappyFox uses Categories for routing, not agent teams. |
| Inbox | Category | Gladly Inboxes may map to HappyFox Categories depending on your structure. |
| Task | Ticket (separate) | Gladly Tasks become separate HappyFox Tickets. |
| Answer | Knowledge Base Article | Gladly Answers can be extracted via GET /api/v1/answers, but HappyFox's public KB API is read-only — articles must be recreated through the UI or a separate content pipeline. |
| Smart Match / Rules | Smart Rules | Cannot be migrated. Rebuild manually. |
| SLA Policies | SLA Policies | Cannot be migrated. Rebuild manually. Historical SLA performance data requires export to an external BI tool. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Conversations (Tickets) | high | The core entity requiring full structural transformation from person-centric threads to discrete tickets, with a hard 100-conversation-per-customer REST API cap that silently truncates records without pagination fallback. |
| Conversation Items (Ticket Updates) | high | Individual messages, replies, and notes are capped at 1,000 items per conversation via the REST API, and HappyFox reply and note endpoints do not support backdating, meaning both completeness and timestamp fidelity are at risk. |
| Customers (Contacts) | medium | Gladly allows multiple emails per Customer while HappyFox requires a single primary email, and cursor-based pagination edge cases can cause newly created customers to be missed during extraction without a final count reconciliation. |
| Custom Attributes / Custom Fields | medium | Gladly Customer custom attributes must be mapped to HappyFox Contact custom fields, which must be pre-created in HappyFox before import; any schema mismatch or missing field definition will cause data to be silently dropped. |
| Topics (Categories and Tags) | medium | Gladly's multi-value, hierarchical Topics cannot map directly to HappyFox's single-value flat Categories, requiring a custom mapping strategy that risks losing secondary topic context and parent-child hierarchy in reporting. |
| Agents (Staff) | low | Agent-to-staff mapping is straightforward by email or name, but all HappyFox Staff accounts must be created and verified before ticket import begins or historical assignment data will be lost. |
| Teams | medium | Gladly Teams have no direct equivalent in HappyFox, which uses Categories for routing, meaning team-based assignment history cannot be preserved and must be remapped to a Category or custom field structure. |
| Knowledge Base Articles (Answers) | high | Gladly Answers can be extracted via the REST API, but HappyFox's public knowledge base API is read-only, requiring all articles to be recreated through the UI or a separate content pipeline with no automated import path. |
| SLA Policies | high | SLA policies cannot be migrated between platforms and must be fully rebuilt manually in HappyFox, and historical SLA performance data requires export to an external BI tool as it is not transferable. |
| Smart Rules and Automation | medium | Gladly Smart Match rules and routing logic have no exportable format and must be manually analyzed and rebuilt as HappyFox Smart Rules, with no automated migration path and a risk of gaps in routing coverage during the transition period. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Person-to-Ticket Model Translation
Gladly's person-centric Conversation model must be decomposed into discrete HappyFox Tickets, requiring a one-to-many structural transformation where each Gladly Conversation becomes a separate Ticket with its own category, status, priority, and update thread.
Silent API Truncation Limits
Gladly's conversation list endpoint returns at most 100 conversations per customer and the items endpoint returns at most 1,000 items per conversation, both without pagination and with data loss signaled only via a response header that must be explicitly monitored on every API call.
No Native Migration Path
Neither Gladly nor HappyFox provides a built-in migration tool, requiring a custom ETL pipeline using Gladly's REST or Export API for extraction and HappyFox's REST API v1.1 for loading.
HappyFox Rate Limit Lockout
HappyFox enforces a 300 POST requests per minute and 500 GET requests per minute cap, with a 10-minute lockout triggered on 429 errors, requiring careful throttle management during large-volume ticket creation.
Backdating Replies and Notes
While HappyFox supports the ISO 8601 UTC `created_at` field on ticket creation, its reply and note endpoints do not expose a backdating field, meaning individual Conversation Item timestamps cannot be accurately preserved in the migrated update thread.
Topic-to-Category Structural Mismatch
Gladly Topics are stackable, hierarchical labels that can be applied in multiples to any Conversation, whereas HappyFox Categories are singular structural containers, requiring a deliberate primary-mapping strategy and a tag or custom field scheme to preserve secondary and parent-child topic relationships.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate from Gladly to HappyFox without coding?
No. There is no native migration path or built-in import tool between Gladly and HappyFox. You must use both platforms' REST APIs to extract, transform, and load data. HappyFox's CSV ticket import only creates the first message as the ticket body and excludes attachments, so it is not suitable for a faithful migration.
How long does a Gladly to HappyFox migration take?
For a mid-size dataset of 5,000–25,000 conversations, expect 8–15 business days including extraction, transformation, loading, and validation. Smaller datasets under 5,000 conversations can be completed in 5–8 business days. Enterprise datasets over 100,000 conversations may take 25+ business days.
Does HappyFox preserve original Gladly reply timestamps?
Only partially. HappyFox supports a created_at field on ticket creation, but its documented staff_update, staff_pvtnote, and user_reply endpoints do not expose an equivalent backdating field for individual replies or notes. Store original timestamps in the note body or a custom field if audit-grade chronology matters.
What data can't be migrated from Gladly to HappyFox?
Smart Match rules, SLA policies, CSAT survey configuration, Sidekick AI settings, canned responses, Knowledge Base articles (HappyFox's KB API is read-only), webhook integrations, and routing logic cannot be migrated programmatically. These must be manually rebuilt in HappyFox.
Does Gladly's API paginate conversation lists?
No. Gladly's conversation list API returns at most 100 conversations per customer and 1,000 items per conversation, with no pagination. The Gladly-Limited-Data response header indicates if data was truncated. For complete extraction, use Gladly's file-based Export API.