Runbook: move AIO Tests cases into TestWarden with CSV

To migrate AIO Tests cases into TestWarden, export the cases from AIO as CSV, open the Migration Center, choose Generic CSV, map the columns, read the preview, import in the background and reconcile the report against AIO. That is the whole path, and it takes an afternoon for a few thousand cases. The rest of this runbook explains each step, the places where AIO exports tend to need reshaping, and the decision that matters more than the mechanics: which parts of your AIO estate you should move, and which parts you should leave exactly where they are.

It helps to be precise about what this is. A CSV migration is a one-time copy of test case definitions into TestWarden’s own shared library. After the import they are native TestWarden tests, with version history, structured steps and version-pinned execution from the first attempt. It is not a live link to AIO, it does not synchronise anything afterwards, and it does not carry your execution history. If you want AIO to remain your test manager while TestWarden independently decides whether the combined evidence is enough for a release, that is a different, integration-shaped path, and the section on migration versus integration explains how to choose.

The visual above steps through the six stages using invented sample data, shows how a typical AIO column maps to a TestWarden field, lists example imported and skipped rows, and filters a coverage matrix of what transfers and what does not. The sections below follow the same order, and every claim in them is also written out as plain text, so nothing depends on the interaction.

Decide first: migrate, keep or run both

Teams usually reach for a migration runbook when a renewal, a consolidation or a tooling review is looming. Before you export a single file, answer one question: what is the job you want TestWarden to do? There are three honest answers, and they lead to different work.

TestWarden is, by design, an independent, policy-driven verification layer that sits above test-management tools, CI systems, scanners and coding agents. Customers can keep using AIO Tests, Xray, Zephyr Scale, TestRail, Azure DevOps, SonarQube and GitHub Actions. The Warden evaluates the combined, attributable evidence for one exact software change under its verification policy. Separately, the same Jira app includes full native test management, which is what this runbook moves cases into. Migrating is therefore a choice about where your test cases live, not a precondition for using the verification layer. For the wider framing see what a verification control plane is and the AIO Tests alternative page.

What you can retain in AIO instead of migrating

• Execution history. Cycles, runs and results are not imported by the CSV path. If you need them for audit or trend work, leave them in AIO or archive them there.
• Attachments. Screenshots, logs and files attached to cases or runs are not carried by a CSV file.
• Cases you do not want to rewrite. If a stable regression library works well and nobody edits it, leaving it in AIO and feeding CI evidence to The Warden costs you nothing.
• Reporting you already trust. If release managers rely on AIO dashboards, moving cases also means rebuilding those answers elsewhere.

A common, low-risk pattern is to migrate one active project first, run its next cycle natively in TestWarden, and leave older projects in AIO until their retention windows end. A mixed estate is not a failure. The migration is optional, and the preview makes a trial cheap.

Step 1: export cases from AIO Tests

AIO documents the procedure in Export Cases to Excel/CSV/PDF. In short:

1. Open Cases in the AIO Tests top menu.
2. Click the vertical ellipsis (⋮) at the top right of the cases page and choose Export Cases.
3. In the modal pick CSV and click Export.

AIO states that one export covers at most 1000 cases, and that an Export Range selector appears when you have more. A library of 4,200 cases therefore becomes five files, and you should keep them separate and name them by range (aio-cases-1-1000.csv and so on) because each file will be its own migration job. The documented export includes the case key, title, pre-conditions, steps with test data and expected results (each step on its own line), folder, linked Jira requirements, status, priority, tags and every custom field defined for cases. Cases that you cannot access export with restricted notices rather than content, which matters: if the exporting user lacks permission to part of the library, the CSV will contain rows that look like cases but carry no useful content. Export as a user who can see everything you intend to move.

Step 2: prepare the file and the account

Preparation is where most migrations are won, because every problem you find in a spreadsheet is cheaper than the same problem found after import. Work through this short list for each file.

