Before You Merge Atlassian Organizations: A Checklist for Identity, Access, and Licensing

Atlassian Cloud organisations are often created for sensible local reasons: an acquisition brings its own environment, a business unit starts independently, or teams build separate administration models over time. Eventually, this can leave an enterprise with duplicate user management, fragmented security controls, overlapping groups, and an unclear view of who can access what.

Consolidating organisations can simplify that landscape. It is also a significant, irreversible administrative change. Atlassian’s current guidance states that consolidation transfers products, sites, and users from a source organisation into a destination organisation, then deactivates the source organisation. It also notes that new consolidation workflows, including self-service options for eligible organisations, begin rolling out from 19 October.

That makes this a good time to prepare. But preparation should start with identity and operating design, not with a support request.

What Atlassian organization consolidation is — and is not

An Atlassian organization is the company-level administration layer for Atlassian Cloud. Consolidation merges the source organisation into a destination organisation. Sites, products, and users are brought together under a shared administrative model.

This is not the same as a content migration from one Jira or Confluence site to another. Atlassian says the existing site URLs and apps on the source organisation are not changed during consolidation. Instead, the sites and apps are unlinked from the source and linked to the destination as they are.

That distinction matters. If the goal is to combine projects, merge Confluence spaces, or reduce the number of sites, organisation consolidation alone may not achieve it. Decide first whether you need an organisation consolidation, a product transfer, a site migration, or a combination of these activities.

Why this needs a cross-functional owner

The process affects more than the Atlassian administration team. It can change group names, user status, identity-provider behaviour, licence consumption, and the way administrators manage access after the merge.

Atlassian specifically warns that the process cannot be reversed. Treat it as an enterprise change that needs accountable ownership across at least identity and access management, security, legal or privacy where relevant, procurement or licensing, and the teams that administer Jira, Confluence, and Marketplace apps.

A technical checklist is essential. So is a clear answer to a more strategic question: What should the destination organisation’s future access model look like?

1. Confirm that both organisations are eligible

Atlassian consolidation requires both organisations to use Centralized User Management. Organisations on Original User Management need to follow a different transfer route.

Atlassian also lists several pre-consolidation conditions, including a common organisation admin, no Atlassian Support accounts in either organisation, no siteless products in the source organisation, reset user-access settings in the source, and no conflicting user status across the two organisations.

Do not assume these are administrative details to resolve later. They are preflight blockers. Establish the current state early and give each blocker a named owner.

2. Resolve conflicting user status before the merge

A user can be active in one organisation and inactive in the other. In that case, Atlassian says the user will be inactive in the merged organisation, which can result in product-access loss.

This is a high-impact issue because it can be discovered only when employees cannot access Jira, Confluence, or an app they need. Build a reconciliation list before the dry run:

• identify accounts that appear in both organisations;
• confirm whether each person should be active after consolidation;
• remove unnecessary product access where the person is intentionally inactive;
• document the intended access state in the destination organisation.

Do not treat “active” as a technical flag only. It represents an access decision that should match the user’s job and legal-entity context.

3. Review your identity provider and SCIM design

Identity provider and SCIM configuration are among the most important parts of the review. After consolidation, identity providers are managed by the destination organisation and may provision users across all sites, including those previously held by the source organisation.

For groups with separate legal entities, regulated data, or regional restrictions, that can create unintended access. Atlassian highlights potential risks to data residency, GDPR or privacy commitments, and access controls when synchronised groups include users who should not see content on every site.

Before consolidating, ask these questions:

• Which identity provider groups will synchronise into the destination organisation?
• Does group membership map cleanly to product and site access?
• Should all identity-provider-managed users be eligible for every site?
• Are there different legal-entity, geography, or confidentiality boundaries to preserve?
• Who will review access after the first SCIM provisioning cycle?

The goal is not to pause automation. It is to make sure that automated provisioning reflects your future access model rather than your historical organisational structure.

