#JiraHeroes May '22 Spotlight: Daniel Cave

[#1]

At Atlassian, we take great pride in the software we ship, and even greater pride in the success our customers achieve when they use our products. #JiraHeroes is our new monthly spotlight series where we ask customers to share their success stories with Jira Software. We hope that customers will find inspiration on how to overcome their own challenges by hearing how our #JiraHeroes overcame theirs.

This month, we’re featuring Daniel Cave, a Senior Infrastructure Engineer at Sophos, who shares how he utilized the Jira Software and Microsoft Teams integration to streamline his company’s migration from server to cloud.

Please introduce yourself! Tell us about where you work, your role, and the team you're on.

Hello Community! My name is Daniel Cave, and I’m a Senior Infrastructure Engineer at Sophos, a leading cyber security company. Unlike most comic books, my heroics are focused on enabling business productivity through greater mastery of corporate tooling. For the past 16 months, I’ve worked to move our Jira Software and Confluence instances to the Atlassian Cloud platform so that our teams can focus less on maintaining the infrastructure and focus more on becoming advocates and solution enablers with these tools. In my spare time, I keep fit by running around after my 3-year-old daughter.

Tell me about what your company was trying to achieve and how that informed the way you thought about moving from self-hosted to Cloud.

As a company, we have been consumers of Jira Software, Confluence, and Bitbucket for over a decade. In 2021, we took the leap forward to move our business from server to cloud.

Why did we move to the cloud? Staying ahead in the cyber security space requires focus and coordination. Whilst we could achieve that with self-hosted products, we frequently found that the investment in maintaining the platform was hampering our ability to deliver best practice and standardization within the environment. Too often, our Jira Admins were planning upgrades and tweaking infrastructure settings when they could’ve been researching new features and enabling better adoption. Maintaining the server was taking focus away from our organizational goals, so we decided to invest the time needed to move to the cloud now and benefit from a managed platform in the future.

Our journey to the cloud took approximately 20 months. During the first 6 months, we assessed how moving to the cloud would meet our organizational needs. We had been tracking Atlassian’s cloud growth for a number of years, and once attachment storage limits grew to a level that met our business needs, we wanted to understand how we could make the transition as smooth as possible. We took several months to identify what subscription level we needed to meet our requirements, what the migration tooling options were, and the functionality disparity between what we had and what the cloud could offer. Ultimately, the largest part of the research phase was focused on evaluating add-on vendors – specifically, what they could deliver in the cloud as well and their migration solution. We used usage metrics, such as macro usage within Confluence, to measure how frequently add-ons were being used and made hard choices about which add-ons we would continue with.

The output of the research phase was invaluable – we were able to deliver the migration at an acceptable speed because we were able to disclose which areas would need additional investment post-migration to our business customers early on. This was essential as tooling that came with the cloud was vastly different from what it was before. Additionally, we also determined very early that the only method we could use to migrate was a number of smaller moves rather than the single XML backup migration. A single big-bang approach has its place, but our company operates globally and does not stop for the weekend. This means we can’t have a single period of downtime across all of our business units and thus had to move in stages.

During the execution phase, we needed to coordinate a huge amount of process and technical change. In addition to migration tooling, we needed multiple Jira Software projects and several dedicated Confluence spaces to just track the effort of managing all the information we received, processed, and delivered as actions. Luckily, we learned some tricks along the way to streamline the migration to cloud, such as a better link between Jira Software to Microsoft Teams. By integrating Jira Software with Microsoft Teams, we were better able to coordinate change requests by using Microsoft Teams cards, a UI container commonly used in Teams apps, to inform our technical teams. This allowed us to fully remove email as our communication method on all Jira Software issues.

How did you leverage the Jira Software and Microsoft Teams integration to streamline your transition from server to cloud?

The two areas where this really made the difference was in monitoring migration plans and tracking bug creation.

For those of you who have used either Jira Cloud Migration Assistant or Confluence Cloud Migration Assistant, you will know that tracking migration plans requires a bit of manual work. Admins will be required to check the status and outcome via the UI or via directly querying the database.

By working with the migration team, we discovered a third option: the migration tools have an undocumented API. By simply connecting to https://{base-url}/rest/migration/latest/plan with a Jira or Confluence Admin account, one can pull a description of the current status of all migration plans. With a little trial and error we were able to build a monitoring tool that could automatically:

1. Record the creation of a migration plan
2. Record the time when a plan was started
3. Record the time and exit status of a plan when it completed

Now all we needed was a delivery mechanism for this information, something that Microsoft Teams offers via cards. With a bit of Python, a Lambda function and a DynamDB table we were able to deliver push messages to our migration team.

1. When a plan started
2. When a plan completed
   • Its success/failure message
   • Its complete runtime

The code was running on a near continuous schedule, so we were receiving these messages nearly synchronously with the event. Given this capability, we were able to effectively manage multiple migration environments without the need to manually check migration status in multiple instances of the Jira and Confluence UI. We were able to spot plan failures more quickly and this allowed Atlassian support more time to investigate issues. As most of the monitoring was replaced with a single Lambda function, we did not need additional staff overhead so the team were able to focus on planning and executing the migration. We were also able to provide much better timing for our production migration phase which allowed us to deliver on a much tighter schedule, which meant less downtime for our customers.

In addition to greater visibility of our migration progress, Jira Software and Microsoft Teams allowed us to better support our testing processes. Through the use of Jira Automation rules and a webhook in Microsoft Teams, we were able to send notification of bugs almost immediately after our customers raised them in Jia without writing a single line of code.This allowed us to better stay on top of the challenges that we faced during the migration and gave our customers the confidence that we were working on their issues as a priority. It also allowed our project manager to identify areas of our business with active testing and who would need more direct support without having to wait for progress meetings.

Ultimately, we were able to deliver the migration at a much lower cost to the business. We have migrated over 1.2 million Jira Software issues in 680 projects and 250 spaces with hundreds of thousands of pages in 14 months.

What are some best practices you could share to help other admins who are looking to extend capabilities via apps?

Urgent issues should trigger push messages. Jira Automation, available in the Cloud product, has a built-in mechanism for interacting with Teams or Slack. Picking what is a blocker and having its own place will help your engineers to better respond to truly urgent

Automate what matters first. Whilst there might be a desire to automate everything, you will eventually hit a point of diminishing returns. Never lose sight of your main goal and learn to be realistic.

Better measurements leads to better results. You cannot effectively plan a complicated project without knowing what measurements are needed to confirm effectiveness. In this case, you cannot plan a cut over without accurate timings and confirming quality of deliverable. If a tool does not provide you with both directly, you might have to find a way to generate it indirectly.

In general, what is one pro-tip you could give to someone who’s a new Jira admin?

As someone who went from zero to Admin in less than 3 months, I’d recommend taking a look at the API once you have the basics down. The API resources available for Jira Software and Confluence Cloud are great, and the documentation makes it really easy to work with.

Whilst this might not be how you achieve every problem, knowing what you can do programmatically allows you to force multiply where you need to. With some fairly basic scripts you can cut days off an admin task and focus on delivering value in other areas.

Thank you for taking the time to read my story! How was your migration from server to cloud? Please share your tips with the Community in the comments section below.

---

Thank you so much for sharing your insights, Daniel! ❤️

Are you inspired by Daniel's story? Do you have a story of your own that you’d like to share? Check out our call for submissions, and let us know you’re interested in the comments below! 🙌🏼