Help Desk Migration: How to Switch Without Losing Tickets

Updated September 2026.

A help desk migration is a different animal from most software switches, because your customers don't stop emailing while you move. Support data breaks in ways sales data never does: conversations thread apart, requesters split into duplicates, and the step that actually matters, routing live email to the new system, is the one most teams treat as an afterthought. This guide covers what goes wrong and gives you a plan to switch without dropping a single ticket.

Why help desk migrations go wrong

Key Facts: help desk migration

• 83% of data migration projects exceed their timeline or fail outright, usually from underestimated scope and skipped testing. Treat this as a widely repeated figure, not peer-reviewed research: the methodology isn't published.
• Only 27% of domain and URL migrations recover organic search traffic within 90 days, and the average recovery takes far longer. The dataset (1,052 migrations) is SALT.agency's own proprietary, crowdsourced data, not an academic study, but it's the most detailed breakdown available and applies directly to knowledge base URLs that move.
• Zendesk caps inbound attachments at 50MB but outbound at just 7MB, while Freshdesk caps attachments at 15-20MB per email by plan. A file that cleared the old system won't automatically clear the new one.

Most help desk switches fail in one of eight predictable ways, and almost none of them look like a CRM migration's failure modes.

Ticket threading collapses. A support conversation is a chain: the original email, replies, an internal note, a CC'd manager. Most importers move each message as a separate object instead of a linked thread. The ticket count looks right in a spot check, but agents can no longer tell what a customer already said.

Attachments get dropped or bounced. Screenshots, log files, and signed PDFs are common in tickets, and every platform sets its own size ceiling on inbound versus outbound mail. A file that lived fine in the old system for years can silently fail to import, or import and then fail to send on the next reply, and nobody notices until a customer asks where it went.

Requesters don't dedupe. One customer who emailed from three addresses, chatted from a fourth, and called from a fifth becomes five separate contacts instead of one. Agents lose that customer's full history exactly when they need it most, since escalations spike in the first two weeks after any cutover.

Custom fields and tags have no target equivalent. A dropdown field for "Plan Tier" or a tag scheme for escalation routing rarely maps one-to-one to the new platform's field types. Teams either lose the data or dump it into a free-text field where it can't be filtered, reported on, or automated against again.

Historical timestamps get rewritten to the import date. This is the one that quietly wrecks reporting. If every historical ticket shows a "created" date of migration day, every SLA report, MTTR trendline, and quarter-over-quarter comparison you've run becomes worthless. Nobody notices until someone pulls a report weeks later and the numbers make no sense.

Macros and automation rules don't transfer at all. Canned responses, auto-assignment rules, escalation triggers, and survey logic aren't data, they're configuration, and almost no importer moves them. They have to be rebuilt by hand, and if nobody documented the old rules first, half of them get forgotten.

Knowledge base articles lose formatting and their URLs change. Rich formatting, embedded images, and anchor links often break on import, and if your KB slugs change, every backlink and ranked search result pointing at the old URL now 404s. That's lost organic traffic that took years to earn.

Email forwarding and DNS cutover can drop live tickets on the floor. This is the step a CRM migration never has to worry about. The moment you repoint your support email, MX record, or web widget, any ticket in flight can vanish if the sequencing is wrong. Unlike a CRM, you can't take the weekend off: customers keep emailing the whole time.

What to plan for before you migrate

Build a full inventory before you touch an export button. The table below covers what to check for each object type.

Clean before you migrate, not after. Merge duplicate requesters, standardize tag naming, and archive tickets closed more than 24 months ago. A smaller, cleaner dataset migrates faster with fewer surprises during validation.

Document every macro and automation rule now. Walk through your current system's rules and write down what triggers each one and what it does. This becomes your rebuild checklist in the new platform and your QA list for confirming nothing was missed.

If you haven't settled on a destination yet, how to choose help desk software and help desk evaluation criteria are the right starting points. Still deciding whether you need a dedicated help desk at all? Read help desk vs. shared inbox first.

A step-by-step help desk migration plan

Phase 1: Audit and scope

Pull a full ticket count, requester count, and attachment volume from your current system. Export a sample of 100-200 tickets and open the raw file in a spreadsheet to see exactly what fields and thread structure you're working with. This becomes your migration spec and your go/no-go criteria.

Phase 2: Map your fields, tags, and macros

Build a mapping document: source field, source type, target field, target type, and a notes column for transformations. Pay close attention to picklist fields whose options don't match exactly, and list every macro and automation rule alongside its planned rebuild location.

Phase 3: Clean and dedupe requesters

Run requester deduplication before export, not after. Most help desks have a merge tool for contacts; use it. Standardize how company domains map to accounts so the target system doesn't recreate the same fragmentation you're trying to fix.

Phase 4: Pick your migration method

See "Migration approaches at a glance" below. Ticket volume, thread complexity, and whether you need historical timestamps preserved all drive this choice.

Phase 5: Test on a sandbox

Run the full migration into a trial or sandbox account first, if your target platform offers one. Check that threads stay linked (not flattened into separate messages), that timestamps carry over as the original dates, that custom fields populate correctly, and that a sample of attachments actually opens.

Phase 6: Dry run with production data

