Most helpdesk migration guides stop at "export CSV, import CSV." That's not a playbook — that's the easy 20% of the work. The hard 80% is preserving inbound-reply threading (Message-ID headers), keeping tag semantics stable across systems, and not orphaning the magic-link URLs customers already bookmarked. This 60-day playbook sequences the cutover around those three risks while both systems run in parallel.

Key takeaways

• The three failure modes that turn a helpdesk migration into a customer-facing incident are broken Message-ID threading, silently shifted tag semantics, and dead magic links in existing customer inboxes.
• Run both systems in parallel for at least three weeks. A hard cutover on day 30 will fail; a staged cutover with dual forwarding on day 45 rarely does.
• Import legacy tickets with their original Message-ID headers preserved so future customer replies thread to the imported ticket, not a new orphan.
• Freeze your tag taxonomy in the source system for two weeks before export. Every rename or merge you do after the export snapshot creates a mismatch that no automation can reconcile.
• Budget 60 days for a 10-agent team. Teams that compress it to 30 tend to re-do the work in month four.

Why CSV-only migrations quietly break B2B support

A CSV export gives you ticket bodies, statuses, and requester emails. That's the visible layer. The invisible layer is what makes email support actually work: the RFC 5322 Message-ID on every historical outbound reply, the In-Reply-To chain that lets a customer's "quick follow-up" from six months ago land back on the right ticket, and the tokenized URLs sitting in confirmation emails that customers use to check status without logging in.

Standard imports drop all three. When a customer replies to a two-year-old thread post-migration, the reply arrives at your new helpdesk with no matching Message-ID — so it creates a brand-new ticket with no context, no history, and no assignee. Your agent sees "per my last email" with no last email. Multiply that by every long-tail customer relationship and you've manufactured a support debt crisis in month two.

The playbook below is designed to prevent that.

Days 1-10: Audit the source system

Before you touch the new tool, catalog what you actually have. On a 5-15 agent B2B SaaS team, this usually means:

• Ticket volume by state: open, pending, on-hold, solved in the last 90 days, closed. The first three are the migration hot zone.
• Tag taxonomy: every active tag, its usage count, and — critically — its meaning. Tags named billing and billing-issue are the same thing to your team and different things to any import script.
• Custom fields: name, type, required status, and which forms use them.
• Automation dependencies: which triggers and macros reference which tags. Renaming urgent-vip breaks four macros silently.
• Magic-link exposure: run a query for every outbound email in the last 12 months that contained a tokenized status-check URL. That's your "link debt" — the population of customer inboxes that will 404 if you don't handle redirects.

Output of days 1-10: a spreadsheet with four tabs (tags, fields, automations, link debt) and an executive summary of what breaks if you do nothing.

Days 11-20: Freeze the taxonomy and prep the target

This is where most migrations already went wrong before day 1. If your team is still merging tags, renaming custom fields, and reorganizing groups during the migration window, no import tool can reconcile the drift.

Declare a taxonomy freeze on day 11. From that day, no new tags, no renames, no field-type changes in the legacy system. Route new taxonomy proposals to a doc that you'll implement in the target system after cutover.

In parallel, set up the target helpdesk:

1. Create your brands, business hours, and groups to mirror the source.
2. Recreate the tag taxonomy exactly — same names, same casing.
3. Recreate custom fields with matching types (text, dropdown, date) and, where dropdowns are involved, matching options in the same order.
4. Configure email forwarding for one low-volume inbound alias as a test — don't cut over your main queue yet.
5. Invite two agents (not the whole team) to start smoke-testing.

Days 21-30: Import history with Message-ID preserved

Day 21 is when you run the historical import. The non-negotiable requirement: whatever import tooling you use, it must preserve the original Message-ID on every message row and dedupe on legacy IDs to prevent double-imports if you rerun.

Helptal's one-shot import from Zendesk, Help Scout, and Intercom is built around exactly this: users, orgs, groups, tags, tickets, and comments come across with legacy-ID dedupe and Message-ID preservation intact, so post-cutover customer replies thread onto the imported conversation instead of creating orphans.

During days 21-30, do three things:

