Zephyr Scale Export: Keeping History and Traceability

A QA lead at a mid sized team knows the feeling. Leadership has decided it's time to leave Zephyr Scale, the export button has been clicked, and a zip file full of CSVs and JSON now sits in a shared drive. Everyone assumes the hard part is over. Then someone asks where last quarter's regression run results went. Or why a test case no longer shows which Jira ticket it verifies. The migration stalls for a week while people dig through the old system by hand. This happens on nearly every Zephyr Scale migration. The export was never the risky part. What happens to run history and traceability links afterward is.

This post walks through what actually comes out of a Zephyr Scale export, what tends to get left behind, and how to plan the move so nothing quietly disappears.

What Zephyr Scale's native export actually includes

Zephyr Scale's export does a solid job with the core of a test case. When you export test cases, you typically get:

• Case fields: name, description, priority, status, and any custom fields you've configured
• Test steps: the step text, expected results, and step level attachments in most export paths
• Folder structure and labels, so the organizational hierarchy is at least partially recoverable

For a straightforward test case library, this is enough to reconstruct the "what should we test" part of your suite in a new tool. A test case management system holds more than case definitions, though. It holds a record of what happened when those cases were run. It also holds the links that prove testing actually covered a requirement. Those two things are where exports get thin.

What commonly gets left behind

Three categories of data are the usual casualties of a Zephyr Scale export. All three are the kind of thing nobody notices missing until an audit or a postmortem needs them.

• Execution and run history: pass or fail results, execution dates, who ran the test, and comments left during a run. Native export often captures the current state of a case, not the log of every run against it over the past year.
• Attachments: screenshots and log files attached to individual test runs, as opposed to attachments on the case definition itself, are frequently not included in a case level export.
• Traceability links to Jira issues: the association between a test case and the requirement or bug it verifies. This link often lives in a separate table in Zephyr Scale's data model, and a straightforward case export can leave it out entirely.

Losing run history means you can't answer "when did we last verify this" without going back to the old system. Losing traceability links is worse. A release sign off process that depends on every requirement having a passing test has no way to prove that. Not even if the tests themselves migrated cleanly.

Picture a team shipping a payment gateway update. Their release checklist cites 40 test cases as evidence the checkout flow was verified against the linked Jira epic. If those 40 links don't survive the export, the sign off has nothing to point to, and someone has to reconstruct the mapping by hand two days before release.

A before you start checklist

Before exporting anything, a QA lead should inventory what the team actually depends on today, not just what Zephyr Scale happens to store. Spend an afternoon on this and the actual migration goes faster.

• List every custom field in use across projects, including ones only one team uses, and confirm each has a mapped destination
• Pull a sample of test cases with attachments and confirm whether case level and run level attachments both need to move
• Identify which test cases are cited in traceability reports, audit evidence, or release checklists, since those are the ones that can't quietly drop a link
• Decide how far back run history needs to go. Six months of history is a very different migration than three years
• Confirm who owns the source system's read access after cutover, in case anyone needs to look something up mid migration

Teams that skip this step tend to discover the gaps during the first release cycle after cutover. That is the worst possible time to find them.

How to preserve traceability links during a migration

The safest approach treats traceability as its own migration task, separate from moving case content. Export the Jira issue key associated with each test case as an explicit field. Sometimes this means a second export pass or a script against Zephyr Scale's API. Once that mapping exists as a simple table of test case ID to Jira issue key, it can be re applied in the destination system regardless of how the rest of the import goes.

It also helps to verify traceability after import, not just trust that it worked. Pick a handful of test cases, ideally ones tied to a real release like the payment flow suite or the checkout regression pack. Confirm the Jira link resolves correctly in the new system before declaring the migration done. A traceability link that silently points nowhere is worse than a missing test case. Nobody notices until an audit asks for evidence.

Tesbo does not offer a one click importer built specifically for Zephyr Scale exports. What it does support is documenting each test case with clear fields and a link back to its source ticket. Once your export is clean and your Jira mapping is confirmed, rebuilding traceability in Tesbo is a matter of importing that mapping rather than reconstructing it from memory.

When a phased or parallel run migration beats a single cutover

Not every team should try to move everything on one Friday afternoon. A single cutover works when the suite is small, maybe under 200 cases, and run history older than a month or two isn't load bearing for anyone. For larger or more compliance sensitive suites, a phased migration is safer.

In a phased approach, one project or one test suite moves first. Both systems stay live for a sprint or two. Testers log results in the new system while the old one stays available read only for historical lookups. This catches mapping problems on a small scale before they hit the whole test library. A QA lead running a 900 case regression suite across three products, for example, might migrate the smallest product first, confirm every traceability link on that 80 case subset, then repeat the process for the rest.

A parallel run, where the same set of test executions gets logged in both tools for a short window, is more work up front. It gives real confidence that nothing about pass and fail behavior changed between systems. Teams under audit or with strict release gates tend to find this worth the extra week.

Getting it right the first time

The export button is the easy part of leaving Zephyr Scale. What separates a clean migration from a painful one is deciding, before you export anything, what run history and traceability data actually matters to your team. Then build a plan to carry it over deliberately instead of hoping it comes along for free.