There are a couple of common reasons to switch help desks. Either the current system no longer fits the way the business works, or the company has acquired another business whose customer service has to be brought onto the same platform. Whatever the reason, you can’t simply switch the old system off. Ticket history, customer data and the macros and automations built up over the years all need to be moved or replaced.

Almost every help desk migration runs into the same three questions: what to move, how to test and time the move, and how to bring people along. If you haven’t picked the new system yet, start with how to choose a customer service platform and come back once the decision is made.

1. Start by mapping out what’s really in the old system

Discovery and scoping are the biggest part of a migration, and they deserve most of your time. Before anything is moved, go through what the old system contains: ticket history, customer and organization data, ticket fields, macros, automations, help center articles and integrations. For each one, decide whether to migrate it, rebuild it or leave it behind.

The most important technical task is data mapping. Every piece of information on an old ticket, such as category, priority, product or customer number, has to land in the right field in the new system. If the mapping is sloppy, data gets mixed up and the new system starts out as a mess.

Ticket numbers change in a migration. Store the old ticket number in its own field in the new system, so a ticket can still be found when a customer or colleague refers to the old number.

Scoping is also the best moment to cut what you don’t need. You don’t have to migrate your entire history. Think about what support agents need in their daily work and what you have to keep, for example for contractual reasons. The rest can be archived separately so it doesn’t weigh down the new system.

Check the old system’s contract at the same time. The data has to be exported before the contract ends, and it pays to have the licenses overlap for a while so you can still get into the old system after cutover. A migration often moves customers’ personal data too, so make sure you have a data processing agreement with the migration tool or partner, and agree when the data will be deleted from the old system once it is no longer needed.

Go through macros and automations one by one. Many were built over the years to patch gaps the new system no longer has, and some haven’t been used in ages. Rebuilding them around your current processes gives you a simpler setup than copying the old one. The same goes for help center articles. A migration is a good moment to turn them into an AI-ready knowledge base, because AI agents, if you roll them out, answer customers mostly based on that content.

2. Test with trial migrations and agree on one clear cutover date

Before the full migration, run one or two trial migrations on a small sample. They show whether the mapping works and whether the sample covers every ticket type and edge case: long threads, attachments, merged tickets and tickets from users who have since left. Open the migrated tickets in the new system and check that they look right. A mistake is far cheaper to fix in a hundred tickets than in a hundred thousand.

After testing, agree on a cutover date. We recommend one clear date. From then on, support agents work only in the new system, and every channel from email addresses to chat is routed there. If two systems run in parallel, agents end up guessing which one to search.

Email is the channel that breaks most often on cutover day. Forwarding has to be switched to the new system, and the new system has to be authenticated to send from your own domain (SPF and DKIM). Otherwise replies may end up in customers’ spam folders.

Something usually still lands in the old system after cutover, such as messages to channels that haven’t been switched yet. Move these over with a delta migration: a smaller run that brings in only the tickets created or updated since the main migration. Agree in advance on what happens if something goes wrong, too: who makes the call, and whether you can still go back to the old system.

Migrated history doesn’t behave like a new ticket

Many teams only notice after the move that migrated history doesn’t behave like a new ticket. In Zendesk, for example, historical tickets are brought in through the Ticket Import API, which keeps the original timestamps. Triggers don’t fire on imported tickets that aren’t closed until the ticket is updated, though, and Zendesk’s metrics and SLAs aren’t supported on them. That is why Zendesk recommends tagging imported tickets and excluding them from reports.

The details vary between systems, but the principle is the same: test your reports during the trial migration as well. Otherwise response times for the first month look either implausibly good or implausibly bad, and they lead to the wrong conclusions.

Mika Mikkola walks through the same three things in this short video.

3. Bring people along early

The technical migration can go without a single error and the project can still fail if support agents can’t or won’t use the new system. Change almost always meets some resistance, and that’s understandable. The old system is familiar, and everyone knows its workarounds by heart.

Everyone who uses the new system needs to be on board: the admins who maintain it, the team leads who run the team and read the reports, and the support agents who do the actual work. Train each group for its own tasks before cutover, not after. Bring a couple of agents into testing early, too. They find the practical problems fastest.

After cutover, plan for a hypercare period: a few weeks of extra support during which questions get answered right away and small fixes go in quickly. That way nobody is left alone with the new system just when customers still expect the usual service.

Who does the migration?

There are three routes: do the migration yourself through the APIs, buy it from the system vendor or a certified partner, or use a ready-made migration tool. The right route depends on how much data you have and how much mapping and testing the move requires.

Whichever route you take, the hardest part stays the same. An API or a tool moves the data, but someone has to decide what gets moved, into which fields and when, and make sure cutover day goes to plan. If you do it in-house, you’re usually making these decisions for the first time. An experienced partner also knows the edge cases that otherwise only show up halfway through the migration.

Planning a help desk migration?

Zennius is an AI Expert certified Zendesk partner, and our team has been building Zendesk environments for clients for years. We help with migrations from discovery all the way to hypercare.

Want to go through what’s worth moving from your current system? Get in touch and let’s plan the migration together.