how to transfer my transfer atlassian account to a new email adress

[Arnd Layer]

My company has been acquired. In the near future, I will be using a new email address. 

My current Atlassian account is managed by my company (Atlassian Access, MS Azure AD). AFAIK, there are no plans to transfer our AD accounts to the other company. We will get new accounts.

I've more or less given up on keeping my asset in the Atlassian cloud products. But is there a chance to at least transfer my identity in the Atlassian Community and Atlassian University?

[Dave Meyer]

Hi @Arnd Layer ,

Your best bet is probably to ask your current company to change your account to a personal email results (assuming your access to their products under this account will be removed). That way you’ll be able to continue using Community with this account.

[Craig Castle-Mead]

@Dave Meyer 

If the current accounts domain is claimed in Atlassian Access, then the username could only be changed to another domain claimed by the same Access org - they cannot change emails from a managed to unmanaged domain (which always excludes  gmail/outlook etc). 

@Arnd Layer  - if the new owners domain is already claimed/managed in an Atlassian Access org, then things can get complicated as neither you or they can change the accounts from @current domain.com (which your org has claimed) to @newdomain.com (which their org has claimed). It depends how many users/what integration/SAML etc is configured with your current Access org and domain, but you’d likely need to (general steps), un-claim the domain in your Access org (accounts become unmanaged, you’d lose SAML etc if it’s setup) and have the new company then verify+claim your current email domain in their Access org. One both domains are managed by the same org, the username/email can be changed. If you then had your new company account provisioned via SCIM, your Access account would link the Access account to that SCIM provisioned object.

I would avoid logging in to any Atlassian Cloud products using your new company email if at all possible until you’ve renamed your old company account over as there’ll be conflicting accounts - and there’s no way to merge cloud accounts. The only cleanup approach then would be to have your “new” email renamed in Access (to a dummy address - eg: first.last-conflict@conflict.com) , which would then mean you can rename your account.

Also, vote on this - https://jira.atlassian.com/browse/ACCESS-1364 - which may seem like it’s in vain, but is the correct approach to take. With all the focus, marketing and hype around Atlassian’s continued march towards a Cloud centric world, being able to do something as table stakes as merging accounts has to happen one day. Soon. Right @Dave Meyer  ?

CCM

[Dave Meyer]

Thanks for keeping me honest @Craig Castle-Mead . You're correct, I had forgotten we changed our policy on that.

I agree that the best solution then, based on what @Arnd Layer has described, is to hope that the company can:

1. Remove product access for accounts using email addresses with the old domain.

2. Turn off SSO so that users can reset their passwords.

3. Unclaim the domain so they can change the email address on the accounts entirely.

Admittedly not trivial, but that would allow @Arnd Layer to change the email address on the old account himself

vote on this - https://jira.atlassian.com/browse/ACCESS-1364 - which may seem like it’s in vain, but is the correct approach to take.

While I acknowledge it would be a valuable feature to have, I'm sure I don't have to tell you that it's quite complex to implement. We are investing heavily in cloud administration and identity features – we just rolled out the ability to easily switch between multiple Atlassian accounts, we have started rolling out "table stakes" like group rename, and we have significant investments in domain claim, external user security, and SSO for JSM customers coming later this year.

[Craig Castle-Mead]

Hey @Dave Meyer 

