Test tool migration to Zephyr — with your history intact

The problem with a standard export

Whatever's driving your change of tool, the destination decision is usually the easy part. The hard question is the one that follows: what happens to ten years of test cases, results and evidence when you get there?

Every tool has an export button, and Zephyr has importers. Between them they may move your test case titles, steps and folder structure — and quietly leave behind almost everything else. Execution history. Step-level results. The cycles and plans that gave those results context. Attachments, at both the case and the execution level. The links between tests, defects and requirements that make your coverage traceable.

For some teams that's an acceptable loss. Most of our customers are the other kind: the execution evidence is precisely what they need to keep — proof that testing happened. For one, it was the evidence that safety-critical hardware had been tested. A migration that drops that isn't a migration, it's an amnesty for your audit trail.

What we migrate

Our own migration tooling was built for precisely this gap, and it has evolved over the years: from scripts into an adaptor-based architecture with a database at its core. The adaptors are why we can extend it to new sources; the database is why we can tell you exactly what moved. A typical engagement moves:

• Test cases with folder structure, custom fields and versioning
• Test cycles and plans, preserved as execution context
• Execution history, including step-level results
• Attachments at case and execution level
• Defect links and requirement traceability

Every run produces reconciliation counts — source objects against migrated objects, by type — so "everything came across" is a number you can check, not a reassurance you have to take.

How we know it works

We've been moving test data into Zephyr since 2016 and work closely with the Zephyr team. Engagements run from single-team moves to enterprise programmes — the tooling and the reconciliation are the same at every size; only the plan and scope change. What gets moved, and how big the engagement is, depend on what you need.

How an engagement runs

1. Fixed-price assessment. We inventory your source data — projects, cases, cycles, executions, attachments, links — and produce a mapping specification plus a detailed estimate and timeline for the migration itself. The assessment is fixed-price; the migration is estimated rather than fixed — variables like third-party vendor APIs sit outside anyone's control, and we'd rather give you an honest estimate than a padded number dressed up as certainty. The pilot in step 2 is where that estimate meets reality before you commit.

2. Pilot migration. We migrate a representative project into a Zephyr sandbox. Your team verifies it against the source — structure, results, attachments, links — before anything else moves.

3. Planned migration with reconciliation. The full estate moves to a plan, not in one big bang: source and destination APIs are rate-capped, so we sequence the migration around your estate's size, number of teams, complexity and scope — and the plan comes out of the assessment, so you see the sequence before anything moves. At the end you receive the reconciliation report: counts by object type, exceptions listed and explained.

4. Cutover support. A short freeze window on the source tool, final delta migration, and your teams carry on in Zephyr — history and all.

Frequently asked questions

Can you really migrate execution history, not just test cases?

Yes — that's the point of the tooling. Executions come across with their results, step outcomes, execution-level attachments and cycle context. It's the part standard importers don't attempt.

We're on TestRail. What maps to what?

Suites and sections become Zephyr folder structures; runs and plans become cycles and plans; results carry across with their status history. Custom fields are mapped in the assessment, so nothing is silently dropped.

We're on Xray. Can you migrate us?

We haven't run Xray through the tooling yet — but it's a natural extension: Jira-native like TestRay, so the Jira issues stay put and the test repository is the work. Extending our tooling to a new source pair is exactly the engineering we do; the assessment scopes your pair specifically. Ask us.

We're on TestRay (formerly SynapseRT). Can you migrate us?

Yes. TestRay is Jira-native, so as with Xray your Jira issues stay where they are; the test repository — cases, suites, cycles, executions and their history — migrates with the same method and the same reconciliation report. Server-era SynapseRT we haven't run yet — ask us; we'd prove it against your estate first, which is exactly what the pilot step is for.

We're leaving RQM. It's old. Can you even get the data out?

The honest general answer for any legacy source, RQM included: we haven't run it through the tooling yet, and old systems are a scoping question, not a dealbreaker — extracting from ageing APIs and databases is exactly what the adaptor model exists for. Ask us: we'd scope it in the assessment, requirement traceability on the list, and prove it with a pilot on your estate.

Why is the migration estimated rather than fixed-price?

Because no two Jira estates are wired the same. Test data lives across two API surfaces — Jira itself and the apps on top of it — and Jira's configurability means the meaning of your data partly lives in how your team used it: we regularly find required information loaded into Epics, for instance, which the migration has to walk up and retrieve. So the traversal is customised to your setup, and pretending otherwise would just be a padded price. The assessment — which is fixed-price — is where we map your specific structure and turn the unknowns into a real estimate.

Will testing have to stop during the migration?

Only briefly. The bulk migration runs while your team keeps working; cutover needs a short freeze window for the final delta, agreed in advance and measured in days, not weeks.

Book a fixed-price migration assessment — you'll get a full inventory of your source data, a mapping specification, and a detailed estimate and timeline for the migration.