A Jira project opens in Cloud, its Test issues are visible, and the migration dashboard shows success. Before reopening testing, the QA lead still needs to know whether historical Test Runs, cross-project relationships and attached evidence arrived intact. Xray's migration guidance explicitly warns that successful status does not necessarily mean every item migrated.
For an Xray Data Center-to-Cloud migration, cutover acceptance should therefore depend on a reconciled data baseline and usable testing workflows. Decide what must survive, rehearse how to prove it, and assign someone to resolve every unexplained difference before users resume work.
Xray is a Marketplace app with its own testing data and migration requirements. Jira projects and issues are one layer; Xray-managed test content, execution records and related evidence are another. In the documented JCMA path, the Xray data migration starts after the Jira data migration completes. Seeing a Jira issue in Cloud does not prove the associated app data is complete.
Give the Jira administrator responsibility for platform migration evidence and the QA migration owner responsibility for testing-data acceptance. They should review the same attempt, destination and project scope, but sign off on different checks. Neither a Jira completion indicator nor an app success indicator replaces reconciliation.
Before rehearsal, record the Jira Data Center, Xray Data Center and Jira Cloud Migration Assistant versions, destination Xray app and edition, licensing, and supported migration path. Ask Xray to confirm the exact combination, including any preload prerequisites. Its overview and minimum-version knowledge base differ at the boundary release, so use the latest compatible supported release rather than treating a remembered minimum as sufficient.
Also confirm migration-stage and strategy guidance for the installed environment. Xray recommends a Production stage label for test migrations, while Atlassian describes that label as organizational rather than behavior-changing. Current documentation also contains inconsistent strategy wording. Do not assume an all-at-once option is either discontinued or universally available, or that a label determines data completeness. Resolve the applicable guidance with the vendors before turning the validation plan into an executable runbook.
A migration batch should follow Xray dependencies, not an organizational boundary chosen for convenience. Xray's planning guidance calls for reviewing its dependency map, and its pre-migration guidance says linked projects must migrate together. A requirement in one project, a Test in another and an execution elsewhere can form a single acceptance chain.
Have the administrator review the selected scope with Xray's preflight checks and retain the dependency findings. If a dependency extends outside the proposed batch, resolve the scope before rehearsal. Do not plan to repair a split relationship later without a vendor-confirmed migration approach.
Capture an agreed baseline at a defined cutoff. Count reusable cases separately from Test Executions and individual Test Runs. A Test Execution issue count cannot substitute for the number of historical runs associated with it. Record attachment counts and sizes separately, since a modest issue inventory can still carry substantial evidence volume.
Use a reconciliation sheet such as this one. These are suggested review fields, not a guaranteed Xray export format.
Data Group | Baseline to Retain | Cloud Acceptance Check |
|---|---|---|
Tests and preconditions | Source identities, types and critical content | Mapped records have the expected specification and associations |
Plans, sets and executions | Membership and cross-project dependencies | Expected members and relationships are recoverable |
Historical Test Runs | Run identity, execution context and result evidence | Matched records retain the context needed to interpret the result |
Attachments | Owning record, count, size and selected critical files | Evidence opens from the correct test or run |
Exceptions | Excluded records, reason, owner and approval | Differences match the approved scope rather than unexplained loss |
Keep a source-to-destination identity mapping rather than assuming internal Jira IDs remain unchanged in Cloud. For critical records, retain enough source context to recognize the correct destination even when an identifier or display location changes.
Resolve archived content explicitly. Xray documents that app data for archived issues is not exported, even though the Jira issues can migrate and the migration can succeed. Archived projects can also cause migration failure. Decide with the responsible owners what belongs in scope and how excluded history remains accessible. Do not quietly subtract missing records from the baseline after the result is known.
Complete app assessment and confirm the destination Xray app before planning attachment preload. Xray's guide requires the preload and main migration to use the same app and Cloud site. A preload prepared for Xray must not be assumed reusable for a main migration using Xray Enterprise.
Treat attachment readiness as a separate gate. Xray explains that after the Jira preload completes, it still processes the preloaded attachments. Jira-side completion therefore does not establish that Xray has finished preparing them. Record the preload attempt, selected projects, destination and evidence of Xray readiness, involving Xray Support when confirmation is needed.
Build timing around both platform requirements and observed app readiness. For supported app preloads, Atlassian requires the follow-up migration within 14 days of preload completion and says this feature is unavailable for Government Cloud migrations. Confirm applicability to the target environment. Xray recommends allowing at least four or five days before the planned migration, especially for large attachment volumes, but that recommendation is not a processing-time guarantee.
If readiness is uncertain, review the schedule and vendor guidance rather than assuming a green Jira preload makes the cutover safe. In rehearsal, include files attached to the records your team depends on, not only attachments visible on ordinary Jira issues.
A useful rehearsal exercises the planned project groups, app choices, versions, evidence checks and decision process. Xray recommends at least two successful test migrations, and its planning guide says a single successful trial is insufficient. Use the first rehearsal to expose gaps and a subsequent production-like attempt to confirm the corrected plan.
Keep the environment differences visible. A smaller dataset, a different destination edition or administrator-only access may make a trial easier without proving that the production plan is ready. If the migration tooling or scope changes after rehearsal, reassess which checks and timings need to be repeated.
The runbook should assign an owner and expected duration to each validation gate. Include planned source and destination change controls, because edits made during transfer can undermine comparisons. Have authorized administrators agree how user activity and automation will be controlled. Xray warns against concurrent maintenance, upgrades, reindexing, restarts and database work during migration. This preparation needs a reviewed operational plan, not an improvised permissions change during cutover.
After each rehearsal, review the Xray migration report for that named attempt, including failed, skipped or missing items. Retain the JCMA post-migration report, relevant app logs and the baseline used for comparison. Atlassian exposes separate overall migration and Marketplace app statuses, so identify which layer each result describes.
Save evidence promptly. Atlassian documents limits on app-log history and event counts, so a later download may not preserve everything needed to investigate an earlier problem. Associate the evidence with the migration name, attempt, time, source scope and destination. Do not mix a report from one trial with counts from another.
For each difference, record the affected source identity, expected destination, observed outcome, explanation and responsible owner. Separate approved exclusions from missing records, duplicate matches, broken relationships and unreadable evidence. Matching totals are useful checks, but two incorrectly matched records can leave a total unchanged.
Choose representative high-risk records as well as comparing inventories. Follow a requirement to its Test, the relevant Test Execution and historical Test Run, then inspect the result evidence and any linked defect. Where applicable, compare tester attribution, execution context, outcome, timestamps and supporting files with the baseline. Confirm the fields and representations supported by the selected migration path rather than assuming every Data Center field appears identically in Cloud.
A reusable case describes what should happen; a historical result records what happened in a particular execution. Updating or viewing the current case must not be mistaken for validating its old result. A Jira requirements traceability matrix provides a useful model for keeping requirement, case, run, result and defect identities separate during this review.
Ask representative users to validate their normal workflows in the rehearsal environment. Include people who need to read historical evidence, reviewers who inspect coverage, and administrators responsible for app access. Administrator visibility alone cannot establish that the intended users can recover the same evidence.
Add documented post-migration differences to the checklist. For example, Xray's detailed library knowledge base says the standalone Automated Step Library is not copied directly. Migrated Gherkin test cases supply steps for the Cloud BDD Step Library, with an Xray project-level Project Reindex required after migration. Have the administrator confirm and schedule that post-migration action separately; it is not a reason to reindex Jira while migration is running.
Likewise, do not assume Cucumber settings, gadget configurations or notification behavior transfer unchanged. Xray lists migration limitations and template-review requirements. Classify the relevant items as deliberate follow-up work with acceptance owners, not as exceptions discovered only after reopening testing.
Consider an invented rehearsal for a checkout project and its linked shared-testing project. The approved in-scope baseline contains 120 Test cases, 360 historical Test Runs and 48 attachment records. Any archived exclusions have already been reviewed and recorded outside those totals. These numbers illustrate a decision process, not a customer migration or tests performed against an application.
The fictional Cloud inventory shows all 120 cases, 358 historical runs and 48 attachment records. A reviewer also finds that one counted attachment cannot be opened from its owning run.
The case count matches, but two historical runs are missing. The attachment count also matches, yet one piece of evidence is unusable. Neither matching total closes the gap. Record the missing run identities and the unreadable file with their owning records, then investigate them against the attempt-specific reports and source baseline.
If the missing runs support the checkout release's audit history, the QA owner should hold acceptance until they are recovered or an explicit, scoped exception is approved. The unreadable attachment remains a separate issue even if a report labels its record migrated. Recheck the affected evidence and relationships after any approved remediation, preserving the earlier findings rather than replacing them with a new green summary.
Agree the go/no-go criteria before the migration window. A practical acceptance policy should require:
Set hold and recovery triggers alongside these criteria. Examples include unexplained loss of critical run history, unresolved attachment readiness, broken cross-project links or insufficient time to finish validation before users must resume work. Name the person who can stop cutover and the people who approve any exception.
Define what returning to the source would mean before relying on that option. Identify the authoritative environment, approved recovery procedure, communications and treatment of work created in Cloud. Once users or automations write to the destination, reopening the source without reconciling those changes can create competing histories. Do not promise automatic rollback or bidirectional synchronization.
Avoid treating a rerun as a universal repair. Atlassian documents app-dependent retry behavior and a separate app-data migration facility with prerequisites, but those general facilities do not establish support for the chosen Xray recovery path. Atlassian's guidance also says Cloud migration adds data rather than overwriting existing data. Confirm the exact remediation and destination preparation with the vendors instead of launching another attempt into an unresolved target.
Before approving cutover, ask another reviewer to recover one critical historical chain using only the retained baseline, reports and Cloud records. If the evidence cannot be interpreted, or any unexplained difference remains, keep the acceptance gate open and resolve it before routine testing resumes.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
