Atlassian open beta deploys Jira config changes from sandbox to production

Atlassian has opened a beta that lets administrators push Jira and Jira Service Management configuration changes from a sandbox straight into production, with no third-party app involved. The company's product manager for sandboxes announced the open beta in an Atlassian Community post on 6 July 2026 — by 14 November it had drawn 8,965 views — and a hands-on write-up published on dev.to shows what the tool does in practice, and where it trips up.

What the beta covers

According to Atlassian's documentation, summarized on dev.to, a deployment can carry workflows, fields, screens, schemes, boards, filters and automation rules to production. The feature comes with restrictions. Only organization administrators can run a deployment; site admins cannot, though an open feature request (CLOUD-13068) asks Atlassian to change that. It requires Jira or Jira Service Management on Premium or Enterprise — one sandbox per app on Premium, up to five on Enterprise — and it works in the regular cloud only, not Atlassian Government Cloud. Team-managed projects are not supported. Deployments are also strictly one-way: the review screen warns that deployed changes "can't be reversed".

A test that stopped before the deploy button

On 14 November the dev.to author ran the beta against their own organization, on a Premium plan, and deliberately stopped at the review screen before committing anything. Their sandbox had never received a copy of production data, and the first scan showed it: about 13 minutes of scanning produced 764 differences, 752 of them additions and 12 modifications.

Their test changes sat in a company-managed project — a new workflow status, a validator, a custom dropdown field, a screen, a shared filter, a project role and an automation rule — each named with a searchable prefix. A rescan after those changes took 5.4 minutes, lifted the difference count to 785, and surfaced 19 matching items.

Ticking four items (the project, the filter, the project role and the automation rule) pulled in auto-selected dependencies, taking the selection to 16; validation then expanded it to 110, mostly fields the project's field scheme relies on. Twelve of those failed, the project among them, so the one thing the author wanted to ship could not go. One warning concerned the Story Points field, which exists on both sites, and the remedy the screen suggests — a full copy of production into the sandbox — would overwrite everything already in it. No deployment ran, and production was untouched afterwards.

Fresh copies, conflicting dates

Atlassian states that deployments are only accurate once the sandbox holds a recent full copy of production. The scan still runs without one, but a never-copied sandbox makes almost everything look new and turns same-name fields into duplicate warnings. The dev.to author skipped the copy to preserve demo data in the sandbox and suspects that choice explains the validation errors.

The cut-off dates are inconsistent, too. The deployment banner asked for a copy made on or after 7 February 2026 for Jira configurations (automations excluded), or 17 May 2026 for Jira Service Management configurations and automation rules. Atlassian's recommended-workflow page gives 7 May for that second date, so copies dated between 7 and 17 May satisfy the documentation but not the screen. A full copy also overwrites any Jira Service Management and Product Discovery sandboxes attached to the same Jira-family sandbox.

The workflow itself has seven stages: check the sandbox's last refresh, make changes, create the deployment and pick the production site, search the scan results, select items and inspect what the tool auto-adds, review every error in the side panel, then deploy and read the report.

Why it matters

A built-in path from sandbox to production gives Jira admins a genuine staging step for configuration work — test a workflow or automation rule away from users, then promote it — rather than editing production directly or repeating changes by hand. The dev.to test suggests the tooling takes that seriously: dependencies get pulled in automatically, and errors block the deploy before anything lands. But the constraints are real. Deployments are irreversible, limited to organization admins on Premium or Enterprise plans, exclude team-managed projects, and collapse into noise unless the sandbox carries a fresh copy of production. Teams adopting the beta should treat sandbox refreshes as part of the deployment routine, not an afterthought.