Our Journey to High Availability with Jira - Part III

[#1]

The Recap...

Hello Everyone! It's the moment you have all been waiting for, our grand finale to my series of posts on our journey to high availability with Jira! 

For anyone that is just joining this series now, I'd recommend looking at Part 1 and Part 2  before you continue.

We left off last time with having made the decision to go to Jira, planning out the process of migrating, and figuring out everything that we would need to pull together to be successful.

First, the Atlassian Migration team has written some fantastic documentation.  Anyone who is looking to do a server to cloud migration should start here.

This is just a small sample of the things I found super helpful while we were preparing:

• https://confluence.atlassian.com/cloud/plan-your-jira-server-to-cloud-migration-972349846.html
• https://confluence.atlassian.com/cloud/compare-atlassian-cloud-vs-server-744721664.html
• https://confluence.atlassian.com/cloud/blog

Testing the migration

Setting up a test cloud instance was extremely easy, and with the recent announcement of extended trial licenses it's now even easier for others to do this.

Our first import completed successfully without any errors, (we did this knowing that we weren't mapping users yet) but we wanted to make sure our project data and attachments wouldn't have any issues.  Full disclosure, by comparison to others, we have a rather small and simple instance.  We have 5 apps which we were able to abandon or find equivalents/alternatives on Jira Cloud, and we have 30 projects with a total of about 50,000 issues.

Once we were comfortable with our project data, it was time to focus on user and group migration.  This was a little more challenging.  For anyone who is using Jira Server today and looking to move to Cloud, be prepared for that fact that the way you manage users and groups is going to change significantly. Cloud has the concept of an Organization to which all users belong and multiple applications (such as multiple Jira instances or other products like BitBucket or Confluence).  All user management happens at the organizational level where user management happens in a central location. It took us a bit of time to wrap our heads around this fact, but gets much easier once you get the hang of things.  There isn't much in the way of good documentation to warn existing admins about just how different the experience is going to be, so I write this so you are prepared for what to expect.

We knew that from Day 1 we were planning to use Atlassian Access connected to our Azure AD.  By following the documentation this was an extremely simple process, and users were able to login using SSO with very little effort.  The only additional change we needed to make (and I would caution people to carefully read the documentation about this) was that we needed to convert our LDAP users into the Jira Internal Directory, as well as all groups.  There are plenty of posts around this topic on the Community to help you on your way.

Since we had AD authentication working, we decided to open the instance up to the entire company for user testing.  There were several people who were more than willing to help, and we were able to find a few configuration issues, and make a note of them, so they would be resolved when we did the live migration.

Users were extremely happy with the UI, with several of them commenting on the fact that it was different and would take a bit of getting used to, but there wasn’t any negative feedback around the changed look at feel, or about not being able to work with the new layout.

After a week of letting people play with things, we started planning who would need to be involved in the live migration and we made sure our schedule would work for everyone involved.  After months of planning and testing, the moment of truth was upon us!

Doing it "for real"

Our plan was to start on a Friday night so we could let the Attachment import run overnight.  Everything started well, taking a backup of our server instance, shutting it down so no one could accidently add additional data, and then we started the project data import. 

It failed.

We then proceeded to look at what had gone wrong as we hadn't encountered this the entire time we were testing.  We made a couple of changes and tried again, and it failed again for a different reason!  This continued until about 1 am on Saturday.  We were working remotely from home but decided to call it a night, resolving to look in the morning.  At 5 am I had an idea to try running the migration overwriting users instead of trying to merge them.  I decided to give it a try, and an hour later the project data imported successfully!

We then decided to meet at the office so that communication would be a bit faster.  Upon arrival at the office we realized that while the project data had imported, none of the users were linked, and that prompted further investigation to realize that we had not actually been successful Friday night in setting up proper a user sync from our Azure AD like we had when we tried things out on the test instance.

At this point we realized trying to push forward would result in a bad user experience come Monday morning for all our users, and we really wanted the first experience to be a positive one.  We decided to cancel the migration and roll back to Jira Server (for the time being). 

We learned two major things from this failure. 

First, Murphy's Law is still an active part of our lives.  Second, when testing a Cloud migration, don't spin up an entire separate test instance and another one for production, simply use what will be production as every time you run an import it's going to overwrite all the data.  This way you won't be stuck with "test" data when you go to do your live migration.

At this point, we were a little demoralized, but we weren't going to let this little bump in the road stop us!  We spent the next week testing on the production instance.  We fixed up the user sync issues from our Azure AD and then we ran multiple project data imports and verified the results.  We were also able to spot some inefficiencies in our plan, such as waiting for the attachment import to run, before making some required manual workflow configuration changes.  By changing the order we were doing things, we would be able to more efficiently complete some of the tasks, while hopefully allowing our next attempt to take less time overall to complete.

That following Friday, we ran through the entire newly minted plan from start to finish, starting first thing in the morning (the exact steps we planned to run that evening minus shutting down our Jira Server).  That night, not only did we migrate successfully, we managed to do it 3 hours faster than we originally intended!

Celebrating the win!

The next day, Saturday night, a few of us (having been through the emotional roller coaster of getting this migration completed) decided to let off some steam. I made a Friday Fun post about how we accomplished this in an epic manner.  The short version: Drinks, Video Games and 90's Action movies!

Final Thoughts

It's been a couple of weeks now since we successfully completed our migration, and overall, everyone is very happy with things.  Our users love:

• The notification hub (some have stopped using emails completely)
• The mobile app
• The UI and user experience Jira Cloud offers

I want to thank the Atlassian migration team for providing as much documentation as they have.  There were a few things we hadn't considered when we started this migration that we were able to plan and account for in the testing phase.  Without all this free help, we probably would have taken much longer to complete the migration.

Were there additional steps we could have taken to avoid the first-round failures?  Maybe.  Our testing in the test instance went extremely smoothly, whereas performing the exact same set of steps in the production instance behaved differently.  It wasn't until we failed that we saw where we could improve, so in that respect, maybe not?  The point is we failed, learned, and applied what we learned to succeed.

So, what's next for Igloo?  Jira Service Desk and Next Gen projects both look like interesting new avenues to pursue.  We'll see what business challenges we need to solve next and how Atlassian can help us accomplish our goals.

Thank you for taking this journey with me, I hope you have enjoyed reading it as much as I did writing it!