Introduction

A sandbox is an isolated environment, a clone of your Atlassian production environment. The sandbox allows users to try different features, configurations, and customizations without impacting their production environment or real data. It is a valuable resource for learning, training, testing new features, and developing custom solutions.

A prerequisite for using the sandbox is having a Premium or Enterprise Atlassian license plan. If you have a Standard license, upgrade to Premium or Enterprise to use the sandbox feature. See Compare plans and pricing for more details about the different plans.

Let’s check out the main use cases for using a Jira sandbox.

‍

‍

Use cases for using a Jira sandbox

‍

Developing and testing new configurations 

This is a sandbox's most common use case. As a Jira admin, your main day-to-day work is developing and maintaining configurations. This can be adding or updating schemes, handling security and permissions, adding automation rules, writing code in Scriptrunner, and more. In most cases, you need real production data to develop and test your changes.

For example, let’s say you want to add a new custom field to one of the screens that calculates data from different Jira elements. In this case, you want the users to see the new field only after you complete the calculation development and check relevant scenarios. If you work in the production environment directly, the users will see the field before you finish developing and testing your application.

In other cases, you want to perform configuration changes, let specific users test them, and get feedback before moving the changes to production. In a sandbox, you can let these users try the new configuration changes at their own pace, as it does not impact the production instance. Without a sandbox, you make all changes directly in the production Jira instance; any changes will immediately affect your production environment.

‍

Evaluation of new apps

Another use for a sandbox is evaluating new apps from the Atlassian marketplace. When evaluating one of the 5500+ apps in the Atlassian marketplace, you’ll usually want to evaluate and play with the app using your real data. Doing so in a production instance is not recommended and can cause the following issues:

1. You are limited to testing the app without changing data in your instance, as you work directly in a production instance.
2. Once installation of the app is complete, it will be visible to all users, who may then start using the app without knowing it is in the evaluation process.
3. You do not know the impact that installing and configuring the app will have on your instance or your data. For example, some apps may add elements to your instance.

Evaluating the app in a sandbox environment is the recommended solution. By leveraging a sandbox environment, you can confidently install and configure new apps without worrying about their impact on live production data. This approach lets you thoroughly evaluate an app’s features, functionalities, and compatibility with your existing workflows.

‍

User training and onboarding sessions

A sandbox is a great solution for user training as it allows these users to use Jira with data similar to production, without impacting the live instance. A sandbox can also be used for training or demo sessions. For example, if you’re an admin presenting a demo for a new configuration or app, you can present your demo in a sandbox environment, including data changes without the risk of impacting the production instance.

‍

Implementing version control methods and a merger to the production environment 

Once you have the option of a sandbox, it enables you to set DevOps processes for configuration changes. Instead of developing in the sandbox and, after testing, manually moving the change to the production instance, you can use a tool like Salto to better manage your configuration changes. With Salto, you can compare production and sandbox environments, check the dependencies of elements, and perform a cherry-pick merge to the desired changes from the sandbox to the production instance. In this way, you can manage and track every change that moves to production and will even be able to roll back changes if something goes wrong.

By using this method, Jira admins can benefit from the same advantages as developers with efficient DevOps processes and risk reductions.

‍

Best practices for sandbox use (for Jira admins)

‍

Setting up the Jira sandbox environment

As a Jira organization admin with a Premium or Enterprise license plan, creating a new sandbox is simple.

To create a new sandbox:

From the main menu, choose Administration or go to admin.atlassian.com

‍

‍

Then, select Products > Sandbox and Create Sandbox.

Choose a product (in our case, Jira Software) and click Create.

‍

‍

Your sandbox is now being created.

‍

‍

You can leave the page, and you’ll be notified once the sandbox has been created.

‍

‍

Once it’s ready, the following notification will appear:

‍

‍

You can see here that your sandbox is ready to go.

‍

‍

In the sidebar, you’ll see the sandbox URL. When you create a new sandbox, it will create a new site with a URL ending in “sandbox-<number>.

