Tickets Missing After Help Desk Migration? Causes & Fixes

You opened the new help desk expecting your support history to be there. Instead, some tickets are missing, others show today's date, conversations are flattened into one long message, or the same customer appears three times. Before you re-run anything, work out which kind of failure you have. Most transfer problems come from a handful of causes, and each leaves a recognizable pattern.

Start with one habit: pick five tickets you know well (an old closed one, a recent open one, one with attachments, one with many replies, one from a customer who wrote in several times) and check those specifically. They give you a quick way to test each fix below.

1. The export was incomplete

This is the most common cause. The new system can only import what the old one handed over.

How to confirm: Compare counts. Check how many tickets the old system shows in total, then how many rows are in your export file. If the export is short, the problem is upstream of the import. Also look at whether the missing tickets share something: a status (often closed or archived), a date range, a particular inbox or group.

How to fix it:

• Re-run the export with no filters, or with filters you have checked deliberately.
• Look for export limits, such as a maximum number of rows per file or per day, and export in batches by date range if needed.
• Check whether closed, archived, spam or deleted tickets are excluded by default.
• Make sure the person exporting has permission to see every inbox and group. Some exports only include what the exporting user can see.

If you are coming from Freshdesk, How to Export Tickets from Freshdesk Before You Migrate covers the export side in more detail.

2. The file format or encoding broke on the way in

Symptoms: Rows are skipped, tickets stop partway through the file, accented or non-Latin characters turn into strange symbols, or a ticket's text is cut off at a comma or line break.

How to confirm: Open the file in a plain text editor, not just a spreadsheet. Look for the first row that goes wrong. Often a single ticket with an unusual character, a quotation mark or a long multi-line message is where the damage starts.

How to fix it:

• Save the file as UTF-8 if the destination supports it.
• Avoid re-saving the CSV in a spreadsheet app if you can. Spreadsheets can alter dates, strip leading zeros from order numbers and change quoting.
• Check that multi-line message bodies are wrapped in quotation marks, and that quotation marks inside them are escaped correctly.
• Split the file into smaller pieces so one bad row does not take down a whole batch, and so you can find the bad row faster.

3. Fields were mapped wrongly or not at all

Symptoms: Every ticket arrives as "open" or "new", priorities are gone, tags vanish, assignees are blank, or custom fields (order number, plan type) are empty.

How to confirm: Look at the value in your export (for example "Pending" or "Waiting on customer") and compare it with the statuses available in the new system. If the new tool has no matching value, the import will usually drop it or fall back to a default.

How to fix it:

• Write a simple mapping list before importing: old status to new status, old priority to new priority, old agent to new agent.
• Simplify where the two systems differ. Merging three old statuses into two new ones is fine if you decide it on purpose.
• If a custom field has no home in the new system, put it in a tag or at the top of the ticket text so the information is not lost.
• Make sure agents exist in the new system before importing, otherwise assignments often cannot be applied.

4. Customers were duplicated or merged incorrectly

Symptoms: One person appears under several records, or two different people share one record and see each other's history.

How to confirm: Search for a customer who wrote in from more than one address, and for a shared address such as info@ or a company's general inbox. These are where matching usually goes wrong.

How to fix it:

• Check which field the importer uses to match people (usually email address) and clean that column first: trim spaces, fix capitalization, remove obvious typos.
• Decide how to treat shared addresses. Several real people writing from one mailbox will often be treated as a single customer.
• Do cleanup before the import where you can. Merging after the fact is slower and harder to undo.

5. Attachments and inline images did not come with the text

Symptoms: Tickets show the conversation, but screenshots, invoices or PDFs are missing, or appear as broken links.

How to confirm: Open one ticket you know had an attachment in the old system, then check the export. Many exports contain only links to attachments rather than the files themselves, and those links can stop working once you close the old account.

How to fix it:

• Download attachments in bulk from the old system before cancelling it, if it offers that.
• Keep the old system on a read-only or lower plan until you have confirmed what you need is accessible.
• Decide which attachments really matter (recent open issues, warranty or billing documents) and store those separately, rather than trying to move everything.

6. Dates, order and conversation threads got scrambled

Symptoms: Old tickets look new, replies appear out of order, or a thread with ten messages becomes ten separate tickets.

How to confirm: Check whether the created date on an old ticket reflects the original date or the import date. Then check whether your export has one row per ticket or one row per message.

How to fix it:

• Confirm the date format (day/month versus month/day, time zones) matches what the destination expects.
• If the export has one row per message, make sure there is a ticket identifier column that groups messages together, and that the importer is told to use it.
• Accept some loss of fidelity. Many imports will not preserve private notes versus public replies, and that is worth knowing before you start.

7. You imported the same data twice

Symptoms: Everything appears in duplicate, often after a failed first run that you retried.

How to confirm: Search for a single known ticket. Two copies with identical content point to a repeated import.

How to fix it: If the destination has a way to undo or delete an import batch, use it. If not, clear out the test data and run a clean import. Test with a small batch first next time. A free tool is handy here, since you can try a trial run without entering a credit card. NeuraDesk, for instance, is free to start, so a small test costs nothing but time.

If nothing worked

Sometimes the honest answer is that a full-fidelity transfer is not realistic, especially between tools with very different structures. A few practical fallbacks:

• Contact the support team of the new tool. Send them your file, the error message and the exact ticket that failed. They see import issues regularly and may spot something quickly.
• Move only what you need. Open tickets and the last few months of history matter most. Older tickets rarely need to live inside the new system.
• Archive the rest. Keep a full export (CSV, PDF or a read-only account) somewhere safe and searchable, so you can look up an old order or complaint when needed.
• Recreate the critical few by hand. If only a dozen open tickets matter, copying them across manually is faster than debugging a broken import.
• Run both systems for a short period. New conversations go to the new inbox while the old one stays available for lookups.

If the move itself is leaving gaps in how your team works, Moved from Help Scout to a Shared Inbox and Things Are Slipping? How to Find the Cause covers the process issues that often show up right after a migration.

The quickest path is usually the same each time: compare counts, test five known tickets, fix one cause, then retry with a small batch before moving the rest. If you need a free place to test a small import first, try NeuraDesk free.