Migration is a chance to delete, not just copy

Most helpdesk migrations fail in the same way: the team treats it as a lossless copy job. They try to drag every closed ticket, every dead macro, and every never-used custom field into the new system, then spend three weeks reconciling data nobody will ever look at.

A migration is the one moment you get to throw things away with permission. Closed tickets older than a year are reference material, not live data — export them to cold storage and don't import them. The half-built workflow nobody trusts? It dies here. Go in with a deletion mindset and the whole project gets smaller.

Decide what actually has to move

There are only four things you genuinely need on day one:

  1. Open and pending tickets. These are live conversations. Dropping one means a customer gets ignored.
  2. Contacts and organizations. Without these, every migrated ticket is an orphan.
  3. Your knowledge base. Articles are slow to rewrite and high-value. Move them.
  4. Macros and SLA policies you actually use. Audit usage first — in most teams a third of macros are dead.

Everything else (closed-ticket history, attachments older than a year, custom fields nobody fills in) is nice to have, and "nice to have" is what blows the timeline. Archive it; don't migrate it.

The export gotchas, by source

  • Zendesk: ticket comments come back as separate API objects from the ticket itself. Pull both, and preserve the public/private flag — internal notes leaking to customers is the classic migration disaster. Tags are flat strings; map them to your new type/category model deliberately.
  • Freshdesk: "status" and "priority" use numeric IDs, not labels. Build the lookup table before you import or you'll land everything as "Open / Low."
  • Jira Service Management: issues carry a heavy custom-field payload and a workflow that rarely maps one-to-one. Flatten aggressively. Your new configurable workflow doesn't need to mirror Jira's twelve states — pick the four that mean something.

In all three, threaded conversation order is the thing reviewers check first. If replies land out of sequence, agents lose trust in the migration on day one.

Preserve the conversation, not the schema

The number one rule of a helpdesk migration: the customer should never have to re-explain themselves. The same principle that governs a good escalation workflow governs a migration. When an open ticket lands in the new system, the full timeline — every reply, in order, with the right public/private flags — has to come with it.

You do not need to reproduce the old system's field schema exactly. Map the source fields onto your new model once, in a spreadsheet, before you write a line of import code. Resist the urge to recreate every legacy custom field "just in case." Each one you keep is a field someone has to maintain forever.

Run it in three passes

Don't attempt a single big-bang cutover. Stage it:

  1. Dry run into a sandbox workspace. Import a representative slice — 200 tickets across every type and status — and have two agents actually work them. You'll find the threading bugs and the status-mapping mistakes here, where they're cheap.
  2. Full historical load while the old system is still live. Bring contacts, KB, and closed tickets across in the background. Nobody's cutover depends on it, so it can take its time.
  3. Open-ticket cutover in a freeze window. Pick a low-volume window (Friday evening is the classic). Freeze the old system to read-only, migrate the open/pending queue, point inbound email at the new address, and go.

The cutover checklist

  • Redirect inbound email to the new system's email-to-ticket address — and keep the old address forwarding for at least 90 days. Customers reply to old threads for months.
  • Update every embedded link: the contact form, the help-center widget, the "submit a ticket" button in your app.
  • Re-point your chat widget if you run live chat. A widget still talking to the dead backend is invisible to your team.
  • Verify SLA clocks started. A migrated open ticket with no running SLA timer is a silent breach waiting to happen.
  • Keep the old system read-only for 90 days. It's your reference and your rollback. Don't cancel the contract the day after cutover.

Tell customers as little as possible

Internally this is a huge project. Externally it should be invisible. Customers don't care which helpdesk you run — they care that their open ticket still works and their replies still reach a human. If you've done the migration right, the only thing they notice is the new address on the autoresponder. A migration the customer never noticed is the only kind that succeeded.