Nobody migrates help desks for fun. You do it because the old platform got too expensive, the AI billing went feral, or the reporting can't answer basic questions anymore. The good news: thousands of teams do this every year without catastrophe. The bad news: the ones that fail usually fail the same three ways — they discover the export is incomplete mid-migration, they rebuild automations from memory, or they cut over on a Friday with no rollback plan. This playbook gives you the five-phase plan that avoids all three. It's research-based — drawn from vendor documentation, migration-tool guides, and published post-mortems — not a first-hand walkthrough of one migration.
- Audit before you move: inventory tickets, automations, integrations, and macros — the automations are what teams forget and what hurts most to rebuild.
- Test your export on day one, not migration week: proprietary formats, truncated attachments, and rate-limited APIs are the classic surprises.
- Run old and new desks in parallel for 2–4 weeks; cut over mid-week with a rollback plan, never on a Friday.
- Budget 4–12 weeks total depending on team size; the migration tool costs a fraction of the labor it saves past ~10k tickets.
- The cheapest migration insurance is checking export options before you sign with any vendor — including the one you're moving to.
Phase 0: the pre-migration audit
Every successful migration starts with an inventory, because you can't move what you haven't counted. Before you touch the new platform, document four things in the old one:
1. Data. How many tickets (open and closed), how many contacts/companies, how many knowledge-base articles, how many attachments and roughly how much storage. Open tickets need special handling — they're live work, not archive. Decide up front: migrate open tickets with their full history, or close-and-recreate them in the new system with a link back to the old record.
2. Automations and business rules. This is the inventory teams skip and regret. List every trigger, automation, SLA policy, routing rule, and macro. Screenshot the configuration of each one — not the name, the actual logic. A rule called "VIP escalation" is useless as documentation; "if tags contain vip AND status is new for >30 min, assign to senior group and notify #support-alerts" is a specification you can rebuild from.
3. Integrations. Everything connected to the desk: CRM sync, Slack notifications, telephony, the chatbot, reporting pipelines, the status page. Each one needs a reconnection plan on the new platform, and some won't have an equivalent — flag those early.
4. Custom fields and ticket forms. Custom fields are the silent migration killer. If the old desk has 40 custom fields and the new one has a different field-type model, someone has to map every field, decide what merges, and accept what gets dropped. Do this mapping in a spreadsheet before migration week.
Deliverable of Phase 0: a migration spec — what moves, what gets rebuilt, what gets dropped, and who's responsible for each. If you can't write the spec, you're not ready to migrate.
Export and import: what actually moves
Here's the uncomfortable truth vendors don't advertise: ticket exports are lossy. What you get depends on the platform, and the gaps are consistent enough to plan around.
What usually exports cleanly: ticket subjects, descriptions, statuses, priorities, requester identities, timestamps, tags, and agent replies. The core conversation thread survives on every major platform — Zendesk, Freshdesk, Intercom, Zoho Desk, and HubSpot all export this via API or built-in tools.
What gets tricky: attachments (often exported as separate downloads with size caps, sometimes truncated), inline images (frequently broken on import because the URLs point at the old platform's CDN), custom field values (survive only if you've mapped the fields first), and internal notes (some exports flatten them into the public thread — audit this before you import, or private agent chatter becomes customer-visible).
What doesn't move: automation rules, macros, views, dashboards, and reports. These are configuration, not data — they get rebuilt by hand from your Phase 0 screenshots. Nobody's export includes "the way we work."
API rate limits matter. Large exports run through the vendor's API, and APIs throttle. A 200k-ticket Zendesk or Freshdesk export can take days of paginated pulls — plan the export window early and don't discover the throttle on cutover weekend. Also note: some platforms charge for or restrict bulk export on lower tiers, and data-retention policies can bite if the old contract has lapsed. Keep the old instance paid and accessible until the migration is verified complete — the $500/mo overlap is the cheapest insurance in this playbook.
Practical rule: run a test export of 100 tickets in week one of the project. Import them into a sandbox on the new platform and inspect what survived. Every surprise you find in week one is cheap; every surprise you find in week eight is a crisis.
The 5-phase migration plan
Phase 1 — Spec and sandbox (weeks 1–2)
Complete the Phase 0 audit. Provision the new platform as a sandbox/trial. Run the 100-ticket test export and import. Map custom fields. Identify integrations with no equivalent and decide: rebuild, replace, or drop. Assign owners to every line of the spec.
Phase 2 — Rebuild configuration (weeks 2–5)
Rebuild automations, SLA policies, routing rules, macros, ticket forms, and views in the new platform — from the spec, not from memory. Reconnect integrations one by one and test each with synthetic tickets. Migrate the knowledge base early: articles are the easiest win and the content your agents need on day one. Set up reporting dashboards and verify the numbers match the old platform's reports on the same data — if CSAT or first-response time disagree, find out why before go-live, because finance will ask.
Phase 3 — Pilot with a slice of traffic (weeks 4–6)
Route a slice of real traffic to the new desk — one channel, one product line, or one agent group. Keep the old desk running everything else. The pilot's job is to surface what the sandbox missed: the macro that doesn't fire, the integration that drops fields, the report that miscalculates. Fix everything the pilot finds. This is also when you train agents — on real tickets, not slide decks.
Phase 4 — Full migration and parallel run (weeks 6–8)
Migrate the full ticket history (or the agreed archive window — many teams migrate 12–24 months and archive the rest). Migrate open tickets with full history. Then run both desks in parallel for 2–4 weeks: new tickets land in the new system, the old system stays read-accessible for history lookup. The parallel run is where you verify reporting parity and catch stragglers — the integration nobody remembered, the scheduled report still pointing at the old API.
Phase 5 — Cutover and decommission (week 8+)
Cut over mid-week (Tuesday–Wednesday), never Friday — you want the vendor's support team and your own engineers online when something breaks. Point DNS/email gateways at the new desk, confirm the first tickets flow end-to-end, and keep the old instance in read-only mode for 60–90 days before decommissioning. Some teams keep a static archive export indefinitely for compliance. Announce the change to customers only if it affects them (new portal URL, new reply-to behavior) — otherwise it's plumbing, not news.
Migration tools: build vs buy
You have three options for moving the data itself:
Native importers. Some platforms ship import wizards for specific competitors. They're free and fine for small, simple moves — but they cover a fraction of platform pairs and usually skip custom fields and attachments.
Dedicated migration services (the Help Desk Migration category of tools). These exist precisely because native importers are thin: they map fields, move attachments, preserve threads, and handle the API throttling for you. Pricing is typically per-ticket or per-record, scaling with volume. Rule of thumb: past ~10,000 tickets, the tool costs less than the engineering time to build and babysit a custom script. Get a fixed quote on your actual record counts, and confirm in writing what happens to attachments, inline images, and internal notes.
Custom scripts via API. The right choice when you have unusual requirements — heavy custom-field logic, data transformation, or compliance redaction during the move. The wrong choice when you're underestimating the edge cases: every team that builds its own discovers the attachment problem, the rate-limit problem, and the deleted-user problem in production.
Whichever you choose, the test migration in Phase 1 is non-negotiable. Never run a migration tool against production data first.
Timelines by team size
Honest ranges, assuming one dedicated owner plus agent time for testing:
| Team size | Ticket history | Realistic timeline |
|---|---|---|
| 1–5 agents | <10k tickets | 3–4 weeks |
| 5–15 agents | 10k–50k tickets | 6–8 weeks |
| 15–40 agents | 50k–200k tickets | 8–12 weeks |
| 40+ agents | 200k+ tickets | 12–20 weeks, phased by team |
The timeline killer is never the data transfer — it's the automation rebuild and the integration reconnections. A team with 60 automations and 12 integrations should budget at the top of its range regardless of ticket count.
The 6 most common failures
1. Discovering the export gap mid-migration. The test export exists to prevent this. If attachments or internal notes don't survive, you find out in week one.
2. Rebuilding automations from memory. The Phase 0 screenshots exist to prevent this. "We had a rule that did something with VIPs" is not a specification.
3. No parallel run. Teams that cut over cold discover the broken integration on Monday morning with a full queue. Two to four weeks of parallel running is not optional.
4. Migrating dirty data. The migration is the best data-cleanup opportunity you'll ever get. Deduplicate contacts, archive dead tickets, kill unused custom fields before the move — don't pay to migrate garbage.
5. Forgetting the knowledge base. Agents need articles on day one of the new desk. Migrate the KB in Phase 2, not Phase 4, and use the move to prune outdated articles.
6. Decommissioning the old instance too fast. Keep read-only access for 60–90 days. The ticket from 14 months ago that legal suddenly needs is always the one you deleted.
—
One more thing worth saying plainly: the best migration is the one you plan for before you need it. When you're evaluating any help desk — including the one you're migrating to — check its export story first: bulk export availability, attachment handling, API limits. That check takes an hour and it's the cheapest insurance in this entire playbook. Our guide to the hidden costs of help desk software covers the contract and data-portability questions to ask before you sign, and the KPI guide gives you the reporting-parity checklist for Phase 2.
FAQs
How much does a help desk migration cost?
The software overlap (running both platforms 2–3 months) plus either a migration tool (typically per-ticket pricing, cheapest past ~10k tickets) or engineering time for custom scripts. The hidden cost is staff time: expect your migration owner at half-time for the duration. Get fixed quotes on your actual record counts.
Can we migrate without losing ticket history?
The core thread — subjects, replies, timestamps, requesters — migrates cleanly on all major platforms. Expect friction on attachments, inline images, and custom fields; plan for those specifically with a test migration in week one. Automations and reports never migrate — they're rebuilt.
Should we migrate open tickets or close them first?
Migrate open tickets with full history whenever the queue is large enough that closing-and-recreating would confuse customers. For small queues, closing with a "we've moved systems" note and recreating in the new desk is simpler and cleaner.
How long should the old help desk stay online?
Paid and accessible through the whole migration, read-only for 60–90 days after cutover, then decommissioned — keeping a static archive export for compliance if your industry requires it. Never let the old contract lapse mid-migration.
What's the biggest mistake teams make when switching?
Skipping the test migration. Every catastrophic migration story — truncated attachments, flattened internal notes, broken images — was discoverable in week one with 100 test tickets. The teams that test don't have catastrophe stories.