Sandbox to production deployment in Jira Cloud: a first field report (and one silent gap)
For reference: the official Jul 27 to Aug 3 Cloud changes roundup lists configuration deployment as Rolling Out, so this is now citable from Atlassian's own release notes, not only the changelog. Test a change in your sandbox, scan, validate, deploy it onward, with a log of who deployed what and when.
I ran one end to end the same day π An 18-minute scan, 461 changes found, one workflow deployed. This is what the announcements will not tell you: the real numbers, what the scanner actually sees, and one gap that deserves a place in your deployment checklist from day one π
The setup, honestly declared. The feature deploys from a sandbox to its production or to another sandbox, and the destination picker offers both (you will see it in the first screenshot). For this first run I deliberately did NOT deploy to production: I used two Jira sandboxes in Atlassian's own recommended pattern, one as development and a fresh production copy as staging, and deployed dev to staging. Same feature, same scanner, same validation and log, just aimed at a rehearsal target first, which is exactly how Atlassian's docs suggest complex deployments should be run before production ever sees one. The test payload: a copy of a real production workflow, renamed, assigned to nothing, and deliberately kept with its Marketplace app post functions and validators. Whether app rules survive deployment is documented nowhere, and I wanted the answer.
The numbers first π
β±οΈ The scan took 18 minutes on a mature org. Plan for coffee, not for a click.
π It found 461 changes: 214 added, 247 modified. Before that number alarms you, here is what it means. The scan is a diff: it compares every supported configuration entity in the source against the destination and lists every one that differs. Added means it exists in the source but not the destination; Modified means it exists in both but is not identical. Nothing on the list deploys unless you select it (I selected exactly one workflow out of the 461). So why so many between two copies of the same production? Time. My dev sandbox was copied from production weeks ago, my staging sandbox is a fresh copy, and production never stopped evolving in between. 461 is not a benchmark, it is one org's drift on one day: yours might be 40 or 4,000 depending on your configuration size, how old your sandbox copy is, and how fast your production evolves. Whatever it is, it is the honest size of your drift, made countable for the first time, and I suspect most orgs will be surprised by theirs.
β Selecting 1 workflow auto-selected 2 entities. Validation took about 5 minutes, and the deployment itself completed in a couple of minutes, named, timestamped, and attributed in the deployment log.
What the scanner shows you
The change list groups everything by entity type (automation rule configs, fields, filters, statuses, permission schemes, projects, boards, screens, workflows and their schemes) with filters by entity type, by space, and by change type. Two observations from reading it closely:
- It quantifies drift you could never see before. Sixty-nine filters and over a hundred boards showing as changed between environments is not a deployment problem, it is a visibility gift π This list is worth generating even if you never press deploy.
- A charming detail for long-time admins: some entity groups surface Jira's internal names. Boards appear as Rapid View, a name most of us last saw in REST payloads π The scanner is clearly reading the configuration layer directly.
Dependencies: the graph is real πΈοΈ
Selecting my test workflow automatically selected one more entity: the custom field the workflow's rules reference. The side panel shows each entity's change type, its dependencies, and a Used by view, and dependencies are selected for you, so a workflow cannot arrive missing the field it writes to.
What the dependency graph did not list is the interesting part. We will get there.
The gates are genuinely good π‘οΈ
Before anything deploys: a validation pass checks every selected entity, with a per-entity Ready for deployment status and a Contains errors filter for anything that fails. Then a plainly worded confirmation: deployed changes in the destination cannot be rolled back. Then a progress view, and a log entry: named deployment, destination, deployed by, deployed on, status.
If your change advisory board has ever asked how a Jira config change is evidenced, this is finally a real answer π
My deployment: both entities validated clean, zero errors, deployed successfully. The workflow arrived in staging exactly as designed: correct layout, correct statuses, and inactive, since deployment does not assign it anywhere.
The silent gap: marketplace app rules partially survived β οΈ
Now the part I ran this experiment to learn. The test workflow carried Marketplace app post functions and validators. After a fully green deployment, zero errors, zero warnings, I opened the deployed workflow on the destination and compared the rules by hand.
Some of the marketplace app-provided configuration arrived. Some did not arrive at all. And nothing in the scan, the validation, or the deployment result mentioned the difference.
To be precise about scope: one org, one workflow, one app stack, a Beta feature. Your results may differ, and I would genuinely like to hear them. But the pattern it establishes is the checklist line that matters: the validator checks Atlassian's entities, not the internals of app-provided rules. A green deployment is not evidence that your app rules travelled. The docs' unsupported-operations list covers locked and app-managed custom fields, but says nothing either way about app workflow rules, which makes this exactly the kind of gap only a field test finds.
So, the discipline: after deploying any workflow that carries Marketplace rules, open it on the destination and diff the post functions and validators against the source, rule by rule. Two minutes, and the only way to know β
What the documentation does warn about π
Reading the full docs family alongside the experiment, the pattern is that the tool is additive-biased: additions deploy well, removals mostly do not. Removing a custom field option, a default value, a status from a workflow, a work type from a scheme: all excluded, all "do it manually on the destination." You can promote new configuration; you cannot promote a cleanup.
Add the smaller surprises: new filters arrive on the destination as private regardless of source permissions, automation rules deploy but their connections need rewiring, media does not travel (request type icons included), project names and keys do not update, and team-managed entities are not supported at all. And one line from the docs that retires an old habit: Atlassian now explicitly recommends against cloud-to-cloud copying sandbox data upward to production.
Verdict π
This is the beginning of real change management for Jira configuration, and I mean that without irony: named deployments, dependency awareness, pre-flight validation, and an audit log where "recreate it by hand in production and hope" used to live. It is also a Beta with sharp edges, and the sharpest one is silent. Rehearse in a staging sandbox first, exactly as the docs recommend, then deploy, then verify what deployed, especially anything an app put inside your workflows.
If you run your first scan, tell me your change count in the comments π And if you deploy a workflow with marketplace app rules, tell me whether yours travelled whole. A handful of reports here would map this better than any of us can alone.
Sources, all read 4 and 5 August 2026: Atlassian Cloud changes, Jul 27 to Aug 3, Deploy data from sandboxes, Deploy configuration changes from a sandbox, Data deployed from sandboxes, Recommended workflow for complex deployments, plus an end-to-end deployment run on a live Enterprise org, 5 August 2026.
Was this helpful?
Thanks!
Sami Shaik
9 comments