You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hi, currently only have Confluence in Cloud without Access subscription so all manual sign-in.
Want to migrate on prem server Jira Software and Core to Cloud with view of getting Access enabled along the way so we can have SSO.
Reading the Jira migration info it states best to test in separate organisation than Prod. I don't believe we have existing 'organisation' just a site so can I just add the product into my sit as a new trial?
I don't want to impact anything to do with our live production Confluence Cloud product.
Referring to info top of page here: https://support.atlassian.com/migration/docs/use-jira-site-import-to-migrate-from-server-to-cloud/
Using the Jira backup data will overwrite any prod data. I will suggest you spin up a development/test instance to test the migration steps you need that are separate from your prod environment.
I'm a little lost. How does importing Jira impact on Prod Confluence or it it in relation to Users/Groups?
Seems odd to spin up new organisation & trial. Do I presume once satisfied migration is working well etc that the products can then be grouped in same organisation as thought that was whole point of organisations: to group all your products together?
@Dave Meyer So Atlassian recommends that for a trial migration, we create a whole new temporary organization just for that purpose (e.g. "myorg-migration-trial.atlassian.net")? Then after the migration, this new organization will persist forever since they can't be deleted (https://jira.atlassian.com/browse/ACCESS-81)?
Hi @Jeremy Cupps , apologies I think my phrasing from last year was a little incomplete. It's often valuable to test a data migration from server or Data Center on a separate site than the one you intend to use for production, but generally we recommend having both the "test" site and your main production site in the same organization.
If you need to test out aspects of your Atlassian Access security configuration without affecting all users, the best way to do this is with an authentication policy that's applied to a small number of test users.
As an aside, we have been working hard on the ability to delete organizations and expect to release it later this calendar year.
@Dave Meyer Thanks for the clarification and update! Just to further evidence the confusion around this question, here is an excerpt from Atlassian's documentation that recommends testing migrations in a separate organization:
For a test migration or UAT, we recommend that your test Cloud site is not part of the organization that also hosts your prod site. The prod site should be hosted in a different organization. This is to ensure smooth migration of the relevant users and groups.
It doesn't provide any further guidance in that regard, which is frustrating.