Help desk migration: 7 things that break when you switch

Records move in a migration; the macros, SLA rules and routing logic around them have to be rebuilt and tested.

A help desk switch typically takes two to six weeks from planning to stabilization, and the migration fee is the most predictable line in its budget. HappyFox's 2026 migration guide puts mid-size projects at $2,500 to $12,000 and enterprise moves at $12,000 to $60,000 or more, and it cites per-record tool pricing of roughly $100 for 1,000 records against roughly $514 for 10,000. Those numbers price data. They do not price behavior.

A help desk migration is the transfer of tickets, contacts, agents, knowledge base content and configuration from one support platform to another. The first four are records. The last one is logic: macros, triggers, SLA policies, routing rules and integrations, all written in the old platform's own terms. In 2024, one record-priced migration service said its pricing did not increase linearly with volume, and that notes, attachments, ticket custom fields and replies transferred free of charge. That is a fair deal for the records. It also means nothing in the quote pays for rebuilding the logic.

Volume misleads in a second way. Per-record pricing tracks how much data you have, not how tangled it is, so two instances with identical ticket counts can be very different jobs. Given the choice, I would take a precise scope over a low quote every time, because a cheap number that leaves out your SLA logic is not cheaper, only later.

The same guide calls SLAs, automations and workflows "consistently the most underestimated item on the list." The seven failure points below are where that underestimate turns into tickets routed to the wrong queue, SLA clocks running on closed history, and screenshots that never made it across.

What breaks when you migrate help desk software?

Records usually survive a help desk switch. The logic built around them does not: custom fields, macros, attachments, ticket history, integrations, SLAs and routing rules all need checking or rebuilding.

Before you accept a migration quote, sort your current setup into three piles:

1. Moves as records: tickets, contacts, agents and knowledge base articles.
2. Moves only if mapped: custom fields, groups, attachments and closed history.
3. Never moves: macros, triggers, SLA policies, routing rules and integrations.

The quote covers the first pile. Your team pays for the third.

HappyFox's June 2026 migration guide states the split directly: tickets and contacts "will probably move cleanly," while automations, workflows and integrations "almost certainly won’t." Scale sharpens the problem. As one commenter in an r/n8n migration thread put it, "100 tickets vs 100,000 tickets has different problems." An IT platform vendor's own guide names ticket subjects, description bodies, statuses, priorities, contact profiles, clean-HTML knowledge base articles and attachments under common API size limits as the data that transfers reliably between most platforms.

Our reviews are written and edited by Zazachat's editorial team, led by Daniel Calloway, and the taxonomy below comes out of that editorial process: practitioner accounts and migration documentation, read against each other rather than taken on a vendor's word. A comparison of 5 sources shows the same pattern. Records travel. The practical step is to ask each vendor, in writing, which of the seven items below its tool touches at all.

The common assumption is that a clean ticket count means a clean migration. It does not. Here are the seven failure points, with one concrete example each:

• Custom fields: platforms name the same object differently. Freshdesk "companies" are "organizations" in Zendesk, so every field needs an explicit source-to-target map.
• Macros and automations: "if this, then that" rules built inside Zendesk or Freshworks rarely map directly to a new platform and typically get rebuilt.
• Attachments: the same practitioner thread describes downloading each file from the source and posting it again to every newly created ticket.
• Ticket history: one sysadmin's CSV export of past tickets arrived without the ticket notes, which made it "pretty much useless."
• Integrations: each third-party integration adds its own testing and reconfiguration time, so the count of connected tools drives the schedule.
• SLAs: SLA rules sit in the rebuild column with automations, because they run on the old platform's own logic.
• Routing rules: ticket mapping covers group, type, status and priority, so one mismatched group sends tickets into the wrong team's queue.

I would compare destination platforms on that third pile before anything else. A shortlist of help desk software with live chat becomes far more useful once you know how much routing, SLA and automation logic each product has to absorb on day one, and how much of it your admins will rebuild by hand. Whether a migration tool can catch any of this before go-live is a separate question, and the evidence on it is mixed.

Can a paid migration tool catch these failures before go-live?

Partly. A good migration tool moves records and reports what it skipped, but the costlier work of rebuilding configuration on the new platform stays with your team.

The case for tooling is stronger than skeptics allow. Help Desk Migration, the most visible automated service in this market, has made verification its pitch: every run produces a Data Integrity Report, a record-level audit listing matched entity IDs, the full field mapping (what moved, what was transformed, what was skipped) and every failed record with the exact reason it did not transfer. The vendor also claims "Zero downtime," with agents working in either platform while data moves in the background, plus SOC 2 Type II and GDPR compliance. That is far more than a raw CSV export offers.

Read the vendor's pricing page, though, and a second picture appears. Its paid options double as a list of what breaks by default:

• Screenshots disappear when the target platform does not support inline images.
• Internal links between knowledge base articles break after the move.
• Ticket-to-issue relationships, such as Jira links, can be lost.
• Contacts can lose their links to all but one of their companies.

