Introduction

When making changes to Jira, whether configuration adjustments or new project modifications, it is advisable to implement these changes in a Jira sandbox environment. However, once you make your changes and configurations in your sandbox, you are presented with a new challenge: Those changes need to make it over to your production Jira environment.  

Moving these changes from a sandbox environment to a production environment can pose problems if you're not careful. The rest of this article will cover a few helpful tips I have personally used in my career as a Jira Administrator. Hopefully, these tips will make your life as an administrator easier when migrating configurations from your sandbox environment to production.

‍

‍

Tip #1 - Change the UI’s Colors of your Jira Sandbox

Tip number one is to change the UI colors of your sandbox. At the very top of every Jira instance, you have the ability to modify the header's color. Change the color of the header to a bold, bright color, which will clearly indicate you are working in a sandbox.  You can also make a few other adjustments, such as changing icons and text color. I recommend applying a distinctive red color to the entire header in your sandbox environment. This will serve as a clear signal to you and any other administrators using the sandbox, ensuring they know they are working within the sandbox environment.

‍

‍

‍

‍

Your sandbox’s navigation header is now a bright red that will help your Jira Administrators remember that they are no longer making changes to their production environment.

‍

‍

Furthermore, I suggest adding a banner that indicates 'Sandbox' or something similarly unmistakable.

‍

‍

‍

‍

With both of these techniques, your Jira administrators should have an easier time knowing which environment they are in and minimize the chances of making mistakes.

Jira's interface is plain, which makes it easy to forget which environment you're in. The only key indicator an admin has to know which environment they are in is to reference the URL, as the sandbox includes the word 'sandbox' in the URL. However, this subtle cue is often overlooked, leading administrators to make changes in the wrong environment inadvertently.

One additional thing that can be quite helpful is to have two monitors. Place your sandbox on one monitor and your production instance on the other, now clearly indicated by different colors. Keep them in these designated locations and avoid switching them. This way, you can build muscle memory and always know that your left screen is for the sandbox and your right screen is for production.

‍

‍

Tip #2 - Determine if you need to make a fresh copy of production Jira over to your sandbox

This next tip is essential before you delve too deeply into making configuration changes in your sandbox. You need to make a crucial decision early on. When you first create a sandbox, it starts as a blank slate with no projects, configurations, or customizations. You have two options: you can either continue with this empty sandbox environment or, if you prefer, you can copy your production data into your sandbox. This will bring over your screens, workflows, and all project information but not automation rules from production. Almost everything else is ported over into your sandbox. You want to make this decision before you start making changes in your sandbox.

Do you want to start fresh, making changes in a completely pristine, untouched sandbox environment? Or do you want to work with existing configurations from your production environment? Most of the time, when I make changes in my sandbox environment, I work with configurations from production. So, my preference is always to copy over my production data to my sandbox and proceed from there.

If you don't make this decision at the beginning of your configuration change journey (step zero), you'll face a real challenge if you change your mind later. If you start making changes in the sandbox without copying your production data and then, a few weeks or months down the line, you decide you want that production data, you'll overwrite all the work you've done in the sandbox during that time, which isn't ideal. Alternatively, you can use a third-party application such as Salto to cherry-pick specific changes from production (or your sandbox) that you want to migrate over without overwriting your sandbox completely.

There are a couple of important points I'd like to highlight. First, as of now, you are only allowed to have one sandbox environment per each Atlassian Cloud Premium product you have. However, Atlassian is currently testing the ability to create multiple sandboxes, so the information in this article may change. It's essential to keep an eye on any updates from Atlassian regarding the above.

Second, it's crucial to exercise caution when others use your sandbox as if it were a production environment. Often, people make a copy of their production environment and move it to the sandbox. This sandbox may stay active for six months or even a year, during which numerous changes that haven't been synchronized with the production environment might have been made. You could face a significant problem if you ever want to copy the production environment back to your sandbox. Doing so means accepting the risk of completely overwriting any changes in your sandbox that haven't made it to the production environment.  Salto can help you cherry-pick specific configurations to avoid this limitation.

