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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.