Project Summary
We’re actively exploring a new feature that would allow customers to promote changes to configuration made in their Sandbox environment to another sandbox or an associated production environment. We hope this feature will provide increased flexibility for safely implementing changes, allowing customers to adhere to industry-standard enterprise change management practices. We’re currently exploring the feasibility of bringing a portion of this functionality, configuration promotion, to a limited number of customers through a closed beta by the End of 2025.
Publish: 28 Jul 2025
Discuss: 13 Aug 2025
Resolve: 27 Aug 2025
Problem:
Today, customers have an ability to copy data selectively into sandboxes for their testing and experimentation needs. However, a frequent point of friction Admins have shared with Atlassian is the inability to safely and efficiently replicate the changes they’ve made in their Sandboxes in their production environment. This severely impacts the efficacy of change management processes, and increases friction for making changes to their production sites.
Proposed Solution:
As a part of our Beta, we are exploring the support for the deployment of changes to select configuration (currently only Jira config, including, but not limited to workflows, screens, custom fields etc) that are either
- Newly added on the sandbox, or,
- Have been copied from production to sandbox and have been modified on the sandbox
from one sandbox to another, or from the sandbox to it’s linked production site.
What are the salient features?
As a part of the beta, we are exploring to enable an admin to
- Choose from a list of related sandboxes and production the destination that they want to compare their sandbox with.
- View a list of entities that have been added or modified on the sandbox when compared to the destination
- For a particular entity, view how the properties are different in the destination when compared to the source, as well as any dependencies that might be needed for the deployment of that change
- After the entities are selected, view which projects on the destination might be impacted by the selection
- Run a pre-flight check to identify whether the change deployment could cause any errors at the destination
- Post-validation, deploy the changes to the destination
Asks
We would appreciate your insights around:
- How you envision potential collaboration opportunities as we move forward with developing this feature
- What type of extensibility you would like to see us build to complement your product strategy
If you’d like to talk to us regarding this, please schedule 1:1 time through this calendly link. Thank you!
8 Likes
Hi, great idea!
It would be nice to see this extended to (marketplace) apps as well.
Customer could try config changes for apps in sandbox first, and if they play well, deploy them to production. This is what (still) happens in most DC environments.
Even thinking it further, if we could get pre-releases to customers, they could try it in sandbox and when we update the app, they could take over the (maybe needed) config changes to prod as well. However, this needs a pre-release feature to implement as well.
I think this goes in the right direction to offer what people are used to on DC. Bigger companies are usually very reluctant when it comes to “just changing” configuration without testing.
5 Likes
Hey Chris, thanks for the feedback! We definitely have this as a part of our longer term vision to support the promotion of app config changes as well and super glad to know that the idea resonates with you. However, we will likely focus on allowing customers to copy app data and config into the sandbox first, followed by the support for their promotion.
Is ‘pre-flight check’ equivalent to ‘dry-run’? If not, is supporting dry-run (with output) part of the vision? A list of changes that would actually be made (vs. what I think will be made) is very useful when assessing the risk / impact of changes.
Will the changes be replayed in such a way that they are indistinguishable from a user making the changes, either via UI or REST?
Notably, will events be fired for config item creation and update, so that apps can react?
Hey @billjamison! Thanks, that’s a great piece of feedback. Pre-flight checks are, for the purposes of the Beta, only static validations that can identify erroneous changes to data - but we will provide the ability to see which projects this change would impact. In the long term, we might introduce capabilities to view a dry-run report of the operation.
Hi @jechlin, the changes will be made in line with how changes are made today during a cloud-to-cloud migration - via REST APIs.
What about rollbacks? Say there is some sort of error during deployment to prod, leaving prod in an indeterminate state - will it be possible to roll back the changes to the previous known good configuration?
While you’re at it can you make sure that billing/licensing/payment is not a roadblock to install apps onto sandboxes?
eg do so diligently:
- Ensure that installation funnel metrics are being tracked.
- Log the instance URL and requests, including user-facing error/success messages.
- You’ll then know the install success % and can debug why that number is awful and how to improve those user-facing messages.
Over the years I’ve had dozens of support tickets where users are unable to install onto a sandbox and get useless error messages.
Across the marketplace there would be an ungodly amount of lost customers and revenue due to drop-offs. I’ve informed Atlassian multiple times but these problems never seem to get fixed.
1 Like
This is something that we are actively exploring right no @JefferyC - though, unfortunately, it is not going to be available for the Closed Beta
Hey Nathan, this makes sense. We’re working on expanding the breadth of our observability instrumentation, which will give us the visibility we need to proactively triage and address a much broader set of issues around reliability. This should allow us to measure exactly where there’s friction in that experience and eliminate it over time. However, as we’re working on those improvements, if you have anecdotal feedback around friction that’s clearly recurring, please let me know. That’s something that the team and I can investigate without having to wait for new tools to surface that signal to us.
1 Like