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