Test migration checklist

Move a test library in stages: inventory, sample, reconcile, then switch over. Use this checklist for a spreadsheet import. Confirm your route in the product guide before planning the move.

Migrate from Xray, Zephyr Scale, Zephyr Squad or AIO Tests. Confirm the supported fields for your chosen route before moving the full library.

Export Nexus folders with or without sub-folders as CSV, JSON, Excel or Cucumber .feature files. Import .feature files into folders with their @folder: tags. Test Sets and cycles support JSON export and import for a round trip, plus CSV export. Imports preview first and can be undone.

Tick items as you review them. Selections are not saved when you leave or reload this page. Print or save the completed page as a PDF using your browser if you need a record.

Inventory the source

• Record the source tool, project, case count and owner.
• Identify cases to migrate and obsolete cases to archive.
• List the fields, folders, labels and statuses your team relies on.
• Identify shared steps, parameters, data sets, attachments and requirement links.
• Decide whether historical executions and defect links need to be transferred or retained in a separate archive.
• Export a source backup and confirm that your team can read it.

Agree the destination and mapping

• Nexus setup and the destination project's health checks are complete.
• The migration operator has the necessary access to both systems.
• Your installed Nexus release and chosen import route support the data you intend to move.
• Map titles, preconditions, ordered steps and expected results.
• Agree how source statuses, custom fields and folder structures will be represented.
• Identify fields and relationships that the selected route does not transfer.

Do not assume that importing cases also imports execution history, attachments or all relationships. Confirm each required data type against the selected route, then validate it in the sample.

Trial a representative sample

• Include a simple case, a multi-step case and a case with preconditions.
• Include shared steps, parameters and non-ASCII text if your library uses them.
• Include requirement links and any custom fields that are important to reporting.
• Review the import preview and resolve rejected or ambiguous mappings.
• Confirm that step order and expected results match the source.
• Run an imported case and verify it behaves as a usable test.
• Establish how retries or repeated imports behave before importing the full library.

Reconcile the full import

• Agree a change freeze or a way to capture source changes during migration.
• Record the import outcome, including created, rejected and skipped records.
• Reconcile source and destination counts, accounting for deliberate exclusions.
• Spot-check cases across folders and complexity levels.
• Check requirement links, shared-step references and data dependencies.
• Verify permissions with a normal tester account.
• Keep an exceptions list with an owner for every unresolved item.

Switch over deliberately

• A QA owner has accepted the migrated sample and reconciliation results.
• The team knows when Nexus becomes the working test library.
• Access to required historical evidence is retained.
• Source backups and any temporary archive have an agreed retention owner.
• There is a recovery plan if validation fails before the switch.

Keep the source available until the agreed validation is complete. For help choosing a migration route, contact Nexus support with the source tool and data types involved; do not send credentials.

Back to guides and checklists