How are you handling Atlassian Guard policies during Cloud migration?

[Mirek]

We’re currently looking at Atlassian Cloud migration and one thing that keeps coming up is how Atlassian Guard fits into the transition.

On paper it feels like a natural extension of moving to Cloud centralizing identity, tightening access control, and standardizing security policies across Jira and Confluence. But in practice, it seems like it can easily become either something that simplifies governance, or something that adds an extra layer of friction during migration.

What I’m trying to understand is how teams approach this in reality. Some seem to introduce Guard early in the migration to enforce structure from day one, while others treat it as a post-migration step once everything is stable in Cloud.

I’m curious what has worked better in your experience.. do you implement Guard policies as part of the migration itself, or only after the Cloud setup is already in place?

And did it make the migration smoother, or add additional complexity to manage?

[Ed Letifov _TechTime - New Zealand_]

Hello, @Mirek 

Since you can't properly secure Cloud to enterprise standards without Guard — always start with Guard.

Verify your domains, claim your users, deal with anyone who is not supposed to be in your Cloud at all (use our User Management app to do so in bulk, you can have it running on DC but connected and operating on Cloud org), configure SSO against your IdP, set up controlled User Provisioning, establish which groups control access to what, and only then — get your target instance, under your organisation, and configure access groups to the products. That's the theory.

In practice, you probably already have an instance (or seven), and a Cloud org (or seven) has been created for you, so you kinda desperately trying to make pieces described above fit the proper narration (almost like a Memento movie, tbh). Good that our app also exists in Cloud and can just run from one of these instances you have :)

[Mirek]

Thank you @Ed Letifov _TechTime - New Zealand_ for being first to reply :) .

The key point is that when you actually migrate (create) users when using Migration Assistant.. so is it better to have them prepared already in Guard or do it later and migrate with basic access etc.. 

Overall from what I understand managing users by using Guard can be done on a complete different organization.. The key point if you manage users is that you claim them somewhere and then they cannot be claimed again. Correct?

[Ed Letifov _TechTime - New Zealand_]

@Mirek 

1) Yes, users can only be claimed in one org.

2) Yes, you can have your users managed under one org, and all, one, or more sites in another org – however just beware that these users will be treated as "external" in the org they are not managed in — this is not always nice, e.g. External policy with email-based 2FA will apply to them in that other org's site.

3) From security perspective — you usually need to have Cloud "secured" and be able to prove it to your security team BEFORE you start pumping production data into Cloud. This means you usually set up Guard, policies, SSO, provisioning etc. first before migration.

4) One of the things that this then triggers is decisions on access groups names e.g. if you EntraID group equivalent for your (historical in DC) "jira-users" is called something completely different by (current) convention — this usually means you need to "re-key" your Jira data before migration — consider: "jira-users" used in Permission Schemes, workflows, comments, Security Levels — if you migrating to the new group name in Cloud — all of these must be changed. It's easier to do on DC. 

There is now a new (in beta) functionality to rename groups in Cloud — if this actually works post migration (e.g. you can just rename your "jira-users" migrated by JCMA and it will somehow auto-magically deep rename all references — that is the hope for this functionality!) then this also means you can't have a "jira-users" group being pushed from IdP before this rename i.e. before migration, otherwise they may end up linked, read-only, and impossible to rename.

Main point: There are some "security design" or "information design" decisions that have to be taken before migration, ideally.

4) Please note that regardless of what you do with Guard before migration — what comes through in the migration (JCMA, CCMA) is going to be a mess requiring post-migration cleanup. 

Example: You had a user in DC who was deactivated 6 months ago. The same person with the same email used Trello (or other Atlassian sites) in Cloud, as recently as 3 days ago. From JCMA/CCMA pov there is no way to tell if this user should be active or deactivated in Cloud — so every deactivated user WILL be migrated as active to Cloud. Now scale this up — you DC instance has 17k users, 8k deactivated — do you want to guess what the result of your migration will be and how it will (try to) affect your Cloud license costs?

This is the bit that always gets ignored and then people scramble to solve it afterwards. Our apps (sorry for the plug) User Management for Jira and User Management for Confluence do exactly the actions required in Bulk Actions mode to help with this, fully functional on eval license. As a Gold Atlassian Solution Partner in New Zealand and Australia we use our own apps all the time when we do migrations.

Now consider if you are doing migration of Jira and Confluence too. That your on-premise AD user list is not the same as being pushed by your Cloud IdP (either deliberately or due to wrong config), and you also have users from external domains in your instances... Technically you have a reconciliation problem for 5 user sources, that MUST be solved before you push migration button.

And don't get me started on people who have multiple different emails in the same app or Jira vs Confluence vs Cloud vs IdP... And you also have your people who registered in the Cloud years ago with an email alias.

And consider this: there is no way to merge user accounts on Cloud. On DC you can at least (ab-)use the GDPR anonymisation apps to do so.

So, anyway... 

To answer your question (again): always always blow on the pie do set up Guard first, claim and analyse your users, do your security architecture/design/implementation, reconcile your user lists, merge accounts, rename emails — much easier to do all of this before you push migration button.