You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hi everybody, my group is looking at Jira on the cloud and we are thinking of moving over, but haven't taken any steps yet. One thing is we want to know what happens to ur accounts - if we make Atlassian IDs to play around with a cloud site and migrate some data to see how it all works and then install Access, what happens to our accounts? Do they just change to become Access or managed accounts? Should we expect anything with our permissions to change or any other changes? Having a hard time understanding what the implications are of adding access and what happens to our accounts?
I'm going to post my experience with Atlassian Access and server to cloud migration - I'm not sure if this answers the question or if its spam, but hopefully this will help.
First - I don't mean to preface that to make it sound like it was a bad thing. Far from it. The setup of Atlassian Access was, for the most part, a pleasant surprise in terms of its ease. Granted, a good portion of the work that was done for this particular migration, was taken care of by the people I was performing the migration for, but only because I did not have direct access to their ADFS environment - so all of the information gathering on the ADFS side had to be done from their side. That said, together we were able to cut right through it with truly minimal effort. I could not have been happier in that regard.
Once it was set up, creating multiple access policies (for example, to include some users in SSO and exclude others) could not be simpler. Want to have a user in your organization that is not bound by SSO in case your identity provider is down? Super easy.
Here's where things got confusing. This migration involved a Jira site migration (due to JSM) and Confluence via the migration assistant.
The checklist for Jira site import involves generating an XML backup and performing a number of validation and cleanup steps, some of which are cleaning up users and groups. WELP... because we were going with Access (I think) Atlassian told us to generate a CSV file of users and groups from Jira and wipe those sections entirely from the XML backup. Atlassian then imported the users and groups to the client's site, where we could then review the upload prior to the site import. Truthfully, I loved this process, and think it should be included in the instructions as the primary method of user migration.
Two semi-minor frustrations with the checklist:
Here's where the biggest downside comes in, and to be crystal clear, its a fault in the identity provider - and from what I understand, technically ADFS is NOT an identity provider. (it is an STS - that's as far as my knowledge goes at the moment, this is far from being my realm of expertise) If you have ADFS and you are considering a migration to the cloud, give serious thought to upgrading to Azure or incorporating Okta into your environment. I say this because Atlassian Access can ONLY work with ADFS for SSO. It's an ADFS limitation, but the bottom line is you miss out on multi-factor authentication, and much much worse, you lose out on any user provisioning since ADFS does not support the industry standard SCIM provisioning.
What does this mean? It means Atlassian Access will, for all intents and purposes, be equivalent to the local directory for Jira and Confluence. It means forget about using AD groups to manage your permissions and group memberships in your products. When you migrate, you'll get a snapshot of your AD users and groups, but after that IT'S UP TO YOU TO MAINTAIN ALL OF IT, MANUALLY. All user and group additions, removals, and any other user management activity is manual. There is no sync with AD.
Second major downside to Access - and it's fully documented BUUUUUUUUT - here are the rules:
Soooo.... if you have people in your organization that set up free Trello/Jira/Confluence/etc accounts thinking it wouldn't cost the company a dime, or if people in your organization set up an Atlassian account with their work email address to access Atlassian Cloud products outside of your organization (say if they were performing work for a client on their site) well.... start practicing your Mr. Krabs voice, because each of them is now draining your wallet with a paid Access account.
hi @Garrett Gifford - I am looking for similar information - I'm going to be helping a team with their migration and (I believe) my email address, though not part of their organization, is within their AD structure. When they move to Atlassian Access will my Atlassian account suddenly become a managed account under their Access account?