‍

‍

Note that creating a sandbox does not copy your data from the production environment to the sandbox. When you create a sandbox, it will be empty until you decide to copy your data.

‍

Periodically copying data from production to sandbox 

When you copy data from your production environment to its sandbox, keep in mind that you'll replace any existing data in your sandbox with the new data that gets copied over. Every new data copy action will overwrite any existing data in your sandbox. 

From the sandbox page, choose “Copy production data”. 

‍

‍

You’ll now have the option to copy with or without media files. Copying media files to the sandbox may take more time, depending on the number of media files in your production instance.

‍

‍

Copying production data can take a long time, depending on the size of your site. If your instance is quite big it can take more than one day. 

The status will change to “Copying Data”.

‍

‍

Note that during the time it takes for data to import from production to sandbox, your sandbox will not be accessible.

What to consider when copying data:

1. Time: Copying a sandbox can be a time-consuming process, often taking more than a day to complete. It's crucial to allocate sufficient time and plan accordingly. Starting the copy process before a weekend or during a period of low activity may help in minimizing disruption.

2. Sandbox availability: When initiating the data copy, the sandbox will become inaccessible while it imports the new data, and all changes made within it will be deleted. Inform all sandbox users in advance about this unavailability and about the deletion of all changes made to the sandbox during this time. Ensure that all Jira admins are aware of the timing and encourage them to merge any relevant changes to the production environment before the copy begins.

3. URL: If you would like to have a new URL for the new sandbox, you’ll need to delete the sandbox, create it, and then copy the data. The new sandbox will get a new, unique URL, and the “sandbox-<number>” will be different from that of the previous sandbox. In this case, make sure to notify the relevant users about the new URL.

4. Apps: Copying data to a new sandbox will not automatically copy the apps from the production instance. There is a difference between apps with a paid subscription and apps without a paid subscription. See Manage Marketplace and Atlassian apps in your sandbox for more information about app behavior in your sandbox environment.

‍

Tips for Jira admins

‍

Sandbox performance 

As a sandbox is not a production environment, Atlassian doesn't guarantee sandbox performance or data retention if it is destroyed. Your sandbox will not be covered by the SLAs that cover products. For this reason, it's recommended to not use a sandbox as the sole location of your data.

‍

Multi-sandbox option

Although Atlassian currently does not support more than one sandbox, many customers do wish to have more than one sandbox environment. This feature is currently being developed (see Multiple Sandboxes user story at Atlassian), and you can also leave a comment and see the progress. Atlassian’s ETA for having 2 sandboxes is Q2 of 2024.

‍

Copy data limitations

Automation rules currently aren’t automatically copied into a sandbox. Suppose you need the automation rules in the sandbox environment. You can manually export them from the production instance to a JSON file and then import them to the sandbox environment. This may be a good solution when you create a new sandbox environment because the rules will be added to the sandbox. Still, you cannot update the automation rules later, as the export/import can only create new automations in the target environment, not update them.

See Atlassian’s guide on how to import and export Jira automation rules, and read the limitations carefully.

Another way to copy the automation rules between instances is by using tools that assist with element migration between instances, such as Salto, which compares and merges changes between instances. The advantage of using this tool is the option to cherry-pick the elements you want to merge and update existing elements—in this case, automation rules—in the target environment.

Another limitation is your instance size. The data copy process won't work if the uncompressed XML file size for your Jira product is over 40GB. Contact Atlassian support if you want to copy files over 40GB for Jira products.

‍

‍

Conclusion

In conclusion, utilizing a Jira sandbox offers numerous benefits for development, testing, training, and evaluating new configurations and apps. It provides a controlled environment to minimize risks and enhance the overall effectiveness of your Jira instance and day-to-day work as a Jira administrator. Using a sandbox also lets you leverage DevOps methods for configuration changes.

See Atlassian’s plans for (and the status of) the next sandbox-supported features:

Sandbox environment for Cloud (see sub-tasks for specific features).