Helpdesk migration checklist

Use this when you are moving from one helpdesk to another — Zendesk to Intercom, Freshdesk to Zendesk, a shared inbox to any real tool. It is written to be run in order: Before is the audit and prep you do in the weeks leading up, During is the cutover weekend itself, After is the first month of cleanup. Replace anything in [brackets] with your own tools and names.

Migrations rarely fail at go-live. They fail three weeks later, when the first monthly report reads zero, a reopened ticket arrives stripped of its history, and the macro that used to route it sits there doing nothing. The four things that break — data, macros, integrations, reporting — each get their own audit below. Do the boring verification and the Monday-morning surprise doesn't happen.

Assign owners first. A migration with no named owner per area is a migration that loses a category.

---

Before — audit and prepare

The goal of this phase is that nothing about go-live is a surprise. You know exactly what is moving, what is being left behind on purpose, and what the new tool will do differently.

Audit the data

• Export a full count from the old system: total tickets, open vs. closed, and volume by year — so you can prove the import is complete afterward
• List every custom field and its type (dropdown, text, date, checkbox) and decide which map over, which get merged, and which get dropped
• List every ticket tag / label in use; flag tags with fewer than [10] uses for retirement rather than migration
• Decide the cutoff: are you importing all history, or only tickets from the last [24] months and archiving the rest?
• Confirm how internal notes vs. public replies are distinguished, and that the new tool preserves that distinction
• Confirm attachments, inline images, and timestamps come across, and that author identity (agent vs. customer) is preserved
• Note that ticket IDs will almost certainly change — inventory anywhere old IDs are referenced (KB articles, internal wikis, "see ticket #4471" notes) so those links can be fixed or redirected
• Reconcile customer and organization records: dedupe contacts, merge duplicate orgs, and agree on the matching key (email? external ID?) before import

Audit macros and automation

• Export or screenshot every macro / saved reply; count how many are actually used in the last [90] days and archive the dead ones instead of rebuilding them
• Document every trigger, automation, and workflow rule with its condition, action, and the order it runs in — triggers fire in a different sequence on a different engine
• List all SLA policies and their exact clock rules: business hours, pause conditions, what counts as first response
• List all routing / assignment rules (round-robin, skills-based, group-based) and the groups they depend on
• Recreate your group and role structure in the new tool first — most automations depend on it
• Flag automations that touch external systems (send a webhook, create a Jira issue) — these need the integration live before they can be tested

Audit integrations

• Inventory every connected system: telephony/CCaaS, live chat, CRM, billing, order lookup, Slack/Teams, Jira/engineering, survey/CSAT tool, BI/warehouse
• For each, record the direction and trigger: what event fires it, what data it passes, whether it is native, via Zapier/Make, or a custom webhook
• Confirm each integration exists or has an equivalent on the new platform — this is the item most likely to block go-live
• Note which integrations need a new API key or re-authentication and who owns the account for each
• Identify any integration with no equivalent and decide the fallback (manual process, middleware, or drop it) before you commit to the move

Audit reporting

• List every dashboard and scheduled report in use and who reads it — kill the ones nobody opens
• Write down the exact definition of each core metric on the old system: first response time, resolution time, what "solved" means, how reopens count, how business hours are set
• Check how the new tool defines the same metrics — differences here are why your trend line will snap at the cutover date
• Decide how you will preserve historical trend continuity: export old metrics to a spreadsheet/warehouse so the pre-migration numbers survive even if definitions differ
• Confirm CSAT/survey history and response data can be exported or is captured somewhere before the old tool goes away

---

During — cutover

Run this over a low-volume window [a weekend]. The whole phase is: freeze, import, verify, switch, tell everyone. Do not skip the verify step because the import bar turned green.

Map the data

