Leaving Zephyr in Jira Cloud: Export Test Cases and Results Before Cancellation

A QA team leaving Zephyr needs more than a spreadsheet that opens successfully. It needs the test definitions it intends to keep, the execution evidence it may need to explain later, and a record of anything the exit package does not preserve. A result summary can show progress while leaving individual attempts unresolved. A case export can preserve useful definitions without proving that execution history or attachment files will remain available.

Prepare and review that package while the app is still accessible. Treat cancellation as a separate, authorized billing decision after the records owner accepts the package and its limitations. The procedure below is educational: no Jira tenant, customer export, vendor support conversation, or cancellation was performed to produce it.

Confirm the App Before Following the Procedure

Use this procedure for the current Zephyr Cloud test-case library and Reports interface documented by SmartBear for its Jira app. The current documentation family includes Zephyr Essential, Zephyr, and Zephyr Advanced. Record the installed Marketplace app name, Cloud deployment, and edition before selecting an export route. A familiar Zephyr name is insufficient to identify the correct instructions.

Do not substitute Zephyr Enterprise or Data Center menus, or a legacy Squad workflow, because an older answer mentions Excel, XML, or CSV. The Cloud guides used here describe selecting cases in the library and generating execution reports separately. If your app does not expose that interface, stop and obtain instructions for your exact installation rather than improvising a similarly named button.

Keep native Jira exports separate. Atlassian's Jira Cloud backup documentation explicitly excludes third-party apps and app data. Exporting Jira work items to CSV is also not evidence that the separately managed Zephyr definitions and execution results have been captured. Jira issue records, app-managed cases, and execution reports may all be useful, but one file should not stand in for the others.

Freeze the Exit Scope and Acceptance Rules

Have the QA lead write the inventory before requesting exports. Identify the spaces or projects, case folders, cycles, plans, date boundaries, and record populations that must remain understandable after the exit. Record the chosen filters and the account's approved access scope. Otherwise, a later reviewer cannot tell whether a missing test was excluded deliberately, hidden by permissions, or lost during collection.

Separate two populations. A definition describes what to test, including its identity and version, setup, ordered steps, and expected outcomes. An execution describes a particular attempt and its recorded result. A case executed twice should remain one case identity with separate execution identities; an execution expanded into several step rows should not become several attempts.

Define these checks as acceptance requirements, not promises about export contents:

• For definitions, compare case identity, title, preconditions, ordered steps, test data and expected results. Identify required versions, relationships, custom fields and attachments separately.
• For execution evidence, compare execution identity, its case and version reference, cycle or run context, status, actual result, linked defects and relevant dates wherever those fields are required and available.
• For scope, record status and environment choices, archived populations, and any selection or pagination behavior that needs confirmation. Do not assume a visible page represents the complete population.
• For delivery, identify the records owner, approved storage location, permitted readers, known gaps and the person authorized to make the later billing change.

Mark required but unconfirmed coverage NOT VERIFIED and keep the exit on hold. The Cloud case guide identifies an Archived Test Cases area, but that does not establish that the ordinary library selection includes archived cases. Likewise, a report's existence does not establish that it includes every archived attempt, environment or historical version. Resolve those questions without modifying or deleting source data to make the numbers easier to match.

Export Definitions and Execution Reports Separately

Plan two evidence streams with a shared scope manifest. Preserve the original files and record which app, selection, filters and collection time produced each one. A convenient merged worksheet can aid review later, but retain the source files so reviewers can inspect the transformation and distinguish case content from execution evidence.

Capture the Test Definitions

For the current Cloud library interface, SmartBear documents this sequence:

1. In the test cases library, select the test cases you want to export.
2. Choose More > Export to Excel or Export to XML.
3. Locate the downloaded file in the default download location and record it in the package manifest.

The documented formats do not establish a complete field schema. Before collecting the final population, an authorized operator should examine a representative sample that includes a multistep case, a meaningful precondition, a linked item and any required custom fields. Compare the actual file with the case being preserved, including step order, line breaks and expected results. Record an absent field as a gap, not as an assumed empty value.

Be explicit about versions. SmartBear's Cloud version-control guide says lists, grids and searches show the most recent version by default. That is a reason to verify version coverage, not a guarantee that the case export includes every older version. If a historical execution refers to an older definition, retain or otherwise resolve that definition under an approved method before treating the execution as fully explained.

Attachment support in the case editor also does not prove that the export contains attachment binaries. A link that still points into the app may become unusable after access changes. Inventory required attachments and relationships separately, confirm an authorized preservation method, and record unresolved content without claiming that XML or Excel makes it portable automatically.

Capture Execution Evidence Through Reports

In the current Zephyr Cloud reporting guide, open a space, select the Reports tab, and choose the report to generate. Complete the relevant Project and Filters options and any date ranges required by that report. The documented filters include test cycle, test plan, test cycle release version, test case folder and advanced filtering. Record the actual choices rather than relying on a screenshot of the final totals alone.

SmartBear lists Test execution results (summary), Test execution results (list), and Test execution results (detailed), with Excel as their export format. Its generation guide describes an option to export raw execution-report data to Excel. Use the applicable list or detailed report as a candidate for record-level review; preserve a summary separately if management needs an overview. A summary of statuses or progress is not a record-level archive of individual attempts.

Inspect the downloaded report before assuming that “detailed” means every field your exit requires. Check identity and case references first, then representative status, actual-result, defect and date values. If a required identity or field is not exposed, ask the vendor about an applicable supported route. Do not silently replace a missing record with an aggregate or borrow a legacy export schema.

Historical attempts need their own check. SmartBear documents that starting a new execution archives the previous result. Confirm whether the chosen report includes those earlier results and how they can be distinguished. Seeing them in the application does not establish that they are present in the downloaded file. Never start a new execution merely to perform an exit review.

