Every migration has the same moment of doubt. You have an export from the old system, a new system that says it can import it, and no idea what will actually be in there when the progress bar finishes. The instinct is to import everything and sort it out afterwards, which is exactly how a queue ends up with eight hundred tickets that have a subject and nothing else.
MyLiveChat has three CSV importers, and they are built around the opposite instinct: look before you commit. This guide covers what each one does, the single column that determines whether you can safely run the same file twice, and the fields that quietly do not survive the trip.
Three importers, one shape
There are separate importers for tickets, for knowledge base articles and for macros, and all three follow the same shape: choose a source platform or let it be detected, pick a file, review a preview, then commit.
The ticket importer understands exports from Zendesk, Freshdesk and LiveAgent, and can also detect which of those it is looking at from the header row alone. Detection works by scoring the header against the column names each platform is known to use, so an export you renamed or trimmed may score too low to be recognised. That is not a failure state; it just means you pick the platform yourself from the dropdown.
The knowledge base importer reads Zendesk Guide article exports, Freshdesk Solutions exports, and any generic two-column file with a title and a body. The macro importer takes the same generic shape, so a spreadsheet of your existing canned replies is a valid input even if it never came out of a help desk at all. That last point is worth knowing, because plenty of teams keep their standard replies in a document rather than a tool, and there is no need to invent a fake export to bring them in.
Each import writes an audit row, and the most recent runs are listed under the form with their counts and status. That log is the record of what you did, and it is the first thing to look at when somebody asks two weeks later where a batch of tickets came from.
Always run the preview
The preview is a real dry run, not an estimate. The file goes through exactly the same parsing and column mapping that a commit would use, with writing switched off, and you get back four counts, a sample of the first rows as they would be created, and the first few parse errors with their row numbers.
Read the counts as a set rather than individually. Total is how many data rows were found, which is the first thing to sanity-check against what you exported: a total of one usually means the file is delimited differently than expected. Imported is how many would be created. Skipped covers rows deliberately passed over, most often duplicates or rows with no subject at all. Failed is rows that could not be parsed, and those are the ones the error samples describe.
The sample table is the part people skim and should not. It shows the mapped result, not the raw file, so it is where you discover that the requester name landed in the email column or that the description is empty because your export put the body somewhere unexpected. Fixing a column mapping means fixing the export and previewing again, which takes two minutes; fixing it after a commit means deleting several thousand tickets by hand.
The one column that makes a re-run safe
Duplicate protection is keyed on three things together: your site, the source platform, and the original record identifier from the export. If a row with that combination has already been imported, it is skipped rather than created again.
The consequence is direct and worth reading twice. If your export has no identifier column, there is nothing to key on, and every row is treated as new. A file imported twice becomes two copies of everything. This is the single most expensive mistake available in this part of the product, and it is entirely avoidable: before exporting, confirm that the identifier column is included, and confirm in the preview that the sample rows show a value in it.
When the identifier is present, re-running becomes a normal operation rather than a risk. A run that stopped halfway can simply be repeated, and the rows that already exist are skipped. An export that has grown since you last imported can be re-imported to pick up only what is new. That property is what makes it reasonable to migrate in small batches rather than one heroic file, which is the approach almost every successful migration ends up taking anyway.
What comes across, and what does not
Being precise about this is kinder than being optimistic, because the gaps are the things people discover at the worst possible moment.
For tickets, what transfers is the subject, the status, the priority, the requester name and email, the tags, and the description. The description becomes the first message on the ticket, attributed to the requester rather than to an agent, so the thread reads correctly from the top. Imported tickets are marked as having arrived through import, which means you can tell them apart from anything your team or your visitors created afterwards.
What does not transfer is the rest of the conversation. A CSV export from a help desk typically contains the first message and nothing else, and the importer maps what the file contains. Attachments do not come across, because a CSV does not carry them. Agent assignment does not come across. Internal notes and the full comment history do not come across. Nor does the original creation date become the ticket's own timeline; the imported record is created now, with its history noted rather than reconstructed.
This is the point at which to decide what the import is for. If the answer is searchable historical context, a subject-and-first-message record is often enough, and the old system's archive can stay read-only somewhere for the rare deep lookup. If the answer is a complete legal record of every exchange, a CSV import is not the mechanism, and you should plan a proper archive export instead. Deciding this before you migrate is what stops the conversation from being had again, with more heat, three months later.
How statuses and priorities are translated
Different platforms name the same states differently, so each preset carries its own translation.
From Zendesk, new and open both become open, pending and hold become pending, solved becomes resolved, and closed stays closed. From Freshdesk, where the export is numeric, the numbers are mapped to the same four states, and the numeric priorities are mapped to low, normal, high and urgent. From LiveAgent, answered maps to pending, which is usually what a team means by it.
Anything unrecognised falls back to open for status and normal for priority. That fallback is deliberately safe rather than clever: a ticket that should have been closed and arrives open is visible and can be closed in a second, while a ticket that should have been open and arrives closed is invisible and stays that way. Still, it is the thing to check in the preview, because a status column full of values none of the presets recognise turns your entire history into an open queue on Monday morning.
What status imported articles land with
This is the detail most likely to surprise you, so read it before you import a help centre rather than after.
Imported articles carry their source status across when the importer recognises it. A row whose status says published or live becomes visible, which means it is publicly readable the moment the import finishes. A row marked archived or hidden becomes hidden. Everything else, including a status the importer does not recognise and a file with no status column at all, falls back to draft. So draft is the safe default, not a blanket rule, and an export straight out of a live help centre will mostly not take it.
That matters because a help centre export is usually a mix of current articles, half-finished ones, and pages that only made sense inside the old product. If you want to curate before anybody reads them, take the decision deliberately: blank or remove the status column before importing so every row lands as a draft, or check the preview, which shows the status each row would be created with, and be sure you are happy for those to go live today.
Either way the flow that works is import, curate, publish. Sort by whatever matters to you, delete the ones that no longer describe your product, fix the ones whose screenshots refer to a different interface, and publish the rest deliberately. It takes longer than a single button, and it is the difference between a help centre and a pile of files.
There is a second reason to curate before publishing. Imported articles can also become material for your AI assistant, and an assistant trained on stale content will confidently repeat it. The judgement in training your AI on your own content applies directly here: an import is a source of candidates, not a source of truth.
A sane order to do it in
Import macros first. They are small, they are immediately useful to agents, and they let your team work in the new tool from day one even while everything else is still in flight.
Import knowledge base articles second, with the status column decided one way or the other, and start curating while the rest of the migration proceeds. This is the part that takes real human time, so beginning early is worth more than doing it in the right order.
Import tickets last, and in batches. Start with a fifty-row export to prove the mapping, then the last quarter, then further back if you need it. Historic tickets are the least urgent thing in a migration and the largest volume, which is exactly the combination that suits an incremental approach. The wider sequencing, including what to do about the old system's widget and your saved replies, is covered in migrating from another live chat provider, and the knowledge base overview shows what the articles become once they are in.
One warning worth carrying across: the contact importer does not deduplicate the way these importers do, as covered in keeping your contact list clean and deduplicated.