‍

‍

Tip #3 - Backup Jira sandbox and Jira production before doing any significant changes

Before making any significant changes to your sandbox or production environment, always create a backup of your current setup. This precautionary measure can save you from potential issues in the future. It is always prudent to have a backup in case something goes wrong. You never know when you might accidentally delete important data, make an unintended change, or lose critical configurations. Therefore, it's essential to maintain backups of both your production and sandbox environments before embarking on significant changes.

There are a couple of different ways to do this. First, if you are on a budget, Jira does have a free, out-of-the-box backup solution. This solution is ineffective because, since you're working with Jira Cloud, Jira Cloud is always active. You cannot shut off the service, so you run the risk that, at some point, a user may log in and make changes that will not be captured if you have to restore from a backup. However, it's better than having nothing, and is entirely free.  Hopefully, you won't need it if you're a perfect admin.

The other option is to utilize a third-party plugin like Salto that handles your backups. These backup solutions are usually more feature-rich, offering encryption and the ability to restore configurations and entire projects, issues, and other data. I highly recommend considering it, especially if you frequently make changes to your environments.

‍

‍

Tip #4 - Double-check that custom fields, screens, and workflow names aren’t already taken in your production environment

When you're preparing to recreate or transfer your changes from your sandbox to your production environment, I recommend always double-checking that you don't already have the same custom fields, screens, workflows, statuses, etc., in your production environment. The last thing you want is to create duplicates with the same names. So, before you proceed with the migration, make sure to thoroughly compare your production environment with what you're bringing over from your sandbox. Check for duplicates, as it can be very confusing when you have two fields that are exactly the same.  Utilizing a third-party configuration manager, like Salto, will be very helpful here as it can do that analysis for you and help you see if you have duplicate names/configurations.

‍

‍

Tip #5 - Clean up as you configure

When making changes in your sandbox, it's easy to find yourself caught in the heat of the moment, rapidly making a high number of adjustments. This can happen when things are not working out, and, given the experimental nature of a sandbox environment, you keep iterating and trying various techniques, methods, and configuration changes in quick succession. This approach often creates a significant amount of clutter in your sandbox.

One recommendation is to clean up as you make your configuration changes. This is crucial, especially if you have not been diligent with your naming conventions. Without proper cleanup, you may be confused when moving those changes from your sandbox to production. I speak from experience; I've accidentally copied over the wrong configuration change due to unclear naming!

Use highly descriptive naming conventions as a sub-tip when creating fields, screens, workflows, statuses, or any other components. Choose names that make it easy for you to identify, and be sure you're bringing the correct configurations to production.

‍

Tip #6 - Migration Strategy

Finally, when it comes time to move your configuration changes from your sandbox to production, there's a specific order of operations that I typically follow. Believe it or not, the order in which you do things matters in Jira. I strongly recommend following the strategy I'm outlining below. Doing so will significantly increase your chances of success and drastically reduce confusion and frustrations when your migrations are not going well.  Using an app like Salto will make this process much easier because their impact analysis feature will find any dependencies for you, making migrations frictionless.

• Start with any Issue Type changes, as everything else depends on these.
• Do the workflows next, as those are the most important and time-consuming. Since workflows are applied to Issue Types, you can see why having your Issue Types in place before you start making Workflows is essential.
• Next, create your Custom Fields.  Don’t worry about having the screens just yet.  You will do that in the next step.
• After Custom Fields, work on the Screens, as you need the fields to exist before you put them on a screen.
• Work on the rest of the configurations (permissions, priorities, etc).  
• Apply everything else that is needed to your project per your changes.

Summary

There are several approaches to transferring your configurations from a sandbox to a production environment. I've compiled a set of valuable tips based on my experience with various migrations throughout my career. These suggestions aim to help you avoid headaches and frustrations commonly associated with moving from a Jira sandbox to a Jira production environment.

These six tips are precious if you're new to the migration process. I hope they prove beneficial and successfully guide you through moving your changes from the sandbox to the production environment. Best of luck!