Hi admins đź‘‹
Welcome back to the Admin Deep Dive series! Change management was a hot topic at Team '26, and many of you expressed interest in learning more about the capabilities. So we’re spotlighting the admin tools that help you manage change across your Atlassian environments in this edition.
Whether a change comes from your team or Atlassian, you need a safe way to test it and roll it out when you're ready, without disrupting anyone's work. Sandboxes, configuration promotion, and change pipelines do exactly that by letting you capture the upside of change without the risks. Let’s dive in!
Sandboxes
Sandboxes are isolated environments that allow you to build, customize, and validate changes before deploying them to production. Different teams can simultaneously test new Marketplace apps, workflow updates, and upcoming platform releases in their own sandboxes. No more queuing and waiting on each other. And because all of this happens in sandboxes rather than production sites, mistakes won't break anyone's work, and changes go live only after they've been tested and approved.
Plan eligibility: Enterprise plan customers get five sandboxes, and Premium plan customers get one sandbox. Visit this page if you’re interested in purchasing more sandboxes.
How it works
From Atlassian Administration, you can spin up isolated sandbox environments linked directly to your production site. You can populate your sandbox and test with real data by performing a full data copy or copying specific Jira projects and Confluence spaces. Automations are disabled by default, so your teams can test freely without disruptions or risk to production data.
Need to create a sandbox? Check out the documentation to learn more.
Best practices for using sandboxes
- Give every sandbox a clear purpose and owner: Assign each sandbox a “job”, such as admin development, UAT, release preview, or app validation. Use naming conventions and name an owner so admins know which sandboxes are for experiments or formal validation.
- Pair sandboxes with release tracks: We recommend configuring your production site to the bundled release track and your linked sandbox site to the preview release track. This way, admins can test upcoming Atlassian changes in a sandbox about a month before they reach production. Learn more about controlling the rollout of new features.
- Watch the inactivity timer: Sandboxes are not a long-term storage mechanism, as they go offline after 28 days without use. They can be restored for 30 days before being permanently deleted.
Configuration promotion for sandboxes
Configuration promotion lets you make configuration changes in a sandbox environment, validate with real project data, and promote the configurations directly to a designated production site. By giving you full visibility into what’s changing and clear traceability with audit trails, you can rest assured that what you tested is exactly what goes into production. This means safer deployments, less disruption for users, and more reliable governance as teams scale.
Plan eligibility: Configuration Promotion is currently in open beta for Jira and Jira Service Management on Premium and Enterprise plans.
What does configuration promotion support?
For supported Jira configurations (see full list), you can:
- Deploy selectively: Move only the configurations you need from the sandbox to production.
- Compare environments: Get clear, side-by-side comparisons between your sandbox and production environments to spot differences instantly.
- Assess impact: Understand dependencies and potential effects before deployment to ensure 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.
Check out this video to learn more.
Ready to try out configuration promotion? Learn more.
Change pipelines
Change pipelines give you a structured, repeatable way to test and prepare for updates to your Atlassian apps before they reach your users. To start, you set up sandboxes for each stage of your review process, like stakeholder sign-off or user acceptance testing. Updates to your Atlassian apps move through those stages one at a time on a predictable schedule, giving you visibility into which stage each update is in.
For Jira seasonal releases, you get up to 60 days to review, test, and sign off. That gives your stakeholders time to review changes, document them, and update training and support materials before anything goes live.
With change pipelines, you get:
- Structured testing that fits your process: set a separate stage for each type of review
- Predictable timing: know when each update will arrive at each stage
- More control over rollout: move updates forward only when your team is ready
Plan eligibility: Change Pipelines is currently in closed beta for Enterprise plan customers. We’ll share more details about which plans it’s available to soon.
Check out this video to see it in action.
Interested in joining the closed beta? Sign up here.
That's a wrap for this month's deep dive! Managing change gets a whole lot easier when you can see what's changing and have a clear path to production, all within Atlassian Administration.
🗞️ Don’t want to miss out on future editions? Bookmark this Admin Essential Library, which we update as new Admin Digests and Admin Deep Dives are published.
