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 :)