• Role. You need the QA Admin role in TestWarden. Migration is admin-only, which is deliberate: an import creates many records at once.
• Limits. One file per job, up to 10 MB and 10,000 rows. A 1000-case AIO export will usually sit comfortably inside both, but a test with a very long step list consumes rows, so check row count rather than assuming.
• Title. Title is the single required mapping, and rows without a title are skipped. Scan the title column for blanks, for cells that contain only a case key, and for duplicates that deserve a note.
• Encoding. Open the file in a UTF-8-aware editor. If accented characters or symbols look wrong in your spreadsheet application, fix that before upload; re-saving through the wrong encoding is the commonest way to damage a clean export.
• Steps. Look at how steps appear in your file. TestWarden structures steps from its multi-step paste format: one step per line, with tabs between action, test data and expected result. AIO writes each step on its own line with its data and expected result, but the separators in your file may differ from what the paste format expects. If the preview later shows steps merged into one block, reshape that single column in a spreadsheet rather than editing every test afterwards.

Decide on a mapping for folders, release and automation fields

AIO cases typically carry organisational fields: a folder path, a release or version, an automation status, perhaps a component. TestWarden’s shared library has folders and tags of its own, but a CSV import cannot create your final structure for you. You have two good choices. Map the folder column to Tags if you want to filter by it immediately, or map it to a custom field if you want to preserve it verbatim and rebuild the library structure deliberately afterwards. Many teams do the second, because a folder path from five years ago is not necessarily the taxonomy they want today, and a custom field keeps the evidence of where each test used to live without forcing the structure.

Step 3: map the columns in Generic CSV

Open Migration, choose Generic CSV and upload the file. Obvious columns are mapped automatically; you complete the rest. The destinations are Title, Description, Priority, Status, Tags and Steps, plus custom fields for anything else, and an ignore option for columns you do not want. Each source column can map only once, so decide deliberately where a column such as pre-conditions should go. A good default is to map pre-conditions into the description, so the context travels with the test.

Treat the mapping as a contract with your future self. Anything you map to a custom field is searchable and preserved. Anything you ignore is gone from the TestWarden copy, though not from your original file, which you should keep. Because mapping decisions are cheap to change before the commit, run the preview twice if you are unsure: once with a conservative mapping, once with the structure you want, and compare the samples.

Step 4: read the preview and validate rows

Before any record is written, the Migration Center shows a preview with three headline numbers, Will import, Will skip and Total rows, the reason for every skipped row, and a sample of mapped tests. Resist the temptation to glance at the totals and click on. The headline numbers tell you how many rows are acceptable, and the sample tells you whether they are acceptable in the way you meant.

Validation happens per row. A row with no title is skipped, with a stated reason. A row with a priority or status value that TestWarden does not recognise does not block: it imports with the default and a warning, which is why the sample matters. Look for four specific smells in the preview.

1. Steps merged. One test with one enormous step instead of several. The separators in the step column do not match the paste format; reshape the column and re-preview.
2. Everything defaulted. If every row shows the default priority, your priority column probably did not map, or its values use a scheme TestWarden does not know. Decide whether to translate the values in the spreadsheet.
3. Surprising skips. A skip reason you did not expect usually points to a blank title cell or a row that is really a continuation of the previous one.
4. Short counts. If Total rows is lower than your AIO count for that range, the export itself was partial. Re-export before importing, not after.

Step 5: import, in the background

When the preview matches your intent, commit. The import runs in the background in batches of 200 with checkpoints, so closing the panel does not cancel it, and the job resumes. Re-running the same file with the same mapping reuses the existing job rather than duplicating rows, which means a flaky connection or an accidental double click does not double your library. Imported tests carry the label Imported from migration and a source reference, which gives you an easy filter for the whole batch, which makes the whole batch easy to find and review.

If you are importing several range files, run them one at a time and reconcile each before starting the next. The temptation is to queue everything and review at the end, but a mapping mistake repeated across five files is five times the cleanup. The first file is your pilot, and it should be the one where you read everything.

Step 6: reconcile against AIO

