Deploy configuration changes from Sandbox - now in Open Beta!

[#1]

Hello Atlassian Community,

I’m Adithya, Product Manager for Sandboxes at Atlassian, and I’m excited to share that Sandbox Configuration Deployment is now available in open beta to all customers on Enterprise and Premium plans for Jira and Jira Service Management. This capability is currently being rolled out, and should be available to you over the next few days.

For many admins, moving configuration changes from a sandbox to production is still too manual, risky, and time-consuming. Teams validate changes in a sandbox, but then have to recreate those same changes in production or in another sandbox, creating extra work, slowing down change, and increasing the chance of human error.

With Sandbox Configuration Deployment, we’re working to make that process much simpler. You can review configuration changes made in a sandbox, understand dependencies, and deploy selected changes to production or to another sandbox linked to the same production environment.

Why this matters?

This capability is designed to help admins:

• Move faster: Reduce the manual effort involved in recreating tested configuration changes.

• Deploy with more confidence: Review changes and dependencies before deployment.

• Stay in control: Select the changes you want to deploy, while ensuring required dependencies move with them.

• Scale admin workflows more effectively: Support more structured sandbox → higher environment workflows for Jira and JSM configuration changes.

What does the capability support?

⚡ Deploy Selectively: Move only the configurations you need from sandbox to production, whether new additions or strategic modifications. This is supported for a wide range of Jira and JSM configuration such as workflows, screens, custom fields etc - the entire list can be found here

🔍 Compare Environments: Get clear, side-by-side comparisons between sandbox and production to spot crucial differences instantly.

🎯 Assess Impact: Understand dependencies and potential effects before deployment, ensuring smooth transitions every time.

✅ Validate Changes: Run pre-flight checks to catch issues before they affect your production environment.

📊 Track Outcomes: Receive post-deployment reports with summaries and actionable remediation steps when needed.

What’s new in open beta?

Thank you to everyone who participated in the closed beta and shared feedback with us. Your input told us what improvements mattered most in real-world workflows, and it directly shaped what we’re launching in open beta and beyond.

Since closed beta, we’ve made several major improvements:

• Support for new configurations: We now support changes made to Automations with Jira and Jira Service Management entities, Asset Schemas, Change Management and Incident Management settings in Jira Service Management

• Deploy newly created projects from a sandbox: Brand new projects created in a sandbox can now be deployed together with their configuration. This does not include issue data.

• Performance, reliability and bug fixes: The reliability and performance problems that interrupted some deployments earlier in the beta have been fixed, and bugs such as errors during selection, missing workflow layouts, etc have been resolved.

Here’s a quick demo of the experience: https://www.loom.com/share/6d555628ec0947aebc4e4e3ae8c9eccf

What this capability is designed for:

Sandbox Configuration Deployment is designed for promoting configuration changes made as part of your operational cloud change workflow. This capability works best when teams have a sandbox that is a close replica of their production - When they create or modify configurations they can validate those changes in a Sandboxes, see a review of what deploying those changes to production would look like, and finally deploy those changes to a linked environment as part of their normal change management process.

Prerequisite: To use this capability to deploy changes from a particular sandbox, you must have performed a full data copy from production to sandbox on or after May 7, 2026 for Jira Service Management configuratioin, and December 7, 2025 for Jira configuration.

Refer to these docs to get started -

• What data is currently supported:
  https://support.atlassian.com/organization-administration/docs/data-deployed-from-sandboxes/

• Recommended workflow for deployments:
  https://support.atlassian.com/organization-administration/docs/recommended-workflow-for-deployments/

• How to deploy configuration changes from a sandbox:
  https://support.atlassian.com/organization-administration/docs/deploy-configuration-changes-from-a-sandbox/

Important: what this should not be used for

This capability should not be used to selectively deploy configuration that were brought into the sandbox through:

• Restores from Atlassian backup and restore

• Data Center to Cloud (DC2C) migration through JCMA

• Other Marketplace Apps

If you want support for DC2C migration workflows or backup-and-restore-based workflows, please vote on this JAC ticket for DC2C workflows and this ticket for backup and restore based workflows, so we can better understand demand and prioritize accordingly. If you'd like to see a similar capability for Confluence, vote here, and share the changes that matter the most to you in the ticket's comments section. 

Who should try this?

This open beta may be a good fit if your team:

• Uses Jira and Jira Service Management sandboxes to test and validate configuration changes before rollout

• Wants to reduce manual rework across environments

• Needs a more structured and reviewable deployment workflow for admin changes

We’d love your feedback

Over the next months, we’ll be making several new exciting additions to this capability and we’ll keep improving the experience based on what we hear from customers using it in real workflows.

We’d especially love feedback on:

• Coverage of supported Jira and JSM configuration areas

• Performance at your org’s scale

• The clarity and usefulness of the deployment preview

• Gaps that still make manual work necessary

If you have any questions, drop them in the comments section, or setup time with me to chat about it using this link. Thanks again, and we’re excited to hear what you think and how you plan to use this!

[Arkadiusz Wroblewski]

Jeez i waited on it so long time. Thank you.

Testing in Production System ? Bad idea :D Test and Deploy from Sandox? YES!!!

[Roksolana SLiusar]

This is a step forward! Hope it will work as described

What about Cloning of prod to sandbox? 
Any planned enhancements? 

[Ignacio Pulgar]

Hello @Adithya Ramesh ,

Configuration deployments among environments is very much needed, thanks!

Please correct me if I'm wrong in any of the following statements.

Sandboxes are not covered by our SLAs with Atlassian, unlike normal Jira instances.

While Atlassian Support always tends to help, we are not legally covered when using sandboxes.

This means a bug impacting a sandbox is not officially supported by Atlassian.

If Atlassian lacks any legal enforcement to fix the bug in a timely manner, that's quite similar to saying Sandboxes are not officially supported by Atlassian.

I think sandboxes should be covered by the same SLAs than our so-called Production instances.

Otherwise, creating a deployment flow among environments not officially supported by Atlassian is a big risk in case a bug or incident impacted any of our sandboxes.

As a result, we are not using sandboxes to build configurations, but normal Production instances instead.

Now that this cool Deployment feature is in Beta, we would like to reconsider our initial choice.

However, lacking official Atlassian Support in sandboxes is a big drawback.

Are there any chances that sandboxes are covered by our SLAs with Atlassian?

Thanks

[Jason Krewson]

I love this! I saw the update in the release notes last week and was so excited that it's coming. Thanks for sharing! 

Deploy configuration changes directly from a sandbox to production environment 

[Gabriel Roth]

When should we expect to start seeing this roll-out? I have checked my sandboxes and DO NOT see any options for creating a deployment as per the Loom content.

[Adithya Ramesh]

Thanks @Roksolana SLiusar !

We are working on improving the performance for copying from prod to sandbox, but I'd love to know if there's any specific improvement that you'd like to see.

[Adithya Ramesh]

Hi @Ignacio Pulgar

Thanks for the feedback, and great question. You're right that sandboxes aren't covered by the same SLAs as production, but I'd love to understand your concern a bit better so we can help.
Generally, when we hear from customers about this, the concern is around performance. From a functional perspective, a sandbox is running the same code base as your production instance, it's essentially a different deployment of the same application. So if a bug exists in your sandbox, that same bug would also exist in production in most cases.

That's actually one of the reasons sandboxes are so useful for testing configuration changes - you're validating against the same underlying system without the risk of impacting live users and data.

Could you help us understand what you're most concerned about? Is it a performance issue you've experienced, a functional bug you've encountered, or something about the deployment itself? That would help us point you in the right direction and make sure we're addressing the right thing.
We'd definitely recommend testing in a sandbox over production when possible - the risk profile is just so much lower, but we want to make sure you feel confident doing so.

[Adithya Ramesh]

Thanks @Arkadiusz Wroblewski ! Would love to hear your experience after you start using this!

[Adithya Ramesh]

Thanks @Jason Krewson ! Excited to see you try this soon!

[Adithya Ramesh]

Hi @Gabriel Roth ! We are actively rolling this change out now - we are hoping to make it available to all customers by the end of next week.

[Ignacio Pulgar]

Hi @Adithya Ramesh ,

Thanks for your answer.

We are mainly concerned about uptime, incident resolution time and performance.

We think those three pillars would need to be solid for pre-production environments too.

If sandboxes always are in the same version than its Production instance with no exceptions, that's definitely good.

So if a bug exists in your sandbox, that same bug would also exist in production in most cases.

If there may be any exceptions, and a bug may be impacting a sandbox instance and not the Production one, we would expect it to be fixed with the same SLA as if it were PROD.

Or at least, have any kind of SLA, even if it were a more flexible one.

But lacking any SLA at all?

Seems like too risky to build anything on top of that...

Imagine we build the Taj-Mahal in a sandbox, just to discover any of these situations (among others):

• The sandbox is down.
• The sandbox is impacted by a bug/incident not impacting PROD which renders the solution useless.
• The sandbox performance is so bad that it is impractical to use it for testing purposes.

No SLAs.

All PROD instances already creating their own tickets, which must be prioritized by Atlassian Support.

It is not hard to imagine a complex incident being closed by Atlassian Support stating something like:

According to our SLAs, sandboxes are not officially supported by Atlassian, therefore, while we have been trying to help in a best effort basis, we regret to inform you we will be closing this ticket, since it is out of the scope of Atlassian Support. We know this decision may be disappointing but...

My main concern is something like this could happen.

Initially, sandboxes were sand boxes.

Now that they are evolving to pre-production environments with deployment capabilities, it would make sense to review SLAs so that we, your customers, feel we are securely building whatever we need, and that we will get all Atlassian help when needed, instead of feeling helpless or assuming too much risk.

Hopefully I explained myself.

Thanks for reading and considering!

Best regards.