Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Do not treat a Zephyr Scale-to-TestRail guide as instructions for moving the other way. TestRail’s article titled “Migrate from Zephyr Scale” describes the reverse direction. Before choosing CSV or REST API for a TestRail-to-Zephyr Scale migration, confirm whether your target is Zephyr Scale Cloud or Server/Data Center and verify that edition’s supported import or API route for the data you need to move.
First confirm which direction and Zephyr Scale edition you mean
The direction matters: TestRail’s “Migrate from Zephyr Scale” guide covers exporting Zephyr Scale data and importing it into TestRail. It is not a TestRail-to-Zephyr Scale recipe. TestRail’s general CSV import documentation likewise explains importing data into TestRail; it does not establish how Zephyr Scale ingests a TestRail export.
Zephyr Scale Cloud and Zephyr Scale Server/Data Center have separate documentation and API surfaces. Identify the target edition and deployment version before designing a file or script. The documentation available for one edition should not be assumed to apply to the other.
Inventory what must survive before picking a method
Make a source inventory and decide which data is in scope. A test-case count alone will not reveal whether important relationships or history are missing. Record both the required target outcome and any intentional exclusions.
- Test cases: titles, descriptions, preconditions, steps, expected results, templates, and custom fields.
- Organization: folders and any hierarchy or naming conventions that users rely on.
- Links and files: attachments, requirements, issue links, and other relationships.
- Planning and execution: test plans, cycles, test runs, results, and their links to cases.
- Historical data: prior changes, execution history, and any audit information users need to retain.
For each category, note the source location, whether it is required, the intended target representation, and how you will verify it. Do not infer that support for test-case creation means support for history, attachments, or execution relationships.
CSV versus REST API: what each route can establish
| Decision factor | CSV | REST API |
|---|---|---|
| Target support | Confirm that the exact Zephyr Scale edition supports importing the CSV structure you plan to create. The TestRail import guide documents TestRail’s importer, not Zephyr Scale ingestion. | Confirm the relevant API operations, authentication, payloads, limits, and version for your target. Zephyr Scale Server API documentation lists resources for test cases and related objects, but that does not establish an automatic TestRail mapping. |
| Best fit | Worth evaluating for a bounded, inspectable transfer, especially when the required scope is limited to cases and their supported fields. | Worth evaluating when transformations need to be repeatable or the migration requires creating and relating multiple kinds of objects. |
| Review and repeatability | A spreadsheet or CSV is straightforward for human review, but may need format-specific preparation and careful import handling. | A script can encode transformations and reconciliation, but requires development, maintenance, and version-specific validation. |
| Data fidelity | Support for fields, steps, attachments, links, plans, executions, and history must be checked separately for the target importer. | Availability of an operation for one object does not prove that every source field or relationship can be represented or migrated. |
The fit descriptions are implementation guidance, not vendor guarantees. The documentation cited here does not establish a complete TestRail-to-Zephyr Scale mapping for either route.
When CSV is the right candidate
Consider CSV only after confirming that your target edition offers a supported import for the required data shape. TestRail’s “Migrate from Zephyr Scale” article, updated March 14, 2025, contains useful examples of exporting data, mapping fields, separating files by template, and preparing CSV files. Those examples describe a reverse migration, so use them as ideas for planning and inspection—not as Zephyr Scale import instructions.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute- Confirm the target importer. In the documentation for your Zephyr Scale edition and version, verify the supported file format, required columns, accepted values, and supported fields. If that route is not documented, do not assume a TestRail CSV will import.
- Define a narrow mapping. Map each required source field to a target field, including how steps, expected results, templates, and custom fields should be represented. Mark data with no confirmed target mapping as unresolved rather than silently dropping it.
- Prepare a representative file. Include varied cases that exercise the formats and fields you care about. Keep cases with different templates or structures separate if the target’s documented format requires it.
- Import a small sample and inspect it. Check the resulting field values, step order, formatting, and organization in the target. Confirm how the importer handles duplicates and errors before scaling up.
- Reconcile the full import. Compare source and target counts and sample records. Track rejected rows, omitted data, and any manual corrections.
TestRail’s general CSV/Excel import article, updated September 5, 2025, describes the TestRail side of importing. It is not evidence that Zephyr Scale supports the same columns or import behavior.
When a REST API migration is worth evaluating
A REST API approach is a custom integration pattern, not a ready-made field mapping. SmartBear’s Zephyr Scale Server API reference lists operations for test cases, bulk test-case work, attachments, folders, test plans, test runs, and results. That establishes that the documented Server API has resources for these areas; it does not prove that source IDs, fields, history, or relationships transfer automatically. Confirm the API for the exact target edition and version before building against it.
- Extract the source data. Choose the available TestRail export or interface that exposes the fields and related records in scope. Preserve a source snapshot and stable identifiers so each record can be traced during reconciliation.
- Transform and map. Convert source fields and values to the target representation. Maintain an explicit ID crosswalk for cases and related entities; do not assume identifiers are interchangeable across products.
- Create target objects in dependency order. Build the records and relationships required by the verified target API, following its documented constraints. Avoid copying endpoint paths or payloads from a different edition or version.
- Capture outcomes. Record created, updated, rejected, and skipped records, along with target identifiers and error details. Make retries safe so a rerun does not unknowingly create duplicates.
- Reconcile the result. Compare counts and selected field values, inspect steps and relationships, and verify attachments separately. Resolve differences before treating the migration as complete.
API automation can make transformations repeatable, but it also makes mapping decisions and error handling your responsibility. A listed API resource is not proof of parity with TestRail data.
Rank #4
Use a staging migration and an explicit reconciliation checklist
Run a representative migration in a staging project before touching the production target. SmartBear’s Cloud Migration Alternatives guidance says, “We strongly recommend the following to be tested in a staging environment,” in the specific context of migrating Zephyr Scale Server/Data Center to Cloud through its API. That is not a TestRail migration procedure; using staging for this separate migration is prudent operational guidance.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Compare source and target totals for every entity included in scope, not just test cases.
- Inspect representative records with different templates, step counts, custom fields, and relationships.
- Check folder placement, issue or requirement links, and plan/run/result associations where required.
- Verify attachments independently and record any that did not transfer.
- Review rejected records, duplicates, transformation errors, and manual changes.
- Retain source exports and the migration log until the responsible users approve the target data.
- Record excluded data, the reason it is excluded, and any separate retention or handling plan.
Do not apply Cloud-migration exclusions to this route without checking
SmartBear’s Cloud Migration Alternatives page concerns Zephyr Scale Server/Data Center to Cloud, not TestRail to Zephyr Scale. For that particular route, the documented API migration is limited to the latest versions of test cases, cycles, and executions, and excludes items including attachments, custom fields, comments, datasets, environment, permissions, priorities, saved filters, statuses, test-case change history, test plans, and test-script test data.
Best Value
Those route-specific constraints are a reason to verify migration coverage carefully, not a definitive list of what a TestRail-to-Zephyr Scale import or API can or cannot transfer. Ask the target-edition documentation or vendor support about each required category before committing to a method.
Choose the simplest route that supports the required data
For a limited case library, use CSV only if the exact target edition documents a suitable import and a sample proves the needed fields survive. For broader relationships, repeatable transformations, or multiple object types, evaluate a scripted API integration only after confirming the target operations and mappings. If neither route is documented for an essential data category, treat that category as an unresolved migration requirement rather than assuming it will move.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