• Import in staged batches (solved tickets first, then open). Verify Message-ID preservation by spot-checking 20 imported tickets against the source.
• Do NOT close the legacy system. It stays writable for open tickets that agents are actively handling.
• Set up an audit query on the target: "tickets created in the last 24h with no In-Reply-To match to an imported ticket." This surfaces threading failures early.

Days 31-45: Parallel run with dual forwarding

The parallel-run window is the safety net that separates a professional migration from a nightmare. Here's the topology:

The redirect layer is what prevents your link debt from becoming customer-facing 404s. If your legacy tool is a subdomain like support.acme.com, keep that DNS pointed at a small redirect service (Cloudflare Worker, nginx, whatever) that maps old ticket-URL patterns to new ones. Most B2B SaaS teams need to maintain this for 12-18 months — customer inboxes have long memories.

During days 31-45, watch three metrics:

1. Thread-break rate: new tickets that should have threaded to imported ones but didn't. Target: under 1%.
2. Agent double-handling: tickets touched in both systems. Target: zero after day 40.
3. Redirect log volume: how many customers are still hitting legacy magic links. This tells you when it's safe to sunset the legacy portal.

Days 46-60: Cutover and legacy shutdown

Day 45 is the cutover. From that day:

• All new inbound routes to the new system only.
• Legacy becomes read-only. Agents can view tickets but not reply.
• Any legacy tickets still open get bulk-migrated as "new" tickets in the target system with a note linking to the read-only source.
• The redirect layer stays up. Don't touch it.

Days 46-60 are stabilization: retraining agents on macros and views, tuning the automations you rebuilt, and running a full post-migration audit. The audit checks that (a) sample customers can still reach status via old links, (b) tag counts in the new system match the frozen taxonomy from day 11, and (c) no imported ticket has broken threading.

Migration risks ranked by likelihood

How Helptal fits in

This playbook was designed against Helptal's data model on purpose. Helptal's Zendesk / Help Scout / Intercom import handles users, orgs, groups, tags, tickets, and comments in a resumable staged flow with legacy-ID dedupe and Message-ID preservation — so customer replies to two-year-old threads still thread correctly post-cutover. Combined with custom fields, a bundled help center, and included live chat, a 60-day migration usually lands on a lower per-agent cost than the legacy tool it replaced.

Frequently asked questions

How long should a helpdesk migration take for a 10-agent B2B SaaS team?

Budget 60 days end-to-end: 10 days audit, 10 days taxonomy freeze and target setup, 10 days historical import, 15 days parallel run, 15 days cutover and stabilization. Teams that compress this to 30 days almost always end up re-doing work in month three or four because tags drift, threading breaks slip through, or automations don't get rebuilt cleanly.

Can I preserve Message-ID threading during a helpdesk migration?

Yes, but only if your import tool explicitly preserves the RFC 5322 Message-ID on every historical message row. Generic CSV imports drop this header, which means future customer replies to old threads land as orphan tickets with no context. Verify by spot-checking 20 imported tickets and confirming the Message-ID column is populated, then wait for a real customer reply and confirm it threads.

What happens to old customer magic links after we migrate?

Without a redirect layer, they 404. Customer inboxes have 12-18 month memories, so this creates a slow-drip customer complaint problem. Maintain a small redirect service (Cloudflare Worker or similar) that maps legacy magic-link URL patterns to the equivalent in your new system. Watch the redirect logs — when volume drops below a threshold you set, you can safely retire it.

Should I freeze my tag taxonomy before migrating?

Yes, at least two weeks before export. Every rename, merge, or new tag added between the freeze and the import creates a mismatch that no automation can cleanly reconcile. Route all new taxonomy proposals to a document you'll implement in the target system after cutover — that gives you a clean before/after snapshot and preserves reporting continuity.

When can we shut down the legacy helpdesk entirely?

Read-only mode should stay up for at least 6 months post-cutover so agents can reference historical context that didn't import cleanly. The redirect layer for magic links should stay up for 12-18 months. Actually decommissioning the legacy tenant — including cancelling the subscription — is usually safe around month 9, once redirect log volume has dropped to near-zero.

Start with the audit spreadsheet this week. You can't sequence a migration you haven't scoped, and the four-tab audit (tags, fields, automations, link debt) is the artifact that makes every subsequent decision defensible. If you're evaluating tooling for the target side, Helptal's free plan lets you build out the target workspace and validate the taxonomy before you commit any budget.