How to Export Test Cases From TestRail: The Export, Map, and Verify Playbook

Most QA leads who search for how to export test cases from TestRail have already made the call. The renewal is coming up. The team is tired of a suite that only one person understands. Or the last audit took three days longer than it should have because run history lived in three different exports. Nobody needs another article arguing that TestRail is wrong for them. What they need is the mechanical part done right: get 1,400 test cases and two years of run history out cleanly, without losing the one field that later turns out to matter. This is that guide. It covers exporting, what to check in the file before you trust it, how to map fields with no clean equivalent, and how to prove afterward that the move actually worked.

Exporting from TestRail without losing structure

Check TestRail's own export documentation on the day you do this, not from memory. Export formats and available fields have changed across TestRail releases. A guide written a year ago may reference a menu path that has moved. As of this writing, TestRail supports CSV export per test suite from the Test Cases view. There is a separate export path for test runs and results if you need history alongside the cases.

Export suite by suite rather than all at once. A single combined export is harder to inspect. It is also harder to re run if something goes wrong halfway through. If your project has 12 suites, budget time for 12 exports and 12 checks, not one afternoon.

Before you close TestRail, note two things. Write down the total case count per suite from the TestRail UI itself. Also list any custom fields your team added over the years. Those custom fields are the ones most likely to go missing quietly.

What to inspect in the exported file before you import anything

Open the CSV in a spreadsheet tool before it goes anywhere near an importer. Three things go wrong here more often than anything else:

• Steps and expected results collapse into a single cell with embedded line breaks, which some importers split incorrectly.
• Custom fields export as blank columns if TestRail's export settings did not have them selected, and this is easy to miss on a quick scan.
• Rich text formatting, such as bold text, numbered sub steps, or embedded images, often reduces to plain text or a broken image reference.

Count the rows against the case count you noted in TestRail. If the file has 1,380 rows and TestRail showed 1,400 cases, stop. Find the missing 20 before you do anything else. They are usually cases inside a nested suite folder that the export did not walk into.

Mapping fields, priorities, and statuses

This is the step where most of the actual decisions live. It deserves a full pass before you import a single case.

• Map priority values directly where the scales match, since Critical, High, Medium, and Low usually translate cleanly.
• Map custom statuses to the closest equivalent. Write down anywhere the meaning shifts even slightly, so a tester six months from now does not assume they mean the same thing.
• For custom fields with no equivalent on the receiving side, decide case by case whether to fold the value into the case description, drop it, or request a custom field be added. Do not silently drop something a compliance reviewer might ask about later.
• Map the folder or suite structure to whatever grouping concept the new tool uses. Do this before import, since re parenting 1,400 cases by hand afterward is a bad way to spend a week.

A concrete example: one team migrating a 900 case regression suite found 40 cases tagged with a custom "Regulatory" field TestRail did not export by default. They caught it only because the row count came up short by exactly 40, which is why the count check matters more than it sounds like it should.

Verifying the import actually worked

An import that completes without an error message is not the same as an import that worked. Verify with counts first.

The number of cases per suite in the new system should match what you counted in TestRail. Check suite by suite, not just in total.

Then spot check by hand. Pick 15 to 20 cases spread across different suites. Include at least a few with custom fields and at least a few with long step lists. Open them side by side with the original TestRail record. Check that steps are in order, expected results are attached to the right step, and priority landed where you mapped it.

Finally, check for silent truncation. Some importers cut off very long descriptions or step text at a character limit without warning. A case that looks fine in a quick scan can be missing its last two steps.

Run history and attachments, stated plainly

Here is the honest part. Historical run results, meaning who executed which case on which build and what the outcome was, generally do not carry over cleanly into a new system. Run data is tied to the structure and IDs of the tool that produced it.

Most teams archive the TestRail run history as a read only export, kept for audit purposes. They start fresh run tracking in the new tool from migration day forward.

Attachments, such as screenshots or log files attached to a case or a run, are similarly uneven. Some export formats keep a link to the original file. Some do not include the binary at all. Check this specifically for any case tied to a regulatory or compliance requirement, since those are the attachments someone will ask for by name later.

The import from TestRail into another tool is not lossless. No honest migration guide will tell you otherwise. What you can control is exactly which pieces you keep, which you archive, and which you knowingly leave behind.

After the move

Once cases are in and verified, resist the urge to import run history data just because it is technically possible. A messy partial history is worse for a team's trust than a clean cutover with an archived old system available for reference. Keep the TestRail export files for at least one audit cycle. Then decide whether to keep the license active for read only access or let it lapse.