How to migrate help desk software
The switching cost nobody prices in: tickets move through the API, but the macros, triggers, SLA rules, tag taxonomy and every single integration do not — and the first thing that breaks after cutover is a webhook that stops creating tickets without throwing an error. What survives, what re-authenticates from zero, and the sequence that keeps SLAs intact through the move.
The tickets export; the workflow doesn’t
Every help desk migration write-up fixates on moving tickets. That is the easy half — and even that only works cleanly through the API, never a CSV. What does not move is everything that made the help desk fast: the macros and canned replies, the triggers and automations, the round-robin and skill-based routing, the SLA policies and business-hours schedules, the CSAT surveys, the tag taxonomy and custom fields, the knowledge base, and every integration — CRM, Slack, e-commerce, telephony, and each webhook — all of which point at the old system and re-authenticate from scratch.
The deeper risk is silent breakage. A help desk is a web of triggers firing on events, and after a migration the ones that fail do so quietly: a Shopify order-created webhook that stops opening tickets, a routing rule keyed to a tag that no longer exists, an SLA clock that never starts because business hours reset to a default timezone. Nothing errors; a queue just goes empty or a breach count climbs. Treat this as a workflow re-implementation with a data copy attached, sequence it deliberately, and anchor it to what you chose in how to choose help desk software.
The five phases of a help desk migration
List your macros and canned replies, triggers and automations, routing rules, SLA policies and business-hours schedules, CSAT surveys, tag taxonomy and custom fields, and the knowledge-base articles. Then list every connected system: CRM sync, Slack, e-commerce (Shopify/order lookups), telephony/IVR, and every webhook and Zapier or native connector. Naming the non-exportable automation and the integrations now is the only thing that prevents a silent break after cutover — you cannot rebuild what you never wrote down.
Ticket history moves only through the API — a paid migration service or a script against both vendors' REST endpoints — never a clean CSV, which strips threading, attachments and internal notes. Decide deliberately how many months you need live in the new tool versus kept read-only in the old one; full-history transfers are slow, lossy on timestamps and original-agent fields, and rarely worth it past a year. Close or resolve stale open tickets before the move so you migrate a clean queue, not a backlog.
Recreate the tag taxonomy and custom fields first — routing and automations depend on them, so they must exist before anything imports. Then rebuild macros, triggers, automations, round-robin/skill routing, SLA policies and business-hours schedules in the new platform's model, which is never a one-to-one map of the old one. Re-index and re-point the knowledge base, and if article URLs change, map 301 redirects so you do not tank the support content's search rankings. Get the workflow right before a single live ticket lands on it.
Reinstall and re-authorise every integration — CRM sync, Slack, e-commerce, telephony, each webhook and Zapier bridge — then fire a real test event through each one and confirm a ticket is created, routed and tagged as expected. This is where silent breakage lives. Run a genuine pilot: forward one channel or queue to the new help desk for a week or two while the rest stays on the old, and watch the macros, routing and SLA clocks fire on live tickets before the whole operation depends on them.
Set the cutover date and hold it. On the date, repoint email forwarding and any support alias at the new help desk, switch the old desk to read-only so history stays reachable, and run short retraining on the new macros and routing the same day — agent muscle memory is keyed to keyboard shortcuts and macro names that just changed. Watch first-response and resolution SLAs, breach counts and CSAT for the first two weeks. Two live desks receiving the same mail is how replies get missed; a clean, dated cutover with one mail path is what protects the SLA.
The export gotchas, named
Partly, and only through the API — never through a clean CSV. Ticket subject, requester and status export as fields, but the threaded conversation, inline images, attachments and internal notes come across only when you run an API-to-API migration (a paid service like Help Desk Migration, or a custom script against both vendors' REST APIs). Even then, timestamps, the original agent and CC lists are the fields that most often arrive wrong. Decide up front how many months of history you actually need live, and keep the old help desk read-only for the rest rather than forcing a lossy import.
No. This is the part teams underestimate. Macros, triggers, automations, round-robin and skill-based routing, SLA policies, business-hours schedules and CSAT surveys have no export format and are rebuilt by hand in the new platform's logic — and every vendor models them differently, so it is a re-implementation, not a copy. Your tag taxonomy and custom ticket fields also have to be recreated before import or the routing rules that depend on them fire on nothing. Budget most of the project for rebuilding this workflow layer, not for moving rows.
None of them come across; every connector re-authenticates from zero in the new help desk. Your CRM sync, Slack notifications, Shopify or e-commerce order lookups, telephony/IVR, and any webhook or Zapier bridge all point at the old system and must be reinstalled and re-authorised. Webhooks are the silent-break risk: a lead form or order-created event that quietly stops creating tickets shows no error, just a gap. Inventory every integration and every webhook before cutover, then fire a test event through each one on a pilot queue before you point real traffic at it.
For a small team on a shared inbox with a couple of integrations and a light macro set, one to two weeks. For a real support operation — deep ticket history, dozens of macros and triggers, multi-channel email, chat and voice, a knowledge base, CRM and e-commerce integrations and SLA reporting — four to eight weeks is realistic. The API ticket transfer is rarely the bottleneck; rebuilding the automations, re-authenticating integrations, re-indexing the knowledge base and retraining agents are. Treat it as a workflow re-implementation with a data copy attached.
Briefly, with email forwarding pointed at one system and a hard cutover date — never open-ended. Route a single channel or one queue to the new help desk, work it fully for a week or two, and watch the macros, routing and integrations fire on real tickets. But two live help desks receiving the same mail is how replies get missed and SLAs breach: customers get answered twice or not at all. Set the cutover date, switch the mail routing and the old desk to read-only on it, and retrain agents on the new macros the same day.
One email when the rankings move. The shortlist, the tradeoffs, the price changes. No filler.