Jira Test Management Migration: Xray and Zephyr to AIO Tests

Switching test management tools is not just a matter of moving test cases. QA teams also need to preserve execution history, requirement links, defects, folder structures, attachments, and custom fields that still support reporting, traceability, and release decisions.

A successful Jira test management migration starts with deciding what must move, how source data should map to the new system, and how the migrated repository will be validated before cutover. For teams moving from Xray or Zephyr, AIO Tests supports test case migration and provides APIs for execution data.

This guide walks through the practical steps to audit your current repository, map test assets, migrate cases and historical executions, verify traceability, and complete the transition without losing the QA context your team still depends on.

What Does “Without Losing Test History” Actually Mean?

A successful Jira test management migration should preserve more than test-case titles. Teams need enough historical context to understand what was tested, how it was organized, what happened during execution, and which Jira requirements or defects were connected to the results.

Test Cases and Repository Structure

Preserve the core test assets your team still relies on, including:

• Titles, descriptions, preconditions, steps, and expected results
• Priorities, statuses, and test types
• Folder hierarchy and custom fields
• Classic and BDD/Gherkin cases
  
  

Requirements and Defect Traceability

Important relationships should remain intact wherever possible:

Jira Requirement → Test Case → Execution → Defect

Losing these links can make historical coverage and defect analysis much harder.

Historical Execution Data

Execution history may include previous runs, statuses, cycles, execution dates, defects, comments, and evidence. The platform supports migrating execution data through APIs, including backdated runs.

Attachments and Version History

Xray migration can include test cases, attachments, and execution data. For Zephyr, migration scope should be confirmed based on the chosen method.

Before You Migrate: Audit Your Existing Xray or Zephyr Repository

A clean migration starts with knowing exactly what exists in the current repository. Before moving anything, audit the Xray or Zephyr environment and decide which test assets are worth carrying into the new test management setup.

Identify the Test Assets That Need to Move

Create an inventory of:

• Active and archived test cases
• Folder structures and test groupings
• Test plans, cycles, and execution results
• Custom fields, statuses, and priorities
• Requirement and defect links
• Attachments and user references
• BDD/Gherkin and automation-related test assets

This inventory becomes the baseline for later migration validation.

Separate Active, Historical, and Obsolete Data

Classify test assets into three groups:

• Active: Still used in regular testing
• Historical: Needed for audits, reporting, or reference
• Obsolete: No longer useful

Not every old test should become part of the new active repository.

Clean the Repository Before Migration

Remove duplicate cases, outdated scenarios, unused folders, invalid field values, and old user references where possible.

This reduces unnecessary migration work and prevents existing repository issues from being recreated in the new testing environment.

Map Xray and Zephyr Data to the AIO Tests Structure

Before migrating, map each source-system object to the closest structure in the destination platform. Xray, Zephyr, and the tool organize test data differently, so assuming a direct 1:1 match can create gaps.

Xray to AIO Tests: What Requires Mapping?

‍

Xray Test Plans need particular attention because the platform does not use the same standalone Test Plan entity. Teams should determine whether their existing planning structure is better represented through Sets, Cycles, folders, or release-related workflows.

Zephyr to AIO Tests: Define the Mapping First

For Zephyr, review how test cases, folders, cycles, executions, statuses, custom fields, requirements, and users should map into the Jira test management tool.

Treat this as a migration design exercise rather than assuming every Zephyr object has an identical structure in the test management platform. Clear mapping upfront helps reduce restructuring and cleanup after import.

Step 1: Back Up Your Existing Test Repository

Before starting the test case migration, create a complete backup of the Xray or Zephyr repository. This gives you a recovery point and a reliable source for checking whether important data was transferred correctly.

Capture:

• Test case exports
• Folder and repository structure
• Historical execution records
• Attachments
• Requirement associations
• Defect links
• Custom-field definitions
• User references

Keep the original system accessible until migration validation is complete. If cases, executions, or relationships are missing in the Jira test management tool, the source repository can be used for comparison and recovery.