Reconciliation is the step that turns “it ran” into “it is correct”. Open the report and filter by Imported, Imported with warnings, Skipped and Failed. Then do three comparisons.

• Count. Imported plus imported-with-warnings plus skipped should equal the rows in the file, and imported plus warnings should equal the cases you expected from AIO for the same export range, less any you consciously skipped.
• Long tests. Open the five tests with the most steps and compare them with AIO side by side. Long tests expose step-splitting problems that short ones hide.
• Warnings. Walk through the warnings list. Each is a decision: accept the default, or fix the value in TestWarden after import using bulk edit.

Step 7: rebuild structure and links

An imported library is a flat, accurate set of tests. The value you used to get from folders, requirement links and cycles has to be rebuilt, and it is better to do it as a short, deliberate project than to let it accrete.

• Folders and tags. Recreate the structure you want in the shared Library, then use bulk actions to file tests, filtering on the preserved folder field or the tag you mapped.
• Requirement coverage. Re-link tests to Jira issues. Coverage is then computed in Jira, from the links, rather than imported from a file.
• Plans and cycles. Build new plans and cycles from the imported library. From the first attempt, each execution is version-pinned, so later edits to a test cannot rewrite what a past run verified.
• Automation. If your AIO cases carried an automation status, decide whether it still belongs on the test, or whether automated results should now flow from CI as evidence instead.

CSV migration versus live integration

Search results for “AIO Tests integration” blur two different ideas, and conflating them leads to wrong expectations. A CSV migration copies cases once, as described above. A live integration reads results from the vendor’s API without moving anything. TestWarden’s AIO Tests Cloud collector is the second kind. It runs in your own CI with authorised read-only credentials, collects the cycle’s results from the AIO REST API, and an attestor signs the source, target, count and execution time before The Warden evaluates them for an exact build.

You should know where that collector stands today, because it is easy to over-read. As of the October 2026 engineering acceptance, the AIO collector passes documented-contract HTTP tests and a signed offline HELD-to-CLEARED end-to-end test, and its live vendor certification is pending. No vendor is certified, and you should not plan a release process on it as a shipped feature. The CSV migration in this runbook is a different mechanism with its own, separate, tested behaviour. See Integrations for the current status of each provider, and the developer documentation for how evidence reaches The Warden.

What to do about AIO runs and results

Run and cycle history is not imported, and nothing in the migration changes it. That is a feature as much as a limit: your old results remain exactly as AIO recorded them, which is what an auditor wants. It does mean you need a plan. Keep read access to AIO for as long as you have a retention obligation; archive what you need to keep in a format you control; and do this before you cancel or downgrade, because exporting after access lapses is the situation nobody enjoys. Quality Memory, TestWarden’s verification history, begins accumulating with your first decision and first attempt, so for a while you will consult two places for history. Write down the cutover date so nobody has to guess later which system answers a question about an old release.

For how decisions, receipts and attempts are retained once you are running natively, see Quality Memory: the verification history TestWarden keeps, and for pricing as you scale to more Jira users see the Pricing page. The Migration Center overview lists every supported source and its limits in one place.

Common mistakes and how to avoid them

• Importing before reading the preview. The preview exists to catch merged steps and defaulted fields. Budget time to read the sample.
• Mapping everything to custom fields. It preserves data, but a library of tests whose priority and tags are buried in custom fields is harder to work with than one where the common fields are mapped.
• Treating the import as the end. The structure, links and plans need rebuilding, and the old history needs a decision.
• Migrating everything at once. A pilot project proves the mapping, and the second import takes a tenth of the time.
• Forgetting access. Only QA Admins can run migrations. Find out who that is before the deadline week.

Frequently asked questions

If you are weighing the decision, the AIO Tests alternative page lays out the comparison, choosing test management for Jira Cloud gives you an evaluation method, and the sibling runbooks for Xray and Zephyr Scale cover the other two common sources. When you are ready to try it on one real project, request an evaluation or open the Migration Center overview. The preview shows what will happen before any test is created, so a first run costs you little more than the time to read it.