• in terms of changing a managed domain email to a non-managed email, wondering what the discussions have been around allowing some domains to be changed to (eg: the gmails/outlooks etc where no org will ever have those domains claimed) to let orgs support users convert a business managed account to a personal account (this could only be done by an org admin, so the org would chose whether that was appropriate after reviewing the sites/content/etc a user still had access to)
• I completely understand that implementing logic like merging accounts is not straight forward, but there are a lot of smart Atlassians, it is possible (unless the design/implementation is overtly complex) and it is a long requested, highly voted, constantly backed up by valid business requirements request.  https://jira.atlassian.com/browse/ID-240 was first raised 7.5 years ago, but now mentions “To be completely transparent, it is unlikely that we will reach a solution where all data in multiple Atlassian accounts across 20+ services can ever be combined”. You didn’t have 20+ products in cloud in 2015. Since then, Atlassian has built more products, acquired more companies and made the job your customers are expecting/demanding even harder on yourselves, yet we’re the ones that continue to suffer?
• While the user switcher may help some users, in some situations, we pay a LOT of money for Atlassian Access, as that’s the only way we can have what should be table stakes security features like SSO to our corporate identities (SAML/SCIM with Okta) and MFA. The goal here is for users to have a -single- identity in Atlassian Cloud that maps to their corporate Okta account. Since we can’t merge accounts (users end up with these for a whole pile of reasons - business restructures, complex user environments, acquisitions/divestments etc - and being blamed for this with statements like “Identifying and improving the workflows that lead to accidental duplicate account creation in the first place” from the above JAC isn’t a great feeling), we would only be able to use the multi user switcher by reducing our security (users would need to have a non-corporate linked account, which means no JML/central auth etc, and we get to pay Atlassian twice (or more) for an Access user seat for that user.
• I get there’s a lot of other areas of investment happening, and the importance of each piece is different to everybody, but hearing basically “we made it hard for ourselves, it’s hard to coordinate lots of teams” is a punch in the face, especially when I can bet that there’s going to be a lot of hype at Team 23 (as there is with every marketing push for your own products), about how using your tools can help you build great, complex products, and align and manage numerous teams to achieve a central goal.
• Getting some form of statement/update on this request that even indicates that new products/designs will implement a method to merge accounts - whether that’s something that an org admin can enable on a product by product basis as they’re built and released (some clean up is better than none), or it’s just feature flagged as off until all/enough products have support. This would be better than “As a team, we discuss this request and how we might be able to address it several times a year.”

CCM

[Dave Meyer]

Hey @Craig Castle-Mead , great questions.

wondering what the discussions have been around allowing some domains to be changed to (eg: the gmails/outlooks etc where no org will ever have those domains claimed) to let orgs support users convert a business managed account to a personal account

We used to allow this, the problem we ran into was that it's an irrevocable change. We had a couple customers do this without understanding the consequences, and after it was done there was no recourse for the customer or Atlassian to compel the user to change the email on their account back to the managed domain so the company could mange it.

 https://jira.atlassian.com/browse/ID-240 was first raised 7.5 years ago, but now mentions “To be completely transparent, it is unlikely that we will reach a solution where all data in multiple Atlassian accounts across 20+ services can ever be combined”. You didn’t have 20+ products in cloud in 2015. Since then, Atlassian has built more products, acquired more companies and made the job your customers are expecting/demanding even harder on yourselves, yet we’re the ones that continue to suffer?

The update in particular here is talking about individual data stores (our cloud services use multiple different data stores, unlike on-premises). The challenge is deeper than this though – even if it was solely Jira, there are still hundreds of individual pieces of data in Jira that can reference a user account that would need to be identified, remapped, and orchestrated.

I'm certainly aware that as our portfolio increases in complexity, delivering features like this becomes harder, not easier. As with all jira.atlassian.com tickets, it's an input into our roadmap decisions. And with all roadmap decisions, we consider the ROI in terms of customer value to development cost at a given time. We're capable of making both short and long term bets – I would point to group rename as an example of a case where we determined that the high cost was justified.

With all due respect to your other points, which are certainly valid, we do not have much evidence that this is a well-solved problem by our peers. Both Microsoft and Google do not support account merging.

being blamed for this with statements like “Identifying and improving the workflows that lead to accidental duplicate account creation in the first place” from the above JAC isn’t a great feeling)

I'd point out that Slack does the same. We're certainly aware that there are valid reasons well out of our administrators' controls why a user might end up with multiple accounts.

Getting some form of statement/update on this request that even indicates that new products/designs will implement a method to merge accounts.

Since all of our products share a single identity/account, it's not possible for a single product to support merging accounts on its own. This could nominally take the form of transferring data from one user to another (i.e. you can bulk reassign all tickets from one user to another) but is much more challenging for complex implicit data (like comments, comment history, audit log records, etc.)

[Arnd Layer]

@Dave Meyer , @Craig Castle-Mead thanks for the insights.

@Dave Meyer , I see that we probably shouldn't hope for keeping the same identity within the Atlassian products. Is there any hope for Atlassian University and the Atlassian Community?

[Dave Meyer]

@Arnd Layer I think it's unlikely but I flagged your question to our Community team just in case there's something I'm not aware of.

[Dave Meyer]

Hi @Arnd Layer , contact Atlassian support and choose the "My account" option https://support.atlassian.com/contact/#/

[Arnd Layer]

Hi @Dave Meyer 

Thanks for the suggestion. But I can't find the "My Account" option. Did I forget something?

I am registered for a few partner roles.

[Dave Meyer]

Hi @Arnd Layer , sorry I'm not sure how the logic works and why only certain options are available. I would select one of the other options (like personal data) and hopefully we can get your ticket transferred.