Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,461,569
Community Members
 
Community Events
176
Community Groups

Atlassian Access and trials

We are starting off our cloud migration. We have our production org name but want to perform POC's in one or more cloud trial accounts.

We intent to use Atlassian Access for user management.

If we claim domain users in a trial account will that then prevent us from claiming those users for our production account?
Is this a bad idea to start with?

3 answers

Hello, @Tom Lister 

It all depends on what various English terms mean in your question...

If we claim domain users in a trial account will that then prevent us from claiming those users for our production account?

If by "trial account" you mean "trial instance of Atlassian Access" – yes, this will prevent you from claiming the same domain in your production instance of Atlassian Access.

If you want a true POC without touching anything that will be related to production later you need a different email domain from your production domain.

To be honest this is an overkill. 

As @Dave Meyer alluded to – you can claim your production email domain from the beginning, but when configuring Access during POC phase, apply "nothing" policy as the default i.e. no SSO, no 2FA, no password strength enforcement – while applying a policy that you want eventually to be the production one only to select Atlassian Accounts, i.e., members of your POC trial.

As such the organisation for this Access instance can be the final production organisation from the beginning as in the end it's just a label.

Your Cloud sites (i.e. a collection of Jira + Confluence + Opsgenie, or Statuspage) existing or future ones – can be transferred to this organisation, either immediately or eventually.

A site always belongs to an organisation – when you register a new site, a dummy org record is created for you, so you need to transfer the site to keep everything organised.

Again, this is more or less just a logical link, as all enforcement is done from the org to managed users via users' email domain.

However, in the new user management org admins do get site admin rights i.e. transfer may affect your licensed user counts depending on how product access is setup in these sites.

Do pay attention to the note at the top of the transfer the other site into that organization page – the improved User Management experience has been "improved" to the level that the process won't work for any new site, you'd have reach out to Atlassian Support via https://support.atlassian.com/

If by "production org name" you mean the part of the url, e.g., "production-org-name.atlassian.net" – to be honest I would claim a site on this name ASAP. We have had customers who ended up losing the name to someone else way too late in the project.

Yes, definitely get a Partner nearby to help you. I always recommend this. In most cases, Cloud migration is not a simple task, and may anywhere from 6 to 18 months from experience. 

As per your further comment re: people being able to access you trial versions (of Cloud products i.e. "a site") – this indicates a problem in the target site's product access configuration. See this answer I've provided to another user for some hints: https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417

Please note, that when you migrate users and groups with JCMA, if these have groups with the same names that will eventually come from an external IdP (e.g. Azure AD) via User Provisioning in Atlassian Access – User Provisioning has to be disabled during JCMA migration, and re-enabled again after it is finished.

We, at TechTime, as a Platinum Solution in New Zealand usually "re-key" the source Server data to use group names that will be coming from the IdP e.g. Server uses "jira-users" (historically) but Azure AD has some "AAD_Atlassian_Jira_Users" group named as per organisation's naming convention – the ultimate desire is to add a user to this group in Azure AD, and give them privileges they would have had on Server if added to "jira-users". For this to happen, Jira data has to be re-keyed to use the new group everywhere – permissions, comment restrictions, workflows, notification schemes, etc.

See some of the notes on migrations in this answer I've provided to others earlier: https://community.atlassian.com/t5/Atlassian-Migration-Program/Migration-planning/td-p/1956666

Hi @Ed Letifov _TechTime - New Zealand_ , @Dave Meyer 

Thank you for these great responses.

We have claimed our production org name and performed some testing in it. Our Atlassian Advocate/Migration manager advised against this as it needs to be clean for final prod migration.

I have run test migrations in trial sites without having to use Access so we have some options to go on with. We have chosen a partner and once we have contracts in place we will discuss in detail how to proceed.

In the production org we need to claim our production domain in order to finalise numbers for the Access licenses quote.

I have claimed a secondary domain we also own in a trial Access in order to explore how it works. As expected this secondary domain can no longer be claimed from any other orgs.

I'm not sure we would benefit from transferring sites into our org. Although we may discover all sorts of 'end user computing' when we verify our domain.

Hello, @Tom Lister 

re: "it needs to be clean for final prod migration" – depending on the complexity you may need to run 5-6 full end-to-end test migrations, so resetting an environment is something you will have to incorporate into your migration plans. See my comment here: https://community.atlassian.com/t5/Atlassian-Migration-Program/Migration-planning/td-p/1956666#M81 you may want to request the ability to load a blank site import from support.

1 vote
Dave Meyer Atlassian Team Mar 22, 2022

Hey Tom,

It sounds like you are planning to have one or more Jira/Confluence trial instances, in addition to Atlassian Access.

It's important to understand that Atlassian Access is associated with your organization, which can be the parent to multiple instances of Jira and Confluence Cloud. So what I would recommend is that you start a trial for Atlassian Access in one organization, and then transfer the other site into that organization so that both sites are linked to one organization.

You can use authentication policies to test out SSO set up prior to rolling it out to users, and testing imports of data into Jira and Confluence typically doesn't affect anything with Atlassian Access.

Hi Tom,

Short answer I think is no, at worst you can just add them to projects?

Though there might be some faff involved and I would make sure to close things down properly.

Personally we set up a set of dummy accounts to try things with.

In terms of whether this is a bad idea it depends on what you want your POC to do.

Trial accounts don't have much in terms of user management, which we found to be a key part of our process.

We also had issues with people being able to prematurely access our trial version, so I would be careful, and definitely don't include any sensitive information in it.

If you want to just have a play then a trial account is probably a good place to start.

Best wishes,

Matthew

Hi @Matthew Robinson 

Thanks for the reply

At some stage we need to do full pre-migration POC's of production data which will involve user data. We can do that without Atlassian Access.

I've tested JCMA migrating users. And got the issue of people being able to access the trial versions!

We are about to appoint an Atlassian Partner who will hopefully provide some alternative approaches to this.

Like Matthew Robinson likes this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events