Most helpdesk migrations don't fail at the export step. They fail two weeks after cutover, when a customer replies to an old email and the reply lands in a brand-new ticket with no history attached — or worse, vanishes into a bounce. This playbook walks support ops leads at 5-15 agent B2B SaaS teams through a 45-day helpdesk migration plan built around three things the vendor sales decks rarely mention: Message-ID preservation, legacy-ID dedupe, and a phased dual-running cutover.

Key takeaways

• The technical risk in a helpdesk migration isn't moving the data — it's keeping the Message-ID headers intact so inbound replies thread to the migrated tickets instead of opening duplicates.
• Legacy-ID dedupe (storing the source system's ticket ID on every imported record) is what lets you re-run a failed import without creating doubles, and it's what makes resumable imports possible.
• A 45-day calendar with three phases — 21 days of setup, 14 days of dual-running both inboxes, 10 days of decommissioning — gives a small team enough room to catch problems before customers do.
• Dual-running means new tickets land in the new system while old threads finish in the old one; agents work two inboxes for ~2 weeks, then the old inbox goes read-only.
• The migration checklist that matters in 2026 is shorter than the one vendors hand you: DNS, DKIM alignment, Message-ID/In-Reply-To preservation, legacy-ID dedupe, customer-facing email continuity, and a CSAT baseline you can compare against post-cutover.

Why most helpdesk migrations break (and it's not the data export)

The data export usually works. Zendesk, Help Scout, Intercom, Freshdesk — they all hand you JSON or CSV with users, organizations, tags, tickets, and comments. The breakage starts when those tickets land in the new system and customers reply to old email threads.

Every email a helpdesk sends includes a Message-ID header. When the customer replies, their mail client adds In-Reply-To and References headers pointing back at that ID. That's how the reply finds its way back to the right ticket. If your migration generates fresh Message-IDs for imported tickets instead of preserving the original ones, every old thread becomes a new ticket on the next customer reply — with no history, no context, and a confused agent.

The second silent killer is duplicate creation during re-imports. Migrations rarely succeed on the first run. If your import script doesn't store the source system's ticket ID (call it legacyId) on every record, your second pass creates a second copy of everything. Now you have 4,000 tickets where you had 2,000, and no clean way to tell them apart.

The 45-day timeline at a glance

The 45-day length isn't arbitrary. Three weeks is the minimum to do a full dry-run import, validate threading on a staging domain, and train agents without burning weekends. Two weeks of dual-running is roughly one customer-response cycle for B2B SaaS — long enough that 80%+ of open threads at cutover will have closed naturally. Ten days of decommissioning gives breathing room for the long-tail replies.

Phase 1: Setup (days 1-21)

Week 1 is reconnaissance. Pull a full export from your current helpdesk and audit it. Count tickets, count attachments, count customer organizations. Note your custom fields, your macros, your SLA policies, your automation rules. Take screenshots of your reporting dashboards so you have a before-and-after baseline.

Week 2 is configuration. Stand up the new workspace, recreate groups and topics, rebuild macros, port over SLA policies. Don't try to recreate every automation rule from day one — most teams discover they were carrying 30-40% dead rules.

Week 3 is the test import and DNS prep. Run a complete import into a staging brand or workspace. Pick 20 random migrated tickets and reply to them from a test email account. Did the reply thread correctly? Did the customer get a response from the right sending domain? Did DKIM align?

The DNS work is the longest-lead item. You need:

1. A DKIM CNAME record on your sending domain so outbound mail signs as d=yourcompany.com, not d=helpdeskvendor.com.
2. SPF/DMARC alignment verified with a test send to a Gmail account (check the original headers).
3. An MX or forwarding plan for your inbound support address ([email protected]). Forwarding is faster to set up; MX delegation is cleaner long-term.

Phase 2: Dual-running (days 22-35)

This is the part most migration guides skip. On day 22, you cut new ticket creation over to the new system — but you do not shut down the old one. Customers keep emailing the same address. Your forwarding or MX setup routes new threads to the new helpdesk, while existing in-flight threads in the old system continue replying out the old system until they're solved.

Agents work two inboxes during this window. Most teams handle this with a shared agent-side dashboard or a simple browser-tab discipline: old system tab for threads already in progress on day 22, new system tab for everything that started on day 22 or later.

This sounds painful and it is, mildly. But the alternative — a hard cutover where all open threads migrate cold into the new system — creates a flood of reply-to-the-wrong-place tickets in week one, exactly when your agents are least familiar with the new tool. Two weeks of moderate inconvenience beats one week of customer-visible chaos.

What to watch during dual-running:

• Reply-threading rate. Sample 30 inbound replies on the new system per week. Confirm they're threading to existing tickets, not opening new ones. If you see >5% mis-threading, your Message-ID preservation broke — pause and fix before continuing.
• CSAT. Run your usual CSAT survey. A 5-10 point drop in week 1 is normal as agents adjust. A 15+ point drop means something structural is wrong.
• First-response time. Will tick up 20-40% as agents learn the new UI. Should return to baseline by end of week 2.

Phase 3: Decommission (days 36-45)

On day 36, set the old helpdesk to read-only or a routing-only mode. Any remaining open tickets either get force-closed (if stale) or manually re-created in the new system with a note linking to the old thread. Take a final full export and archive it somewhere durable — S3, a compliance bucket, wherever your retention policy lives.

Days 37-42 are KB and link cleanup. If your knowledge base moved too, set up 301 redirects from old article URLs to new ones. Update every "contact support" link in your product, your billing emails, your onboarding sequences. This is tedious and unglamorous and the thing most often skipped — and the thing that quietly costs you tickets six months later.

Days 43-45 are vendor offboarding. Cancel the old subscription effective the renewal date (not immediately — keep read-only access for audit). Revoke API tokens. Remove the old helpdesk's domain from your DNS. Confirm the final invoice. Done.

The migration checklist for 2026

The checklist that actually matters, in priority order:

1. Message-ID preservation. Your import process stores the original Message-ID of every inbound message so replies thread correctly.
2. Legacy-ID dedupe. Every imported ticket, user, and organization carries the source system's ID so re-imports don't double up.
3. Resumable imports. The import is staged and resumable — a network blip at hour 6 doesn't mean starting over.
4. DKIM alignment on the new sending domain. Outbound mail signs as your domain, not the vendor's.
5. Inbound routing plan. Forwarding or MX, decided and tested before cutover.
6. Custom field mapping. Documented field-by-field, with types (text/dropdown/date) preserved.
7. Agent training. At least one full session per agent before dual-running starts, not during.
8. CSAT baseline. Recorded for the 30 days before migration so you can compare.
9. KB redirect map. Old slug → new slug, for every published article.
10. Rollback plan. What you do if reply-threading breaks at >10% in week 1 of dual-running.

How Helptal fits in

If you're migrating to Helptal, the things that usually wreck a migration are built into the one-shot import for Zendesk, Help Scout, and Intercom: legacy-ID dedupe on every record, Message-ID preservation for inbound-reply threading, and resumable staged imports so a failure at hour 6 doesn't restart from zero. CNAME-delegated DKIM means your outbound mail signs as your own domain from day one. And because chat, email, and the knowledge base sit in the same inbox, the dual-running phase doesn't require agents to learn three new tools — just one.

Frequently asked questions

How long does a helpdesk migration take for a 10-agent team?

Plan for 45 days end-to-end: 21 days of setup and test imports, 14 days of dual-running both systems, 10 days of decommissioning. Smaller teams (under 5 agents) can compress to 30 days. Skipping the dual-running phase to save time is the single most common cause of post-migration customer-trust damage.

What happens to old ticket history during a helpdesk migration?

If your import preserves the source system's ticket IDs and original Message-IDs, full history transfers and inbound replies thread to the correct ticket. Without those two things, history may import correctly but new replies to old threads will open fresh, context-less tickets. Always test threading on 20+ sample tickets before cutover.

Can I migrate helpdesks without any customer-visible downtime?

Yes, with a dual-running phase. Customers keep emailing the same support address throughout. New threads land in the new system; existing in-flight threads finish in the old system. Two weeks of dual-running covers ~80% of open-thread close-out for a typical B2B SaaS team. The customer never sees a service interruption.

What's the biggest mistake in helpdesk migrations?

Hard cutover. Switching every open ticket and every inbound thread to the new system on day one creates a flood of mis-threaded replies, frustrated agents, and confused customers — exactly when your team is least familiar with the new tool. The fix is a 14-day dual-running window where new and old systems both receive mail.

Do I need to migrate my knowledge base at the same time?

Not necessarily, but if you do, plan the URL redirects before cutover. Every old article URL needs a 301 to its new location. Skipping this step quietly costs you organic traffic and creates broken "contact support" links inside your product that route to dead pages.

If you're starting a migration this quarter, the one thing to do this week is run a test export from your current helpdesk and audit it for completeness — count tickets, attachments, custom fields, and orphaned threads before you sign anything. That single hour of work will save weeks later. If you're evaluating where to land, Helptal's free trial includes the full Business feature set for 14 days, which is enough to dry-run a staged import end-to-end before you commit.