Re-run the migration with a current export to catch anything that changed since your initial audit. Get sign-off from a support lead and at least one agent who works tickets daily, not just the person who scoped the project.

Phase 7: Plan the parallel run

This is where a help desk migration diverges hardest from a CRM one. You cannot put your support inbox in read-only mode for a weekend, because customers keep emailing regardless of what you're doing internally. Run a deliberate parallel window instead:

Phase 8: Cutover and validate

Execute the DNS and forwarding changes from Phase 7 during your lowest-traffic window. Immediately after cutover, work through the validation checklist below before declaring the migration complete.

Phase 9: Decommission

Once the parallel window closes cleanly, with the rollback trigger below never firing, cancel the old contract and archive a final export for compliance. Don't decommission early just because week one looked clean.

Migration approaches at a glance

How to decide: a migration decision framework

Migrating your CRM at the same time? The CRM migration guide covers the sales-data side, and the accounting software migration guide helps if that system is also in motion.

Validation checklist and rollback trigger

Don't call the migration done until every row below checks out.

Rollback trigger: agree on this before cutover, not during it. A common threshold is "more than 2% of tickets in the first 24 hours show a routing, threading, or data error." If you hit it, revert DNS and forwarding to the old system immediately, work the backlog from there, and re-attempt cutover only after the root cause is fixed and re-validated in sandbox.

Pricing: what to expect

DIY (native importer). Free to cheap in dollars, expensive in staff time. Budget 2-5 days of support-lead time for a clean migration under 5K tickets, more if thread history matters.

Vendor-assisted onboarding. Most mid-market help desk vendors bundle onboarding into the sales process, either included or for a few thousand dollars depending on tier and ticket volume.

Specialized migration service. Help Desk Migration's own pricing example shows a basic migration on its Standard support plan running $100 for 1,000 records, scaling to roughly $514 for 10,000 under the same terms, with volume discounts as record counts grow. Attachments, comments, and notes are included; larger or custom scopes are quoted after a free demo migration against your real data.

Custom API-based migration. Engineering time is the main cost, scaling with how much thread and timestamp fidelity you need plus how many integrations require reconnecting.

Ongoing cost of your destination platform, per the vendors' own current pricing pages:

Zendesk's $19-$25 range is its Support-only line, not the Suite plans most teams end up buying; keep those separate when comparing totals. HubSpot Service Hub Professional also carries one-time onboarding fees of $1,500 (Professional) or $3,500 (Enterprise) on top of the per-seat rate.

Hidden cost to budget for. Agent efficiency typically dips for a few weeks post-migration while the team relearns shortcuts, macro names, and where things live. That's not a line item on any invoice, but it shows up in first-response time, so flag it to leadership before cutover, not after.

Frequently asked questions

How long does a help desk migration take?

It depends on ticket volume and thread complexity. A small team with under 5,000 tickets and simple fields can finish in a few days with good preparation. A mid-market migration with 20,000-100,000 tickets, custom fields, and several integrations typically runs 3-8 weeks including audit, cleanup, sandbox testing, and the parallel-run window. Larger or heavily customized environments run longer, mostly due to automation-rebuild work.

Can I keep receiving customer tickets during the migration?

Yes, but you have to plan for it rather than hope for it. Unlike a CRM, a help desk can't go read-only for a weekend without customers noticing. The safest approach is a phased dual-run: point new traffic at the new system on cutover day, keep the old inbox forwarding anything that still arrives there, and run both systems in parallel for at least 30 days.

What happens to my historical timestamps and SLA reports?

This is the failure mode teams discover latest and regret most. If your migration tool rewrites every ticket's creation date to the import date, every historical SLA and MTTR report becomes meaningless, because the data no longer reflects when tickets were actually created and resolved. Check this specifically, on tickets from several time periods, during sandbox testing, before you touch production data.

Do macros and automation rules migrate automatically?

No. Macros, canned responses, assignment rules, and escalation triggers are configuration, not data, and essentially no migration tool moves them. Document every rule in plain language before you migrate, then rebuild and test each one against the same trigger conditions in the new platform.

What's the biggest mistake teams make during a help desk migration?

Treating the email and DNS cutover as a technical afterthought instead of the highest-risk step in the project. Data mapping errors are annoying but recoverable. A botched cutover can drop live customer tickets with no record they ever arrived. Lower your DNS TTLs days in advance, keep the old inbox forwarding through the transition, and agree on a rollback trigger before you touch a DNS record, not after something breaks.

Get the migration right the first time

A help desk migration succeeds or fails on the parts that don't look like data: the macros nobody wrote down, the DNS record nobody double-checked, the SLA report nobody validated until weeks later. Treat the cutover as the smallest part of the project and the planning, sandbox testing, and parallel run as the real work, and the switch itself becomes close to uneventful.

If you're still narrowing down where to land, how to choose help desk software for small business and how to choose support software for startups cover the evaluation side first.

Related reading

• Help desk evaluation criteria
• How to build a software shortlist
• How to choose help desk software
• Help desk vs. shared inbox
• How to choose help desk software for small business
• How to choose support software for startups
• How to choose knowledge base software
• How to choose shared inbox software
• CRM migration guide
• Accounting software migration guide