4. Prepare for group renames and changed admin rights

Groups with the same name in both organisations do not remain identical after consolidation. Atlassian says groups from the source are renamed using the source-organisation name to avoid conflicts. The source admin group is also renamed and no longer grants administrative permissions.

This can affect automation rules, licence assignments, access reviews, and internal documentation. It can also create a false sense of continuity if a group name looks familiar but no longer holds the same members or permissions.

Create an inventory of:

• source and destination groups;
• duplicates and similarly named groups;
• groups used for Jira, Confluence, and app permissions;
• groups used by SCIM or an identity provider;
• groups that grant administrator roles;
• automation, scripts, or integrations that reference group names.

Then define the destination-state group structure before consolidation. Do not rely on renamed legacy groups as the long-term access model.

5. Model licensing and Marketplace app effects separately

Organisation consolidation is not a billing consolidation. Atlassian states that billing and licensing for transferred sites are not automatically updated. Source-organisation administrators may become organisation administrators in the destination, which can affect product access and potentially increase licence consumption.

Marketplace apps also remain licensed per site and host product. Consolidation does not merge, deduplicate, or modify Marketplace app subscriptions; if the same app exists on several sites, those instances remain separate.

Before the change, ask finance and procurement to validate:

• the plan tier of each site and product;
• current and projected licensed-user counts;
• administrator group membership;
• separate Marketplace app subscriptions and renewal dates;
• the destination billing model after consolidation.

This keeps licensing work from becoming an unexpected post-merge issue.

6. Plan the operational window and a change freeze

During consolidation, the administration hubs for both organisations are read-only. Atlassian also says site and product changes are blocked during the consolidation window.

The userbase merge typically takes about one to four hours, while the Teamwork Graph merge normally takes around one additional hour. For large organisations, the total window can take four to six hours or more.

Prepare a practical change plan:

• appoint an incident and communications owner for the window;
• suspend non-essential user, group, site, and subscription changes;
• notify support teams, site administrators, and identity teams;
• establish how access issues will be triaged after the window;
• avoid creating dependencies on new Rovo Agents during the userbase merge, as Atlassian states they cannot be created while the userbase is locked. [1]

The product sites continue to operate, but administration is constrained. Plan accordingly.

7. Treat the dry run as an approval gate, not a formality

Atlassian’s process includes preflight checks and a dry-run report that shows expected changes such as group renames. The consolidation cannot proceed without written approval of that report.

Use the dry run to validate your assumptions, not merely to confirm that the project can move forward. Review user-status conflicts, group changes, administrative roles, sites, identity implications, and the intended post-consolidation ownership model.

If the output reveals something unexpected, resolve it before approval. The consolidation is not a convenient point for discovering an access design problem.

Your post-consolidation checklist

Once the consolidation is complete, check access and operational outcomes before declaring success.

1. Confirm user access to the right products, sites, and roles.
2. Review renamed groups and assign sustainable destination-state ownership.
3. Validate SSO and SCIM provisioning in the destination organisation.
4. Check administrator privileges and privileged-access groups.
5. Reconcile product licences, plan tiers, billing ownership, and Marketplace app subscriptions.
6. Reconfirm domain verification and security controls, including Atlassian Guard where applicable.
7. Record lessons learned before consolidating a further organisation.

Consolidation should simplify the access model, not just the org chart

The upcoming workflow changes may make the process more accessible to eligible Cloud organisations. They do not reduce the importance of preparation.

A successful consolidation is not defined by whether the source organisation disappears from the admin screen. It is defined by whether the destination organisation ends up with clearer ownership, least-privilege access, predictable provisioning, controlled costs, and fewer administrative exceptions.

If your organisation is assessing a consolidation, planning an Atlassian Cloud operating model, or preparing the identity and access work around a wider transformation, Lupus Consulting can help structure the readiness assessment and translate platform changes into a workable enterprise plan.