In the process of testing Server Migration to Cloud (Preparing to)

Tech Ops_yjrg2f

Hi All

We have Jira in the cloud and in the process of moving confluence server to the cloud.

Jira is already Live

We plan to trial Atlassian Access. When doing so is it possible to setup only one OU from our Azure/AD idp to test with just a few users? Or is it all or nothing? 

We have users already using Jira via email invitiation. I just want to be sure that when I set up atlassian access it doesnt sync those to the idp yet for the trial as I want to test with non Jira users as they share the same email address in the idp and in the local user tables. 

We also plan to Migrate some data to the cloud. for testing. I assume I can select only one or two spaces to migrate? I assume I can manually delete those spaces after the test when its time to do the real thing? Reading the documentation thus far, this is what I believe is true. But wanted to be sure (I cant make a sandbox because I dont have premium) 

Ed Letifov _TechTime - New Zealand_

Hello, @Tech Ops 

1) In Azure you add groups to Atlassian Cloud application to indicate which users should use SSO or be provisioned. So yes, you can limit to a subset.

Please note in the case of User Provisioning these will be groups "pushed" to Cloud too. This does have implications, please review my answers on how to set it all up correctly here: 

• https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417
• https://community.atlassian.com/t5/Atlassian-Account-questions/SAML-SSO-with-Azure-AD-does-not-work-when-using-quot-Continue/qaq-p/2085502
• https://community.atlassian.com/t5/Jira-Service-Management/Azure-AD-login-and-incoming-email-not-matching-up/qaq-p/1821809#M88619

On the Cloud side, you can configure the directory associated with Azure to NOT have a link to a domain – this will prevent everyone from this email domain to be added to the User Policy associated with the IdP automatically.

Then you can put everyone in your Cloud into "default" and "non-billable" policy. When Azure synchronises users and groups – these will end up in the IdP-related policy i.e. only these will get SSO.

2) Yes, you can migrate a couple of spaces and then delete them.

Some recommendations however (in New Zealand and Australia, we, TechTime, are a Gold Atlassian Solution Partner and do migrations A LOT):

2.1) Work with a partner like us – it will save you time and grief.

We do fixed-cost Confluence migrations priced at NZ$9000, all of the above Access-related, every single detail will be handled within this budget as well as the migration itself.

You are more than welcome to reach out to our 24x7 support, but, really, just find the local one using Partner Directory and ask them what they can offer to help and when.

2.2) Create a runbook. Use Confluence for this, Product Requirements blueprint works perfectly. Document sequence of actions, and when executing – record timing e.g. 12:10-12:15.

2.3) Create a new throwaway Confluence Cloud instance and do test migrations into that or subscribe to 30 days Premium Confluence trial, and create a sandbox – do test migrations into that. Blow it away as a whole when you need another one.

Part of the migration is migrating users and groups – you really don't want to mess up your PROD setup in Jira in any way.

2.4) Plan for at least 2 full (not just a couple of spaces) test migrations. Every time you do a test migration – update/refine your runbook. Your goal is to be able to give this to any admin in your org (who has prior knowledge of Atlassian Cloud and Confluence Server) to be able to click-through and achieve success.

2.5) Cleanup your users at source, either in your Prod confluence, or an intermediary environment – make sure all have non-duplicate non-empty emails.

This is where we usually deactivate anyone who hasn't access Confluence for 6 months or more. We use our own User Management app for this with Bulk User Actions. You can run a Data Center evaluation on a Server Confluence!

Since you already have users in Cloud, specifically Jira – it will be worth to make sure your users in Confluence match i.e. that you don't have the same person in Confluence with a different email, which will create a distinct account in Cloud.

2.6) migrate users and groups first, with nothing else, no data, no attachments, no apps

2.7) migrate attachments-only next, this will save you A LOT of time later

2.8) migrate spaces and apps (if any). If any space migration fails, figure out why, blow away the space, re-migrate – but don't settle for this as your prod migration strategy. By the time you are in prod migration mode this should be all one "long shot" process

2.9) Configure global settings for Confluence, but also for your sites – Product access, etc.

2.10) Really, consider using a Partner for the above.