• Build the field mapping sheet: old field → new field, with a decision for every unmapped field (merge, drop, or create new)
• Map statuses (e.g. old "Pending" → new "On hold") and priorities so nothing lands in a default bucket
• Map agents and groups so ticket history keeps the right author and team
• Decide how out-of-scope / archived history is stored and how agents will access it if needed

Test import

• Run a sample import first — a stratified set of [50] tickets covering every type, channel, custom field, and edge case (long threads, attachments, merged tickets, reopened tickets)
• Diff the sample field by field against the source: timestamps, author, notes vs. public, custom fields, attachments — do not trust the "import complete" bar
• Rebuild macros and automations in a staging instance and fire live-shaped test tickets through them; confirm each triggers, routes, and applies SLAs correctly
• Test each integration end to end against its real trigger event, not just a "connected" green light
• Fix mapping errors, then re-run the sample until a clean diff — only then schedule the full import

Cutover plan

• Pick the cutover window and confirm coverage: who is working, who is on call, who can roll back
• Announce a write freeze on the old system so no ticket is created or edited mid-copy; note the freeze start time
• Run the full import; reconcile the ticket counts against the pre-migration export from the Before phase
• Redirect inbound channels: support email forwarding/MX, chat widget, contact-form endpoint, phone/IVR all now land in the new tool
• Set the old system to read-only — reachable for history, impossible to reply from
• Write the rollback plan: the exact trigger to abort, who decides, and how you point channels back — and keep it one click away

Comms

• Tell agents ahead of time: the cutover date, the freeze window, where to log in, and where to find old-ticket history
• Give agents a one-page cheat sheet of what's different (new statuses, where macros live, how to search old tickets)
• Update customer-facing touchpoints: help center URL, "contact us" links, email signatures, status page
• Set an auto-reply / status note for the freeze window if customers might write in during it
• Line up a war-room channel [#migration-cutover] for the first 48 hours so issues surface in one place

---

After — verify, retrain, decommission

The migration isn't done at go-live; it's done when the numbers are trustworthy and the old tool is safely off. Give this a full month.

Verify

• Day 1: confirm every agent can log in, see the queue, reply, and search old ticket history
• Watch the first reopened ticket — does it keep its full thread and customer context?
• Confirm inbound is flowing: send a test email, chat, and form submission from outside and check each lands and routes
• Verify SLAs are timing correctly on live tickets (first response and resolution clocks, pauses, business hours)
• Spot-check macros and automations in production for the first week — the staging test doesn't catch everything under real load
• Rebuild and compare the core dashboards against the last known-good numbers from the old tool; explain any gap before your manager asks
• Confirm integrations fire on real events for a few days (a real call logs, a real order looks up, a real Jira issue is created)

Retrain

• Run a live walkthrough of the new tool for the whole team, not just the cheat sheet
• Cover the things that changed: statuses, where macros/saved replies live, keyboard shortcuts, how to find archived history
• Have a fast-feedback loop for the first two weeks: a channel or standing 10-minute daily where agents flag friction
• Update onboarding docs and the internal KB so new hires learn the new tool, not the old one
• Check handle time and reopen rate week over week — a temporary dip is normal; a sustained one means a workflow gap to fix

Decommission

• Keep the old system in read-only for at least [one quarter] — the history you didn't migrate cleanly is the history a compliance or legal request will need
• Confirm exports are archived somewhere durable: full ticket data, CSAT history, and reporting snapshots
• Cancel the old contract — set a calendar reminder before the renewal date so you don't auto-renew a tool you've left
• Revoke old API keys and integrations and remove the old tool's access to connected systems
• Reclaim seats on any tool whose usage dropped because of the move (the "temporary" second tool, sandbox seats)
• Write a short post-migration note: what broke, what you'd do differently, and the final all-in cost vs. the estimate

---

Go-live gate

Do not announce the cutover to customers until every one of these is true.

The green "import complete" bar is not verification. A field-by-field diff on a real sample is. Everything expensive that goes wrong in a migration is something that looked fine until someone actually checked it.