Reconcile Identities Before Comparing Totals

The following frozen inventory illustrates a future review. Its identifiers and worksheet rows are local teaching conventions, not Zephyr field names, a vendor CSV schema or observed export results. The deliberately incomplete candidate shows why row totals alone cannot authorize cancellation.

Fictional exit inventory EX-16, version 1, is an authored, unexecuted teaching example for the current Zephyr Cloud library and Reports interface. It contains no customer data or vendor output. The current definition scope is C01 version 2, C02 version 1, and C03 version 1. C01, Review basket, has precondition Cart has two synthetic items and ordered steps Open basket then Review total, with expected result Total matches the dummy prices. C02, Submit basket, has precondition Cart has one synthetic item and step Submit order, with expected result Dummy confirmation appears. C03, Reject empty basket, has precondition Cart is empty and step Submit order, with expected result Submission is refused.

The expected execution inventory is E01 for C01 version 1 in Cycle A, Failed, actual result Dummy total differs, defect BUG-01, dated 2026-10-01; E02 for C01 version 2 in Cycle A, Passed, actual result Dummy total matches, no defect, dated 2026-10-02; E03 for C02 version 1 in Cycle A, Passed, actual result Dummy confirmation appears, no defect, dated 2026-10-02; and E04 for C03 version 1 in Cycle B, Blocked, actual result Dummy environment unavailable, no defect, dated 2026-10-02. The authored candidate definition rows are C01/2/1, C01/2/2, C02/1/1, and C03/1/1, where each tuple means case/version/step. Candidate case fields match the expected definitions except that C02's precondition is blank. The authored candidate execution rows are E01/1, E01/2, E02/1, E03/1, and E03/1, where each tuple means execution/step.

The execution fields match the expected inventory for identities present; repeated step rows are not separate attempts. The older definition C01 version 1 is outside the confirmed current-definition inventory and its availability is NOT VERIFIED. Attachments, change history, archived-attempt export coverage, storage permissions, package access, vendor retention, and records-owner acceptance are NOT VERIFIED. Any missing expected identity, unexpected identity, duplicate execution/step tuple, missing required field, or unresolved required scope keeps the exit decision on HOLD. Identity agreement alone does not prove content fidelity, retrieval, import compatibility, or a restorable backup.

Review Population	Expected Inventory	Authored Candidate, Unexecuted	Future Exit Decision
Current case identities	3 distinct IDs	3 distinct IDs in 4 step rows	HOLD: C02 precondition is blank
Execution identities	4 distinct IDs	3 distinct IDs in 5 step rows	HOLD: E04 is missing
Execution and step duplicates	No repeated execution/step tuple	E03/1 repeated once	HOLD: 1 duplicate row
Unexpected identities	None allowed	0 unexpected IDs	No unexpected ID in this example
Historical definition	C01 version 1 needs confirmation	NOT VERIFIED; current C01 is version 2	HOLD: historical content unresolved
Attachments, history, access, retention, acceptance	Separate required checks	NOT VERIFIED	HOLD: do not authorize cancellation

The definition worksheet has four step rows but only three case identities. The execution worksheet has five rows but only three execution identities: E01 occupies two legitimate step rows, while E03/1 is repeated once. E04 is absent even though the raw row count exceeds the expected number of execution identities. Preserve the duplicate in the original candidate record and investigate its cause; silently deleting it would conceal the discrepancy.

Compare fields after joining identities to the frozen inventory. C02's blank precondition fails the stated requirement even though every current case ID is present. For E01, compare the Failed status, Dummy total differs actual result, BUG-01 reference and date together. Its C01 version 1 reference still requires historical definition confirmation; the current C01 version 2 cannot automatically explain that earlier failure. These checks describe only this bounded fictional inventory, not coverage of every case in a real account.

For a real review, extend the manifest to the entire approved population and document every missing, unexpected or duplicated identity, field difference and unresolved scope. If identities reconcile, continue with content and dependency checks. A readable file, a successful parse or matching counts still does not prove that another tool can import it or restore the original app state.

Resolve Retention and Secure the Package Before Cancellation

Atlassian states that Marketplace app retention and reactivation periods are set by the app vendor. Do not apply a Jira platform retention period to Zephyr. SmartBear's current Cloud privacy page says customer information is not automatically deleted, but that general statement does not establish a post-cancellation retrieval window, access rights or restoration service for your subscription. Obtain applicable written clarification before relying on continued availability.

Ask the vendor to identify the exact app, deployment and edition covered by its answer. Confirm what happens after subscription cancellation or deactivation and after uninstall, which records and attachment assets are retained, when access ends, whether retrieval requires reactivation, and how deletion requests affect that process. Record unanswered questions as unresolved. A retention agreement alone is not a retrieval test, and no vendor confirmation is assumed here.

Store the package only in an approved location with appropriate access controls and handling for any personal or confidential data. File existence and an export permission do not verify file contents or storage permissions. Have an intended reader test access to the preserved package and check whether any required attachment or link still depends on the source app. Do that while the source remains available, not after cancellation.

The records owner should accept the manifest, representative field comparisons, unresolved gaps and any separate retrieval or migration validation required by the organization. Only then should a separately authorized billing actor consider the applicable subscription action. Atlassian documents different original and improved billing experiences and distinguishes deactivation from later app uninstall. Do not treat either as permission to delete a Jira site or assume the same consequences.

Keep the exit on hold when required evidence remains missing or unknown. The practical deliverable is an accepted, accessible exit package with explicit limits. Calling it a full restorable backup would require evidence that these exports and reports do not provide on their own.