Each fix is an option priced by quote. So is preserving legacy custom-field data as private notes on each ticket. Back in 2018, that same page claimed "60,000+ Migrations" and carried a testimonial from Aaron Johnson of Lids.com describing "roughly 370k tickets" moved from Zendesk to Jira over 10 days for roughly $10k, after manual quotes of 60k to 100k.

I find that options menu more candid than most migration guides. It is a failure list published as a price sheet.

Independent signals are thinner than the marketing. 6sense's 2026 technographic profile counts 152 current customers for Help Desk Migration and ranks it #98 in a "Database" category alongside Microsoft SQL Server, which shows how poorly general market data fits a one-off service. Neither number predicts whether your platform pair will migrate cleanly.

Practitioners put the tool fee in proportion. In one MSP discussion of a PSA switch, a vendor estimated about $6k to move 200K tickets, plus another $2k for hands-on assistance. A commenter's reply: "Your migration is going to be the trivial part of the cost." Another predicted roughly two years of tweaking the new platform afterward. A third said ConnectWise does not allow API access for migrations, so everything moves by CSV.

That gap matters most if you are moving toward AI. The same vendor argues that support history is an AI agent's best training data, and it sequences the knowledge base and highest-quality tickets first so automation has context on day one. If your shortlist comes from AI customer support software, treat mapping quality as a buying requirement rather than an IT chore. Incorrectly mapped records degrade triage accuracy and suggestion quality from the first day.

The integrity report will name every skipped field. Deciding which of those fields your agents actually need is a call no tool makes for you, and it has to be made before the full run, not after it.

How do you plan a help desk switch so nothing breaks after go-live?

Audit and export first, test until the failed-record report is explainable, then budget the automation, SLA and routing rebuild as its own project.

The order matters. Each step below exists because one of the seven failure points surfaces late, and expensively, when that step is skipped or done after the contract is signed.

1. Export and audit before you talk to vendors. Pull the full ticket history, user and organization records, knowledge base articles, and every macro, trigger and automation as reference material for the rebuild. Then document intake channels, routing logic, agent access levels and key integrations. That audit becomes your requirements list, whether you are comparing full help desks or building a live chat software shortlist.
2. Agree the test runs before you sign. MigrateX's October 2026 cost guide recommends fixing the number of test runs and the acceptance criteria up front, so an extra run becomes a priced decision rather than a surprise. Write acceptance as field-level checks, not "the tickets arrived."
3. Read the failed and skipped records line by line. In 2024, the same migration vendor's billing documentation named inactive employees and mandatory-field discrepancies as common reasons records were skipped or failed. Its re-migration windows were short: 5 days on the Advanced plan, enough for one sandbox run and one production run, and 10 days on Premium, the only tier that included delta migration. After the window closed, migration data was archived automatically.
4. Silence the target platform during the load. Freshservice, for example, does not mute Slack, Teams, business rules or workflows during bulk migration, so imported tickets can trigger live notifications and automations as they land.
5. Budget the rebuild as its own line. MigrateX is blunt that workflows, automations, business rules, SLA definitions, macros and running SLA timers are rebuilt on the target, not migrated, and it advises pricing that work with whoever configures the new platform. Routing rules and tagging systems belong on the same list.
6. Run both systems after cutover. Keep the old platform accessible for two to four weeks while new tickets go to the new one, name one person to field agent questions, and expect productivity to dip during the first week.

Short windows punish slow reviewers. A team that runs its full migration on a Friday and gets to the skipped-record report the following week may find the re-migration option already gone.

SLA history deserves its own test case. Closed issues imported into Atlassian by CSV keep counting against SLA goals, because they carry no history beyond the creation event; Atlassian's documented fixes are a flag field that excludes them from SLA goals, or a bulk transition to Done. So put a sample of imported closed tickets into the step-two acceptance test, and check that the first SLA report on the new platform does not count them as breaches. Field-level checks alone will not catch the clocks.

If I had to keep only one of these steps, it would be the second. An acceptance test written before signing changes who pays for a bad run, and it forces someone to decide, in writing, which fields actually matter to agents. The first time an agent opens a two-year-old ticket in the new system and finds the notes missing, that list is what tells you whether the migration failed or the scope did.

What will still break in your next help desk migration?

The logic, not the data. Record transfers keep getting more predictable, while macros, SLA clocks, routing rules and long-lived history still depend on your own rebuild and archive plan.

I expect record-count pricing and free test runs before payment to keep spreading, because they make the data side of a switch easy to quote. The harder failures sit where no quote reaches. A 2025 r/sysadmin thread shows the extreme case: a 40K-person company moving to its third service desk platform since 2015, with thousands of AD groups and firewall rules that point back to the tickets that created them. One commenter noted that a well-known migration service did not support the legacy source at all. Another team kept its 15-year-old system in read-only mode for a year after switching.

Plan for that outcome on day one. Decide which history must stay searchable, for how long, and where it will live.

Then track one number through your own switch: time to recover for each failure type, from the first broken macro to the last re-mapped field. Your next migration budget should start from that figure, not from a vendor's record count.