The backup also supports final reconciliation, allowing teams to compare source and destination records before making the test management platform the active system of record.

Step 2: Configure the AIO Tests Project Before Importing Cases

Set up the destination before moving data. Review and configure:

• Case statuses and priorities
• Case types
• Custom fields
• Folder structure
• Permissions
• Relevant Jira project settings

Custom fields must exist in the platform before import, since only existing fields appear in the mapping screen. Statuses, types, and priorities work differently. Matching names are assigned automatically, so creating them upfront removes most of the mapping work.

Step 3: Create the Field and Value Mapping

The import runs three mapping stages. Field mapping matches your columns to AIO fields, data mapping matches the values inside them, and user mapping matches people across the two systems.

Review fields such as:

• Status
• Priority
• Case type
• Custom fields
• Folder
• Requirement reference
• User

For example, source priority values such as Highest, High, Medium, and Low may need to map to the platform values such as Critical, High, Medium, Low, and Lowest.

Document these mappings before import so the same rules are applied consistently across the repository.

Step 4: Migrate Test Cases and Repository Structure

Once the mapping is ready, begin the test repository migration.

Focus on preserving:

• Test titles and descriptions
• Steps and expected results
• Folder hierarchy
• Statuses, priorities, and types
• Supported custom fields
• Requirement mappings
• Classic or BDD/Gherkin cases

The platform supports Excel, CSV, and BDD imports, along with migration options for Xray and Zephyr.

Preserve Source IDs

When using Excel or CSV, retain existing case identifiers where possible. They make it easier to compare migrated records with the source during validation.

Preserve Folder Hierarchy

Map folder paths carefully so cases do not end up in a flat or incorrectly organized repository.

Map Jira Requirements

Include requirement references during import where supported so traceability does not have to be rebuilt manually afterward.

Check Custom-Field Limitations

Not every custom-field type is handled the same way. For example, user-type custom fields are not imported through the standard Excel/CSV method and may need separate handling.

Step 5: Recreate or Map the Execution-Cycle Structure

Migrating cases alone does not preserve the context in which they were executed.

Recreate the cycles needed to organize historical runs, such as:

• Release testing cycles
• Regression cycles
• Sprint-based testing
• Environment-specific cycles

The Jira test management tool uses Cycles to organize execution activity and allows Cases and Sets to be included within those cycles.

The goal is to give historical execution results the correct context rather than placing old runs into unrelated or newly created structures.

Step 6: Migrate Historical Runs and Execution Results

This is one of the most important parts of preserving test history.

The test management platform provides APIs for migrating execution data, including support for backdated runs. This helps preserve the original execution chronology instead of making historical tests appear as though they were run on the migration date.

• Runs, statuses, dates, defect links and comments move through the Migration endpoints. 
• Evidence and attachments do not. They upload through separate endpoints once the runs exist, so plan them as a second pass.

Confirm which fields are supported by the chosen Xray or Zephyr migration method before assuming every historical attachment, comment, user assignment, or audit event will transfer automatically.

Step 7: Preserve or Restore Jira Requirement and Defect Traceability

After the test asset migration, verify that the relationships around each test still make sense.

The intended flow should remain clear:

Requirement → Test Case → Execution → Defect

• Use the Traceability Detail report to check these in one view. 
• It shows requirements, linked cases, execution results and defects as four columns, which is the same chain you are trying to verify. 
• For coverage totals, the Traceability Summary report accepts JQL so you can reconcile against the same requirement set you queried in the source tool.

Where requirement mappings are included during Excel or CSV import, they can be carried into the test management platform along with the migrated cases.

Maintaining these relationships is essential for coverage reporting, defect analysis, and release-readiness reviews.

Step 8: Validate the Migrated Repository Before Cutover

Do not assume that a successful import means the migration is complete. Reconcile the source and destination before retiring Xray or Zephyr.

Compare:

