Most helpdesk migrations don't fail at the data export. They fail at four artifacts that nobody plans for: Message-ID preservation, in-flight SLA clock state, customer organization mappings, and the translation of macros into triggers. Get those right and a 45-day rollout lands cleanly. Miss any one and week three feels like starting customer support from scratch. This playbook walks the full 45 days, week by week, with the decisions that matter.
Key takeaways
- Real helpdesk migration risk lives in four artifacts — Message-ID continuity, in-flight SLA state, org mappings, and macro logic — not in the CSV export of past tickets.
- A 45-day window is the sweet spot for 5-15 agent B2B SaaS teams: long enough to preserve in-flight context, short enough to avoid two-tool fatigue.
- Run the legacy mailbox and the new helpdesk in parallel for exactly 14 days — any longer and agents start working from two queues permanently.
- The migration succeeds or fails on day 30, when in-flight tickets need to keep threading correctly across the cutover. Plan for Message-ID preservation from day one.
- Treat macros as logic, not text. A flat list of canned replies in Gmail becomes a routing-plus-status-plus-reply trigger on a real helpdesk, and the translation needs an owner.
Why most helpdesk migrations regress in week three
The pattern is consistent. Weeks one and two feel great — the new tool is faster, the inbox is organized, agents are energized. Then week three hits and three things happen at once: a customer replies to an email from the old system and the thread doesn't reconnect, an SLA timer that was halfway through on the old tool fires immediately on the new one, and an agent applies a macro that no longer routes the ticket the way the old canned reply did.
None of this shows up in a vendor's migration checklist. Standard guides cover "export your tickets, import them here." That's table stakes. The regression risk is in the connective tissue: how email headers thread inbound replies to existing tickets, how SLA clocks resume mid-cycle, how customer-to-organization relationships survive the move, and how agent muscle memory translates between systems.
A proper helpdesk migration playbook treats those four artifacts as first-class deliverables — not afterthoughts.
The four artifacts that decide the outcome
Message-ID preservation
Every email carries a Message-ID header. Reply threading depends on it. When a customer replies to your old support address two weeks after cutover, the new system needs to recognize the In-Reply-To header pointing at the legacy message and attach the reply to the migrated ticket.
If your import tool drops Message-IDs, you get duplicate tickets, lost context, and customers asking "didn't I already explain this?" The fix isn't complicated, but it has to be designed in before the import runs. Confirm with your new vendor — in writing — that inbound Message-IDs are preserved on migrated tickets and that the inbound mail pipeline matches on In-Reply-To / References headers, not just the From address.
In-flight SLA clock state
A ticket created on the old tool 6 hours ago, with an 8-hour first-response target, has 2 hours left. If the new tool starts the clock at zero on import, you've quietly handed every in-flight ticket a fresh full SLA — which sounds generous until the customer experience says otherwise. If the new tool starts the clock at the original creation timestamp without honoring business hours, you've breached half your queue on day one.
The right behavior: import the original createdAt, the original firstResponseAt if it exists, and let the new SLA engine compute remaining time from there, respecting your configured business hours. Test this with five sample tickets before the full import.
Customer organization mappings
For B2B SaaS support, the customer-to-organization relationship is half the value of a real helpdesk. "Three open tickets from Acme this week" is a different signal than "Sarah at Acme has one open ticket." If your migration imports users without rebuilding the org membership graph, agents lose account context overnight.
Gmail and Outlook shared mailboxes have no concept of organizations, so this is a build, not a transfer. Pull org data from your CRM (HubSpot, Salesforce, Pipedrive) via CSV or API and load it alongside users. If you're moving from a legacy helpdesk, confirm the importer carries org membership, not just user records.
Macro-to-trigger translation
Gmail canned responses are flat text. Helpdesk macros are text plus actions — apply a tag, change status, reassign, set priority. The migration moment is the right moment to upgrade your canned replies from "text I paste" to "workflow I trigger."
List every canned reply in use. For each, decide: does this reply also imply a status change (Solved? Pending?), a tag (billing, bug-report), or a reassignment (to engineering escalation)? Build those as macros on day one. Anything that should fire automatically based on inbound conditions becomes a trigger, not a macro.
The 45-day timeline, week by week
| Week | Phase | Primary deliverable |
|---|---|---|
| 1 | Audit | Inventory of mailboxes, canned replies, SLAs, customer orgs |
| 2 | Setup | New helpdesk configured, brand, groups, business hours |
| 3 | Import dry run | Test import with 50 sample tickets, validate the four artifacts |
| 4 | Parallel start | Full import, dual-running starts, agents trained |
| 5 | Parallel monitor | Both systems live; new tickets land on new tool only |
| 6 | Cutover | Old mailbox forwards to new; legacy access read-only |
| 7 | Stabilize | Reports, automations tuned, edge cases cleaned up |
Step-by-step: the 45-day rollout
- Days 1-7 — Audit. Export every canned reply, document every routing rule (even the informal "Janet handles billing" rules), list every SLA commitment in customer contracts, and pull org membership data from your CRM. Write down which mailboxes feed support (support@, billing@, help@). Most teams discover 2-3 inboxes they forgot about.
- Days 8-14 — Configure. Provision the new helpdesk. Set up brand, business hours, groups, agent roles, and SLA policies. Build the macro library from your canned-reply audit, this time with status and tag actions attached. Configure inbound email — either by forwarding your existing addresses to a generated inbound address or by pointing MX records at the new mail server.
- Days 15-21 — Import dry run. Run a test import with 50 representative tickets: a few solved, a few open, a few with attachments, a few with long threads. Verify Message-IDs are preserved (check the database or API), SLA clocks compute correctly, org mappings carry over, and macros fire as expected. Fix gaps now, not after the full import.
- Days 22-28 — Full import and parallel start. Run the full import over a weekend. Monday morning, agents work from the new tool for new tickets while the old mailbox stays open in read-only mode for legacy in-flight context. Send the team a one-page cheat sheet: how to find a customer's history, how to apply a macro, how to escalate.
- Days 29-35 — Parallel monitor. Both systems are technically live, but new inbound mail only lands on the new tool. Watch for two failure modes: customers replying to old threads (those should land in the right migrated ticket — verify daily) and agents reflexively checking the old mailbox (block this culturally and via permissions).
- Days 36-42 — Cutover. Forward the old support address to the new inbound address. Revoke write access on the old mailbox. Run a full audit: every in-flight ticket has the right assignee, right status, right SLA clock. Pull a customer-history sample to confirm org context renders correctly.
- Days 43-45 — Stabilize. Turn on the reports you care about. Run a week-one CSAT check against pre-migration baseline. Hold a retro with the team — what's faster, what's slower, what canned reply still doesn't have a home.
What to migrate, what to leave behind
Not every artifact deserves migration. A clear policy keeps the project small.
- Migrate: open and pending tickets, solved tickets from the last 12 months, user records, org mappings, canned-reply logic, SLA policies.
- Archive (don't migrate): solved tickets older than 12 months — keep them readable in the old system or in a CSV archive, but don't pay the import cost or pollute new-system search results.
- Rebuild fresh: triggers, automations, reports, agent groups. These should be designed for the new tool, not ported. Old automations were shaped by old constraints.
How Helptal fits in
Helptal was built with this exact migration profile in mind. The one-shot import from Zendesk, Help Scout, and Intercom preserves Message-IDs so inbound replies thread correctly to migrated tickets, and the SLA engine honors business hours when resuming in-flight clocks. Customer organizations import as first-class objects, so agent sidebars show account-level context from day one. The macro library on Helptal's shared inbox treats canned replies as workflow actions — status changes, tags, reassignments — not just paste-able text. For teams moving off Gmail or Outlook, the forwarding-mode inbound email means no DNS work to get started.
Frequently asked questions
How long should a helpdesk migration take for a 10-agent B2B SaaS team?
Forty-five days end-to-end is the right target for a 5-15 agent team. That breaks down into one week of audit, one week of configuration, one week of import dry runs, two weeks of parallel running, and one week of cutover and stabilization. Compressing below 30 days usually means skipping the parallel-running phase, which is where most in-flight context gets lost.
Will customers notice we changed helpdesk software?
They shouldn't, if you preserve Message-IDs and keep the support email address unchanged. The reply they sent yesterday should thread to the same conversation today, with the same agent context. The visible changes — branded portal, CSAT surveys, faster response times — should feel like quality-of-life improvements, not a forced relationship reset.
What's the biggest risk in a helpdesk migration?
Double-handling. If the old mailbox stays writable after cutover, half the team will reflexively keep working there for weeks, and your customer view fragments across two systems. The fix is a hard cutover date with read-only access on the old system afterward — and a 14-day cap on the parallel-running phase.
Do we need to import every old ticket?
No. Import open and pending tickets, plus solved tickets from the last 12 months for search context. Older tickets can stay archived in the source system or exported to CSV. Importing five years of history slows the migration, clutters search results, and rarely pays off — agents reference recent context, not ancient history.
How do we handle SLAs on tickets that are already in-flight during the cutover?
Preserve the original createdAt timestamp on import and let the new SLA engine compute remaining time against your configured business hours. Test this with sample tickets before the full import. The wrong behavior is starting fresh clocks (too generous) or honoring elapsed wall-clock time without business-hours math (too punishing). Verify both modes during the dry-run week.
This week, do the audit. Walk through every mailbox feeding support, list every canned reply, and pull the org membership data from your CRM. That single exercise tells you whether you're 45 days from cutover or 90, and it costs nothing to run. If you're evaluating tooling alongside the audit, Helptal's free plan covers the full feature set used in this playbook so you can run the dry-run import without committing.