How to Export, Clean and Import Customer Support Data When You Switch Help Desks
A practical checklist for moving contacts and ticket history between help desk tools: what to export, how to clean CSV and JSON files with free tools, and how to test the import before cutover.
Contents
Switching help desk software is rarely blocked by the new tool. It is blocked by the data: contact lists with duplicates, ticket exports in a shape the new importer does not accept, and a long tail of macros and tags nobody wrote down. This guide walks through a safe order of work so that you move what you need, clean it once, and test before anyone depends on the new system.
What should you move, and what can you leave behind?
Start by splitting your data into four groups, because each one behaves differently.
- Contacts and organizations. Almost always worth moving. These are the records agents look up every day.
- Open tickets. Move or finish them before the cutover date. Mid-flight conversations are the hardest thing to split across two systems.
- Closed ticket history. Move only what agents will actually search. Many teams keep the old system read-only for a few weeks instead of importing years of history.
- Configuration. Macros, canned replies, tags and automation rules usually cannot be imported and need to be rebuilt by hand. List them now so nothing is forgotten.
Step 1: Export from the old system
Most help desks let an admin export contacts and tickets as CSV, JSON or both. What each export includes differs by vendor and plan, so read the vendor's export documentation first and write down what is missing, for example attachments, internal notes or custom fields. Export a small sample first and open it before you request the full dataset.
Step 2: Look at the shape of the file
CSV is flat: one row per record, one column per field. JSON is nested: a ticket can contain a list of comments, each with its own author and timestamp. Importers usually want one of the two, so you may need to convert. UrwaTools has a free JSON to CSV converter and a CSV to JSON converter. If your JSON is deeply nested, the JSON flattener turns nested keys into single-level column names first, and the JSON formatter makes a messy export readable so you can spot problems by eye.
Step 3: Clean the contact list
This is where most imports go wrong, and where a few minutes of work pays off.
- Remove duplicates. If you can export a column of email addresses, the duplicate lines remover collapses repeats quickly. Decide which record wins before you delete anything, because the newer record is not always the better one.
- Check email addresses. Run suspicious entries through the email validator to catch typos and malformed addresses that would bounce or fail import.
- Normalize names. Mixed capitalization such as ALL CAPS and all lower case looks careless in agent replies. The case converter fixes this in one pass.
- Check for stray columns. Delete columns you do not plan to map. A smaller file is easier to review and less likely to hit row or size limits.
The same ideas are covered with a CRM example in the guide to cleaning a lead list before importing it into a CRM, and the habit of cleaning the export before importing it applies equally to moving tasks between work management tools.
Step 4: Map fields and test with a small batch
Open the new tool's import screen and compare its required fields with your columns. Typical points of failure are date formats, required fields that are empty in some rows, and status or priority values that the new system names differently. Import 20 to 50 rows into a test or sandbox space if the vendor offers one, then check:
- Do names, emails and organizations land in the right fields?
- Are dates and time zones correct?
- Do ticket threads keep their order, and are internal notes still internal?
- Did any characters turn into question marks? That usually points to an encoding problem, so save the file as UTF-8.
Step 5: Plan the cutover
Pick a low-traffic window, announce it to customers if your support address will change, and forward the old address to the new one. Keep the old system read-only for a defined period, such as 30 days, so agents can still look up history. After that, archive a final export somewhere safe. Check any legal or contractual retention requirements for support records before you delete anything, especially if tickets can include health or payment information.
Choosing the new tool before you migrate
Data migration is much easier when you know which tool you are moving to, because you can read its importer requirements first. If you are still deciding, ProductListo's comparison Best Zendesk Alternatives in 2026 covers pricing and AI agent billing for Help Scout, Front, Intercom and Freshworks, and ProductListo's Communication guide lists the other support and messaging tools it has profiled. Makers of customer support tools can submit a tool to the ProductListo directory, and sponsored placement options are described on its write for us page.
A short pre-migration checklist
- Export a sample and open it before exporting everything.
- Write down what the export does not include.
- Convert between CSV and JSON only as many times as needed.
- Remove duplicates, validate emails and normalize names.
- Import a small test batch and check it field by field.
- Keep the old system read-only after cutover and archive a final export.
Frequently asked questions
Can I import my old ticket history into any help desk?
Should I convert my export from JSON to CSV?
How do I remove duplicate contacts before importing?
How long should I keep the old help desk after switching?
The UrwaTools Editorial Team delivers clear, practical, and trustworthy content designed to help users solve problems efficiently. Our articles focus on accurac...