Need clarification on migration with Atlassian Access

[Rob Horan]

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?

[JimmyVanAU]

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

[Rob Horan]

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?