Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Need clarification on migration with Atlassian Access Edited

I am going to be assisting an organization with migration. In terms of order of operation, Atlassian recommend enabling Atlassian Access after the migration to avoid https://jira.atlassian.com/browse/ACCESS-653 - This also ensures that any users on the internal directory ie: users manually added, are also migrated to cloud.

So, to perform the initial work I will be logging in with my Atlassian account as an admin, the test migration will occur, and then Access will be installed.  My email address is associated with an Active Directory account - does this mean that it will be associated with their Atlassian Access subscription?  If so, does that make my entire Atlassian account a managed account under their organization?

Also, assuming all accounts are converted to Atlassian Access accounts, are there any fallback options for accessing the site if something goes wrong with Atlassian Access setup or under any other adverse conditions?

Lastly, and I assume this is a non-issue, but would there be any concerns with another post-UAT migration to the same site after Access is in place?

1 answer

0 votes
JimmyVanAU Community Leader May 24, 2021

Hi Rob,

Let me try to tackle your questions one by one:

So, to perform the initial work I will be logging in with my Atlassian account as an admin, the test migration will occur, and then Access will be installed.  My email address is associated with an Active Directory account - does this mean that it will be associated with their Atlassian Access subscription?  If so, does that make my entire Atlassian account a managed account under their organization?

From this I'm inferring that you're external to the org, that is, you are rob@robhoranconsulting.com helping cloud.com migrate. Is that right? You don't have an email address/Atlassian account associated with cloud.com and will be performing work with your own Atlassian account.

If this is the case, then no, your account will not be associated with the Atlassian Access subscription. Atlassian Access is managed an organization by organization basis, for all of the domains that the organization (here cloud.com) owns.

 

Also, assuming all accounts are converted to Atlassian Access accounts, are there any fallback options for accessing the site if something goes wrong with Atlassian Access setup or under any other adverse conditions?

During the Jira/Confluence migration, accounts will be created if they don't exist. If something goes wrong with Atlassian Access, then you'll need to raise a support ticket at support.atlassian.com. A handy site to bookmark is the Atlassian Access status page. This will tell if you if there's anything going on. 

Lastly, and I assume this is a non-issue, but would there be any concerns with another post-UAT migration to the same site after Access is in place?

You can perform more migrations later after Access is in place for sure :)

 

Cheers, Jimmy

Thanks Jimmy not just for this answer but the answer to my other question.  This is going to tie into that a bit.

Migration is a complex process - and I use that word loosely, because the logic is complex and unclear, and the responses I'm getting on a support ticket are a little contradictory. 

The Jira pre-migration checklist for site imports instructs users to take the XML backup, check for email issues (multiple people per address, etc) and "fix" the XML, without defining what that fix really is.  Delete the users?  Modify the addresses?  Something else?  OK.  You've already seen how that was difficult in Windows given the instructions were written for Linux and only Linux.

I also got contradictory instructions in the support ticket telling me to just surgically remove that entire section from the XML file.  So.... don't fix anything, just delete?

When I asked for clarification, I got a response telling me to use the Cloud Migration Assistant, which I didn't think would even come into play in a site import, but also doesn't answer the question: fix or delete, and if fix, how?

My other questions can be distilled into this:  How are ALL users in a system that has an external and an internal directory going to be migrated?

I am assuming the step involving the creation of CSV files based on SQL statements will be sufficient - and if that's the case, why doesn't the pre-migration checklist just tell people to wipe that section out? 

So the only thing I can think of is that the use of Atlassian Access with a site import is the differentiator.  If using access, then completely delete users and groups from the XML file, otherwise if Access is not being used then perform the check and manually fix the discrepancies.

Does that make sense?

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Atlassian Cloud Migration

Cloud migration resources roundup: May 2021

...est practices.   And don’t forget about the tried and true! Cloud Migration Center - central hub for all things Atlassian Migration Program. Includes links to our full resources page, s...

557 views 2 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you