3 top tips for promoting Jira configuration changes from staging to production

Change is an unavoidable part of a Jira Admin's work life. When you make changes directly into a production environment, it may save you time and money, but it can also be a risky approach. If you make a change and something goes wrong, the resulting downtime can quickly become expensive. So how can you optimise any change management objectives to make sure your work reduces as much risk as possible? 

From implementing a solid risk management strategy to involving your end users, and maintaining the control of the process, there are several things you can do as a Jira Admin to reduce risk when promoting Jira configuration changes from staging to production. Here are three of our top tips to get you started:

Risk management is the process of identifying and predicting risks, issues or potential threats before they happen. This enables organisations to prepare well in advance with risk-proof procedures to lessen any serious impact, or at the very least help cope with the impact. Organisations should conduct a detailed and realistic evaluation of the true level of risk and plan accordingly. With a proper risk management plan, one can easily prepare for the worst, minimise risks, and even save extra costs and time. 

How does risk management apply to Jira?

In a workflow, for example, a direct change made into a production environment is unique, and because of this it is crucial to conduct a risk management analysis. This allows teams to rapidly identify risks associated with change, and what must be planned to minimise these risks. This includes cases when a Jira Admin manually makes a configuration change - they should follow a defined procedure that minimises the chance of errors occurring. The best way to truly understand risk tolerance is to gain a deep knowledge of how your organisation’s business, regulatory and compliance obligations are set out and what they mean.

What about risk management in agile teams?

For agile teams, risk management means being proactive instead of reactive. Effective risk management involves defining change types by risk, and the appropriate levels of validation required when making changes directly into a production environment. 

Suppose you have a development instance where some changes have been made to the configuration of some projects. End users have seen and approved these changes, and you now want to transport these changes to your production instance (PROD). It is best practice to know which projects you have in your PROD instance and what they are being used for in order to better assess the risks derived from these changes. 

When should configuration promotions take place?

It’s important to be able to judge and estimate the risk to your business if projects are unavailable for even a minute. With that in mind, it’s generally recommended to perform the configuration promotion out of office hours, to reduce the impact of any eventual downtime and allow enough time for the promotion to run.

What else should Jira Admins do before promoting configuration changes?

Jira Admins should carefully preview which configuration items will change, and check where they are used in their Jira PROD instance. This is to assess any potential effect of changes to those objects. If there are many batches of changes, and the risks are high, consider testing the configuration promotion process first on a clone of PROD. 

Jira Admins can save time by automating the process of copying configuration changes from one instance to another, and thus reduce the chance of any human errors happening during the manual reproduction of configuration changes.

In any change management process, it’s recommended to involve wider teams. When performing Jira configuration changes, your Jira end users should be factored into your plans.

When all changes are implemented in a staging/test instance, involve users to review and validate jointly before applying the changes to the PROD. Ask users to view, feed back on and approve the new configuration, and in turn share your risk analysis results with them. In doing so, you’ll not only be communicating change transparently, but also reducing risk and ensuring the quality of the new configuration is high, and up to the required standards. Depending on the scope of proposed changes, some of the things to check for include:

• Ensuring workflows are complete with all required states and transitions,
• Checking if there are fields to hold all required information.
• Validating with end users the chosen time for the promotion of the new configuration to PROD

In some cases, this user involvement and acceptance will be mandatory, and according to predetermined company procedures. The most important step in this process is validating the new configuration before applying it to PROD.

Change management is complex because of audit and compliance requirements and the need to assess and minimise the impact of changes. Unsurprisingly, this can be incredibly time-consuming and laborious. For Jira Admins who make frequent changes to their Jira instance to constantly improve and meet ever-evolving user needs, change management can be particularly tricky. This makes it important for Jira Admins to maintain control and awareness of what’s happening at every stage of the configuration process. These top tips will make this easier:

• Preview changes to the config in PROD, and check that these are in line with expectations. If required, individual changes can then be enabled or disabled. 
• Keep a runbook with all the steps taken, and the options used on the configuration tool, so that they can be repeated exactly when applied to PROD. This is particularly important if a previous test was run on a clone of PROD.
• Keep a record of all the changes that are actually applied to PROD.
• Automate the process of replicating the configuration changes in DEV/STAGING to PROD - don’t try to repeat them manually!