• Test-case counts
• Folder structures
• Cycles
• Historical runs
• Execution-status distribution
• Requirement associations
• Defect relationships
• Attachments where applicable
• Custom fields

Run Record-Level Validation

Select representative records and follow them end to end:

Requirement → Case → Cycle → Run → Result → Defect

This catches mapping errors that total record counts alone may miss.

Step 9: Validate Your Jira Testing Workflow Before Retiring the Old Tool

Use a short validation period to confirm that the migrated repository works in day-to-day testing.

Verify:

• Test creation
• Manual execution
• Automated-result reporting
• Requirement traceability
• Defect logging
• Permissions
• Reports
• QA team workflows

The objective is not to run two tools indefinitely. It is to identify missing data, broken relationships, or workflow issues before the source system is switched off.

Step 10: Complete the Final Cutover

Once the migrated data and workflows have been validated, complete the cutover in a controlled way.

• Stop creating new test assets in Xray or Zephyr.
• Capture changes made after the initial migration.
• Move any remaining records using the supported migration method.
• Run a final reconciliation.
• Preserve source exports where required.
• Update QA documentation and internal processes.

Treat this as part of the overall Jira migration strategy, not as an automatic “delta migration” feature unless that capability has been specifically confirmed for your migration setup.

Xray vs Zephyr Migration: Where the Process Differs

The overall migration process is similar, but the Jira test management platform provides different levels of migration support for Xray and Zephyr.

Migrating From Xray to AIO Tests

The platform states that its Xray migration utility can move:

• Test cases
• Attachments
• Execution data

Xray-specific elements such as Test Sets, Test Executions, Test Runs, Preconditions, requirement relationships, and test versions should still be reviewed during mapping.

Test Plans require particular attention. Xray uses a dedicated Test Plan entity, while the Jira test management tool does not provide the same standalone object. Teams therefore need to decide how existing Test Plans should be represented using Sets, Cycles, folders, or release-related workflows.

Migrating From Zephyr to AIO Tests

For Zephyr, the tool explicitly supports test-case migration and provides migration assistance. Teams should map:

• Test cases and folders
• Cycles and execution data
• Statuses and custom fields
• Requirements
• User references

The exact migration scope can depend on the Zephyr setup and migration method. Do not assume that every attachment, comment, audit record, or execution field transfers automatically without first confirming support.

Common Jira Test Management Migration Mistakes That Put Test History at Risk

Even when the import succeeds, poor migration decisions can leave important QA context behind. Watch for these common mistakes:

1. Migrating Cases Without Defining Field Mapping

Importing before mapping statuses, priorities, case types, and custom fields can create inconsistent or unusable data.

2. Moving Test Cases but Ignoring Execution History

A repository may look complete while still missing years of pass/fail results, cycles, defects, and execution dates.

3. Recreating Historical Runs as New Executions

Historical runs should retain their original chronology where supported. Otherwise, reports may make old testing appear recent.

4. Assuming the Tools Use Identical Data Models

Xray, Zephyr, and the platform structure test assets differently. Xray Test Plans, for example, require deliberate workflow mapping.

5. Losing Requirement and Defect Links

Preserving cases without their Jira relationships reduces traceability and makes historical analysis harder.

6. Assuming Every Custom Field Migrates the Same Way

Some field types require separate handling. User-type custom fields, for example, are not imported through the test management tool’s standard Excel/CSV method.

7. Assuming Version and Audit History Transfers Automatically

Migrating current cases and executions does not necessarily recreate every historical source-system revision or audit event.

8. Retiring the Source Tool Too Early

Keep Xray or Zephyr available until record counts, historical runs, traceability, and workflows have been fully validated.

QA Migration Checklist: What to Verify Before and After Cutover

A clear QA migration checklist helps teams catch missing data before the old system is retired.

Before Migration

