<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

Everything I Learned about Moving to Atlassian Cloud I Learned from Marie Kondo

Atlassian, Atlassian Tools, Jira, Atlassian Cloud



If you're reading this blog post, you are most likely using the Data Center versions of one or more Atlassian tools. Many of you are probably happy right now working on your own servers...but beware, you will eventually move to the Atlassian Cloud. Maybe not tomorrow, but soon. And for the rest of your professional life, Atlassian Cloud awaits. It might be the case that you do want to move to the cloud now, but there are time constraints, or budgetary or technical reasons you can't move. 

The purpose of this blog is to help you help yourself, your internal teams, and/or your future Atlassian Solution Partner make your migration to the Atlassian Cloud as friction-free as possible. Like any move, the more work and planning you do up front, the more successful you will ultimately be.

Make sure as you read this, or any blog articles on moving to Atlassian Cloud, that you visit (and re-visit) Atlassian's guide to moving to the cloud. It is a great high-level view of what your organization will go through as you embark on this journey.


A Short History

Over time, Atlassian Cloud has gone through many changes. In the very beginning, it was actually called OnDemand. In fact, we here at Isos were on the OnDemand version of Jira and Confluence for a few years. OnDemand was what you could consider technically a twin of Jira Server. It was basically Atlassian hosting a Jira server for you (with a few minor modifications).

In 2014, Atlassian switched from the OnDemand moniker to Cloud. Over the next four years, as the differences between Server and Cloud grew, their technical DNA started to drift. Features like GUI changes, Atlassian ID, the dropping of certain features and the adding of new features showed the changes were more than skin deep. Lastly, the concept of Connect applications is what really seem to drive the point home that Cloud was not a re-badge of Jira Server.

Finally in 2018, Atlassian started their own journey into becoming a "Cloud First" company (you can see a presentation on that journey with this link.) Up until that point, products like Jira Cloud were still very close to Jira Server. They were hosted on Atlassian-owned servers and, in general, Atlassian didn't feel they could iterate and scale their services because of technical sins of the past. In the next 18 months, Atlassian converted their entire services stack to use every Amazon web service they could possibly leverage, and restructured their own services to convert them from monolithic servers to hundreds of micro-services.  


Focus: Users / Groups

When you move any Atlassian product to the cloud, user (and group) migration is one of the first proverbial ducks you must get in a row. If your user info is not correct, it can stop a migration in its tracks. Let's go into what issues you might have to deal with and some short explanations of why:

Why is this even a problem? Jira and Confluence have been around for 17+ years. The constraints around what were the requirements to create users in Jira, for instance, has changed over time. For ease of upgrading, Jira didn't force admins to fix user account constraints.  These uncorrected issues became roadblocks when attempting to move to Cloud.

Here's a quick list of issues you might need to deal with:

  • Unique email address - In Atlassian Cloud, every user must have a unique email address. Atlassian ID uses a person's email address as their main login, so having a unique email address for each account is definitely required.
  • No email address - Along the same lines as above, previous Atlassian deployment options allow users to NOT have an email address.
  • Weird characters in user names / group names - Early versions of Jira were very tolerant of name formatting issues, like allowing admins to put spaces at the end of group names, periods at the end of user names, etc. This naming tomfoolery is not tolerated by the Atlassian Stack. 


Ways to Start Chipping Away at the User/Group Problem

There are few things you can start to do right away to discover and fix these user/group problems. By the way, even if you do not plan to move to Atlassian Cloud for years, this clean up activity is a good best practice. It will not be a waste of your time.

  • Load Up All Your User Account Info into a Spreadsheet - If you search the Atlassian community for ways to extract your Jira user information, you'll find many ways to use REST calls and/or SQL queries to get that information. However, in the past few years, a better way has come along in the form of a free Jira app, Jira User Export.  
  • Jira Cloud Migration Assistant - While this tool still might be rough around the edges for completing complex Jira migrations, it now is up to the task of migrating your users and/or groups to Atlassian Cloud. Both during its preflight and user/group migration processes, you will definitely end up with a short list of users and groups you need to fix to make your cloud migration a success.
  • LDAP / Active Directory Admin Help: As you find a lot of these user and group apps, you will have to employ the help of your external directory admins to make the necessary changes. Make sure you keep that group in the loop as you work on resolving each exception you encounter.



Start working on your user clean up and be sure to let us know how it goes in the comments. And as always, you can engage Isos to help you with this whole process. We're here for you!

See you next time! 

New call-to-action

TAGS: Atlassian, Atlassian Tools, Jira, Atlassian Cloud

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts