Migrate from TestRail: bring cases onto the thread

Moving off TestRail is usually less about rewriting every case and more about where verification evidence lives. The goal is to bring cases onto the same thread as the requirements they verify — not to lose the library your QA team already built.

This guide assumes a destination that imports CSV/Excel with field mapping, such as traceunified.

What to export

1. Test cases — title, steps (action / expected), priority, type, references, custom fields.
2. Suites / sections — preserve hierarchy if your export supports it; otherwise recreate folders in the destination.
3. Historical runs (optional) — many teams keep TestRail read-only for past evidence and migrate the library forward; decide with QA and quality.
4. Jira / requirement IDs — export any external keys you use today so you can re-link after import.

Import pattern that works

1. Map fields (steps, expected results, priority, type) before committing.
2. Import one project’s suite first.
3. Link each case to the requirement it verifies (and risk it mitigates) — on import if IDs align, or in a structured cleanup pass.
4. Prove live coverage and a sample signed run before expanding.

Validation checklist

• Case count and critical suites accounted for
• Steps and expected results intact for a sample of high-risk tests
• Requirement-to-test links for a known subsystem
• Suspect-on-change exercised after an upstream edit
• Part 11 / audit path exercised on a controlled run (if in scope)
• Export path out confirmed

Parallel run

Common pattern: TestRail remains the system of record for in-flight runs for one release; new cases and formal coverage move to the new system. Retire TestRail when coverage views and evidence match your QMS bar.

Related reading

• TestRail alternatives
• traceunified vs TestRail
• TestRail alternative
• Tests module