• Inventory test cases and execution data
• Identify historical records that must remain accessible
• Back up the source repository
• Remove duplicate or obsolete cases
• Define entity, field, and value mappings
• Configure AIO Tests
• Review custom-field limitations
• Map users
• Select a representative pilot dataset

During Migration

• Migrate test cases
• Validate folder hierarchy
• Check field and value mappings
• Verify custom fields
• Confirm requirement links
• Set up the required cycles
• Migrate historical execution data
• Validate attachments where supported
• Check defect and run relationships

Before Cutover

• Reconcile source and destination record counts
• Validate representative records end to end
• Confirm historical runs and dates
• Check requirement and defect traceability
• Test the Jira testing workflow
• Verify permissions and reports
• Capture any final source changes
• Preserve the source backup

The migration should move to final cutover only after these checks are complete.

How to Know Your Jira Test Management Migration Was Successful

A migration is successful when teams can continue testing in the Jira test management platform without losing the context they relied on in Xray or Zephyr.

Check that:

• Test cases are complete and usable
• Folder structure is organized correctly
• Statuses, priorities, and custom fields are mapped properly
• Historical execution data is available as required
• Requirement-to-test-case traceability is intact
• Defects remain connected to relevant testing activity
• Required attachments are available where supported
• Reports reflect the migrated data accurately
• Manual and automated Jira testing workflows work as expected

Do not judge success only by the number of imported test cases. A technically complete Jira test management migration should also preserve the relationships and historical execution context that QA teams need for coverage analysis, defect investigation, and release decisions.

The test management tool for Jira provides execution, coverage, traceability, automation, and defect reporting that teams can use to review the migrated environment and confirm that testing can continue without rebuilding critical QA context.

Conclusion

A Jira test management migration is not complete just because test cases appear in the new repository. Teams also need to preserve the structure, traceability, execution history, and supporting data that give those cases context.

Moving from Xray or Zephyr should therefore follow a controlled process: audit the existing repository, define how source data maps to the test management platform, migrate cases and historical execution records, validate the results, and complete the cutover only after reconciliation.

AIO Tests supports test-case migration from Xray and Zephyr, provides APIs for migrating execution data, and offers flexible import options for structured test assets. For large or complex repositories, migration assistance can also help reduce the risk of missing important data.

The goal is simple: move to a new Jira testing workflow without leaving behind the QA history your team still depends on.

Frequently Asked Questions

1. What is Jira test management migration, and what data should be migrated?

Jira test management migration is the process of moving test assets from one test management tool to another while preserving the information teams still need. This can include test cases, folders, custom fields, requirements, defects, execution results, attachments, and historical run data.

‍

2. What are the key steps in a Jira test case migration?

Start by auditing and backing up the existing repository, then map source fields and test structures to the destination system. After migrating the cases and execution data, validate record counts, traceability, historical runs, and workflows before completing the cutover.

‍

3. What should be included in a QA migration checklist?

A QA migration checklist should cover repository backup, test asset inventory, field and value mapping, user mapping, folder structure, custom fields, requirement links, historical executions, defects, and attachments where supported. It should also include post-migration reconciliation and end-to-end validation before the source tool is retired.

‍

4. How do I migrate from Xray or Zephyr to AIO Tests without losing test history?

First, identify which test cases, execution records, traceability links, and supporting assets need to be preserved. Then map the source data to the Jira test management tool, migrate the repository and historical executions using the supported methods, and validate the results before retiring Xray or Zephyr

‍

5. Can I migrate test cases to AIO Tests while preserving test execution history?

Yes. The test management tool for Jira supports test-case migration from Xray and Zephyr and provides APIs for migrating execution data, including backdated runs. However, teams should confirm which source fields and historical metadata are supported by their specific migration method.

‍

6. How can I ensure a smooth migration from Xray or Zephyr to AIO Tests?

Run a pilot migration before moving the full repository, and define field, value, and workflow mappings in advance. Keep the source system available until test cases, historical executions, requirement links, defects, permissions, and reporting have been fully validated.

‍

‍