Switching Help Desks: 8 Practices to Keep Data Safe

Most data lost in a help desk migration is lost by accident, not by a technical failure. Someone cancels the old plan before checking the export. An attachment folder turns out to be empty. A support address keeps forwarding to a mailbox nobody reads. Almost all of this is preventable with a little planning before you touch anything.

These are the practices worth following whether you have two agents or ten.

1. Inventory everything before you choose a cutover date

You can't protect data you haven't listed. Before you plan the move, write down what lives in your current help desk:

• Tickets and full conversation threads (customer messages and agent replies)
• Internal notes and private comments
• Attachments and inline images
• Customer or contact records
• Tags, categories and custom fields
• Saved replies or templates
• Automation rules, assignment rules and SLAs
• Connected email addresses and forwarding setups

Mark each item as "must move," "nice to have" or "leave behind." Rules and automations rarely transfer between tools in a usable form, so plan to rebuild the ones you still need rather than expect them to arrive intact.

2. Decide what actually needs to migrate

Moving everything is not always the goal. Many small teams find that only a slice of their history is useful day to day: open tickets, recent conversations with active customers, and a few templates.

A practical split:

• Move into the new system: open and pending tickets, plus any recent history your agents regularly refer back to.
• Archive: everything else, as a searchable export you can open when someone asks "what did we tell this customer last year?"

Before you commit to a new tool, confirm what it can import. Some tools accept ticket history, some accept only contacts, and some start fresh. Knowing this early keeps you from discovering the gap on cutover day.

3. Export everything first, and keep an untouched copy

Before any migration step, export your data and store the files somewhere safe and separate from both systems. Treat this copy as read-only. If something goes wrong later, it's your fallback.

If you're leaving Freshdesk, How to Export Tickets from Freshdesk Before You Migrate walks through that process. Other tools have their own export options, and the details (formats, limits, what's included) vary, so check your current vendor's documentation.

If you handle customer personal data, your retention and privacy obligations apply to these exports too. Store them securely, and confirm what rules apply to your business and region.

4. Verify the export instead of trusting it

An export that finished without an error message isn't necessarily complete. Spend an hour checking it:

1. Compare the ticket count in the export to the count in your help desk.
2. Open five or ten tickets at random, including some old ones and some long threads, and confirm the full conversation is there.
3. Check that attachments actually exist as files, not just as filenames in a spreadsheet.
4. Confirm internal notes are included, or note that they aren't.
5. Look for garbled characters in names and messages, especially if you have customers who write in languages with accents or non-Latin scripts.

If something is missing, you want to find out while the old system is still fully active.

5. Clean up before you move, not after

A migration is a good excuse to stop carrying clutter. Before exporting for the final time:

• Delete or ignore obvious spam tickets.
• Merge duplicate customer records where you can.
• Collapse a sprawling tag list into the handful you actually use.
• Close tickets that were effectively resolved but never marked as such.

Cleaning first is cheaper than cleaning in the new system, where you'd be sorting through imported mess while also learning a new tool.

6. Map statuses, fields and tags in writing

Two help desks rarely use the same vocabulary. What one calls "Pending" another calls "Waiting on customer," and a custom field in your old tool may have no equivalent in the new one.

Make a simple two-column list: old status or field on the left, new equivalent on the right. Decide in advance what happens to anything with no match (drop it, fold it into a tag, or keep it in the archived export). Doing this on paper takes ten minutes. Doing it mid-migration, with agents waiting, takes much longer.

7. Treat email routing as part of the data

Your support address is the most important thing you're moving, and it's the easiest to break. If customers write to support@yourcompany.com and the forwarding points to the old system after you've switched, messages can land in a place no one is watching.

Before cutover:

• List every address that feeds your help desk (support, billing, sales questions, and so on).
• Note how each one is routed today.
• Decide the exact moment each one will point to the new system.
• Send test emails afterward and confirm each one arrives as a ticket.

This is also a good place to run the two systems side by side. With a tool like NeuraDesk, which is free to start with no credit card, you can set up a trial inbox and confirm that incoming emails convert to tickets the way you expect before you redirect your real support address. Whatever tool you choose, test with a low-stakes address first.

8. Plan for open tickets and a defined overlap period

Open tickets are where migrations hurt customers. A reply sent in the old system after cutover may never be seen, and a customer replying to an old thread may create a duplicate or vanish.

Two approaches work for small teams:

• Drain the queue. Before cutover, resolve as many open tickets as you can, and recreate the few that remain in the new system with a short summary and a link or reference to the archived history.
• Announce a freeze. Pick a cutover time, tell the team that new replies happen only in the new system after that, and assign one person to watch both inboxes for the first few days.

Then keep the old system accessible, read-only if possible, for a set period before canceling. Don't cancel the subscription until you've confirmed your exports are good and that you can still reach your data afterward (some vendors limit access once a plan ends, so check their terms).

After the move: watch for gaps

The first couple of weeks are when small leaks show up: a status nobody uses, a customer who wasn't notified, a conversation that doesn't have its earlier context. Ask your agents to flag anything that feels off rather than working around it quietly.

If you're moving from Help Scout specifically, Moved from Help Scout to a Shared Inbox and Things Are Slipping? How to Find the Cause covers the most common post-move problems.

A good migration is a boring one: a verified export, a written mapping, tested email routing and an overlap period. If you can check those four things off, you've covered most of the risk. When you're ready to test a new inbox without risk, try NeuraDesk free.