Change Domain for Jira and Confluence, with GSuite

[Omari Rodney]

We've had a company name change from when we originally created an account. Our on-demand account is currently xxxxx.atlassian.com but all of our email addresses are @yy-yyyyyy.com if I enable "Connect G Suite" will all of my team still be able to login?

[Shannon S]

Hi Omari,

The G Suite domain doesn't have any relation to the subdomain of your Atlassian Account URL.

When you enable G Suite you set up the connection with your existing G Suite logins, so any users with an email domain that matches a domain associated with your G Suite account will be able to login.

Let us know if you have any questions.

Regards,

Shannon

[Clive Lawrence]

Does the G Suite sync look at the "Secondary email" field in the G Suite User properties when reconciling existing Atlassian user accounts? The reason I ask is that we are also going through a company name change and would like to migrate our existing Atlassian Managed User accounts from our "@old domain" to the "@new domain" that has been configured in each user's G Suite user account.

I would hope that if the email address of the current Managed Atlassian account matches the "Secondary email" address (the "@old domain" address in our case) of the G Suite user when the G Suite Group sync occurs then a relationship will be established, but I'd certainly like confirmation of this before importing the G Suite users, as I don't want to double-up on user numbers, or lose the relationships between user accounts.

[Shannon S]

Hi Clive,

Per our G Suite FAQs page:

When you connect your site to G Suite, your users must log in with Google and cannot use an email alias. Because of this, the G Suite integration will look at any email aliases (secondary email) associated with the account in G Suite and update the user's Atlassian account to use this primary email address instead.

Because of this, you won't be able to use the secondary email as a G Suite login.

Your best option is to disconnect G Suite and reconnect with the new setup. If you run into any issues, you can let us know. We recommend troubleshooting with one user in this case.

Regards,

Shannon

[Clive Lawrence]

Hi Shannon, thanks for getting back to me.

It sounds like the behaviour you are describing is what we actually want to happen; I'm happy for the user's Atlassian account to change/update to use the Primary email address of the G Suite user login. This would help us in moving from the "@old-domain" email address that the Atlassian users currently have to the "@new-domain" email addresses that all our G Suite user accounts have been set up with. The important point for me is whether the Secondary email that we have configured in all our G Suite users (which matches the "@old-domain" address of their current Atlassian user account) will be used as a "key" to reconcile the accounts, and avoid creating new (effectively duplicate) Atlassian user accounts.

Does that help clarify what I would like to happen? I'm happy to test this with a single G Suite user account in a "test" G Suite Group, if you can assure me that no other users will be affected by enabling the G Suite integration for this single user test.

Thanks,

Clive

[Shannon S]

Hi Clive,

Thank you for verifying that. Just as a note, any use of the secondary email address even in your scenario hasn't been proven to work. I would recommend running the test you mentioned. 

What I'll do now is create a support ticket for you, so our Cloud support team can work with you and see if we can confirm if this scenario would work on your system.

Please check your email in a few minutes for that ticket number. :) 

Regards,

Shannon

[Jarno_Lepistö]

Hi,

What might have been resolution for this support ticket?

I have similar transformation coming soon.

[Clive Lawrence]

Hi Jarno,

With the help of the Atlassian Support Team, I successfully migrated all of our users using a two-step process. The first step was to get them all using their "@new-domain" logins, and then activate the Google G-Suite authentication on our Managed Accounts. There were a few problems along the way though... For some reason we found that some "phantom" Atlassian accounts had been created for some of the "@new-domain" addresses, and these had never been verified. So they "blocked" the migration process for that user. But I do have a workaround from Support for that as well.

Here's the steps from the notes I made during the migration:

Move user to "@new-domain" email

• Ensure all users know their current Atlassian login password!!
• Change Managed Account email address to "user@new-domain"
• User will receive a Notification mail
• User should *login* with the new account name (user@new-domain) and their current Atlassian account password and see a Welcome message. Click Resend to speed things up...
• User will receive email verification link - they should click this link
• User should be logged in as before, but with new email address
• User should confirm Jira/Confluence product access
• Verify that the Managed Account is now in the "@new-domain"

Once this is done for all the users you can enable the G-Suite authentication, and they shouldn't have to use their Atlassian passwords in future; the Google login option should work.

If you have any issues with "unverified" accounts that prevent the migration (for example, you may get an odd error when you try and change the user's email address), then these steps may help:

Removal of unverified blocking "@new-domain" account (requires user input)

• Open https://id.atlassian.com, click "Can't login" and enter user's "@new-domain" email address
• Send recovery link for the password via email to User. Ask them to use a simple, temporary password that they can share with you
• Login using the user's "@new-domain" login, and temporary password.
• Check the Managed Account now exists.
• Logout.

If you need to remove a Managed Account without user input, then these steps will effectively change the account to one in another (temporary, disposable) email domain.

Get rid of unused Atlassian account in "new-domain" (doesn't require user input)

• Create a temporary email address - https://temp-mail.org/ e.g. yourname@bit-degree.com
• Change email address of unused "new-domain" account to temporary email address (yourname@bit-degree.com)
• Verify address change notification email is received in TempMail address
• Login as new TempMail address, and existing password, or use Reset option; Resend to hurry it up...
• Wait for email verification link in TempMail (can take some time)
• Copy the link and open it in an Incognito window
• Log out
• Confirm that the Managed Account no longer exists

I hope some of that is useful :) Good luck with your migration!

Clive