A pop-up survey could appear while you're here --curious what it's for? Click here to learn more!
×Community resources
Community resources
Community resources
Your Guide to Site Transfers and Org Consolidations
As CSMs, we often help guide customers who are planning an upcoming Atlassian Cloud site transfer and/or organization consolidation. These are considered merges, not migrations, and usually are the results of bigger changes—like a merger or acquisition, a re-org, or a strategic push to standardize tools—and it affects everyone from system admins to business stakeholders.
This article is for:
- Org admins planning or executing a consolidation of Atlassian Cloud sites and organizations
- IT, security, and business stakeholders who need to understand the options, risks, and trade-offs before giving the green light
Below, we’ll walk through what merging actually means in Atlassian Cloud, the main paths you can take, and the key decisions and risks to align on before you start.
This guide walks through:
- The main ways to merge in Atlassian Cloud
- What to prepare before you start
- How merges affect billing and licenses
- Special considerations for Enterprise, identity providers (IdPs), and Active Directory (AD)
- Best practices
For deeper technical steps, see:
- Atlassian organization consolidation guide:
Atlassian Organization consolidation guide | Atlassian Cloud | Atlassian Support - Copy product data between sites:
Transfer data from one Atlassian app instance to another | Atlassian Support - Transfer products to another organization:
Transfer all apps to another organization | Atlassian Support
What “Merging” Means in Atlassian Cloud
There are two main pieces to most “merge” plans:
- consolidating your admin layer (organization), and
- moving product data between sites.
Scenario A: Organization Consolidation (Admin Layer)
What it is
Organization consolidation focuses on your admin and security layer, not on moving Jira or Confluence data. It brings together:
- Users and groups
- Billing and subscriptions
- Organization-level security and admin controls
Outcome
- You manage all your sites under a single Atlassian organization.
- You get a centralized view of users, policies, and billing.
What it is not
- It does not move Jira or Confluence data between sites.
- It does not automatically migrate projects, spaces, or Marketplace app data.
Use this when your goal is centralized administration, billing, and security, while leaving products and sites largely as they are.
Scenario B: Cloud-to-Cloud Data Migration (Product Data)
What it is
Cloud-to-cloud data migration moves actual product data between Atlassian Cloud sites, such as:
- Jira Software and Jira Service Management projects
- Confluence spaces and pages
- Related users and groups (as supported by the tools)
Tooling
- Jira Cloud Migration Assistant (JCMA):
Jira Cloud Migration Assistant | Atlassian Support - Confluence Cloud Migration Assistant (CCMA):
Confluence Cloud Migration Assistant | Atlassian Support
Use this when your goal is to reduce the number of sites and bring related Jira/Confluence data together.
High-Level Journey to a Merge
Most real-world scenarios combine organization consolidation with one or more cloud-to-cloud migrations.
Scenario A: Organization Consolidation (Admin Layer)
Typical flow:
- Check centralized user management status
- Confirm how users are managed across your organizations (e.g., domains, directories, IdPs).
- Pre-flight checks
- Clean up potential blockers like unverified domains, conflicting IdP setups, or special-purpose accounts.
- Review API keys and admin accounts.
- Submit a request to Atlassian Support
- Open a request at: Atlassian Support
- Dry run
- Atlassian generates a report outlining expected changes, conflicts, and risks.
- Execution
- Atlassian engineers perform the consolidation.
- Admin screens may be placed in read-only mode during the merge window.
- Post-merge configuration
- Re-verify domains.
- Validate user access.
- Reconfigure any organization-level settings and security controls as needed.
Scenario B: Cloud-to-Cloud Data Migration (Product Data)
Typical flow:
- Define scope and target, recommended to open a ticket with Atlassian support for guidance
- Open a request at: Atlassian Support
- Decide which site will be your long-term “destination”.
- Agree on which projects, spaces, and products will move.
- Prepare and clean up
- Archive unused or legacy projects and spaces.
- Clean up users and groups (duplicates, inactive accounts, naming).
- Run test migrations
- Use JCMA/CCMA into a test or sandbox environment where possible.
- Validate permissions, links, and key data.
- Execute production migrations
- Run migrations in planned windows, potentially in waves.
- For complex setups, consider engaging Atlassian Support or an Atlassian Solution Partner.
- Post-migration validation
- Confirm that data, permissions, and key Marketplace apps function as expected.
- Perform any necessary manual cleanup.
Prerequisites Before You Merge
A bit of prep goes a long way toward a smooth merge.
1. Licensing and Plans
- If you’re on Enterprise, work directly with Atlassian Support to plan your approach to organization consolidation:
Atlassian Support - If you’re on Premium, remember that Premium includes one sandbox per site. You may need to adjust if you have extras.
2. User Management
- Make sure you have at least one organization admin per organization.
- Clean up unnecessary or special-purpose accounts.
- Resolve status conflicts for users who share the same email across organizations (e.g., active vs. deactivated).
3. Technical and Operational Limits
- Avoid leaving siteless products in the source organization; confirm what can and cannot be transferred.
- Large environments have limits on total sites, users, groups, and memberships.
- These are typically validated during the pre-flight step with Atlassian.
4. Conflict Resolution Rules (What to Expect)
- Groups with the same name may be renamed to avoid collisions.
- Admin groups from the source may be renamed and may not retain elevated permissions.
- Plan to review and re-grant the right admin roles after the merge.
5. Safeguards and Limitations
- Some admin experiences may be temporarily read-only during consolidation.
- Organization merges are irreversible with current tooling; there’s no automated “un-merge”.
Key Risks and Impact Areas
Understanding the trade-offs up front helps you plan and communicate effectively.
- Irreversibility
- Once organizations are consolidated, there’s no automated rollback.
- Manual cleanup
- Expect to deal with duplicate users and groups, naming conflicts, and permission reviews.
- Tooling limitations
- Some Marketplace apps and data types (for example, certain team-managed project configurations) may need separate or manual migration steps.
- Performance risks
- Large migrations or consolidations can temporarily affect destination site performance; plan for off-peak windows.
- Billing and entitlements
- User tiers may increase when user bases are combined.
- Some entitlements can only be held by a single organization.
- Data residency and compliance
- Confirm data residency requirements and target regions before moving data.
- User communication
- Users may see changes to URLs, login flows, SSO/MFA, or maintenance windows. Plan how you’ll message this.
Best Practices for a Successful Merge
A few habits that consistently improve outcomes:
- Thorough pre-migration cleanup
- Remove inactive users; resolve duplicates.
- Standardize group names where it makes sense.
- Test before go-live
- Use sandboxes and test migrations.
- Validate permissions, key workflows, and Marketplace apps.
- Communicate early and often
- Share timelines, expected impacts, and any actions users will need to take.
- Provide clear “what’s changing” and “what’s staying the same”.
- Backups and documentation
- Export data where possible and appropriate.
- Capture key configuration details so you can validate them after migration.
- Careful scheduling
- Choose low-usage windows and coordinate with internal stakeholders.
- For larger changes, coordinate timing with Atlassian Support.
- Engage Atlassian or partners for complex scenarios
- Large user bases, multiple IdPs, strict compliance requirements, or complex app landscapes are good candidates for extra help.
License, Billing, and Cost Impacts
Merging sites and organizations often changes how you’re billed.
1. License Consolidation
- User counts are based on unique accounts, so the same email across multiple sites typically counts once.
- All products in a given organization need to align on plan tier (Standard, Premium, or Enterprise as applicable).
- Premium customers get one sandbox per site; factor this into your planning.
2. Billing Cycles and Invoices
- You may choose to co-term billing (for example, align renewals to a single date).
- After consolidation, you’ll generally receive a single invoice per billing cycle that covers all products and users.
- Prorated adjustments or credits may apply when dates or tiers change.
3. Marketplace Apps
- Post-merge, you’ll typically move toward one subscription per app in the destination setup.
- App user tiers follow the host product’s user counts; if those increase, app tiers may increase too.
4. Entitlements and User Tiers
- Combining users across sites often pushes you into a higher user tier, which can increase costs.
- Some advanced entitlements (for example, Enterprise-level capabilities) are tied to a single organization and may need review.
Before you merge:
- Clean up your user list.
- Align plan tiers and preferred billing cycles where possible.
- Decide which redundant app subscriptions to keep or retire.
Merging Sites Across Different Atlassian Organizations
If your sites live in separate Atlassian organizations, you’ll usually:
- Choose the destination organization
- Decide where products, users/groups, billing, and security policies will live long-term.
- Transfer products between organizations
- Copy data between sites when needed
- For example, if you’re consolidating Jira projects or Confluence spaces:
- Transfer data from one Atlassian app instance to another | Atlassian Support
- (Optional) Request organization consolidation
- To fully unify users, groups, and billing, review:
- Can I merge my Atlassian organizations? | Atlassian Support
- Post-migration cleanup
- Reconfigure domains, SSO, and provisioning as needed.
- Align Marketplace apps and validate permissions.
Special Case: Enterprise Plans
If one or more of your organizations use Enterprise plans, there are additional considerations around:
- Advanced user management and security controls
- Entitlements that can only be held by a single organization
- Sandboxes and release tracks
- Billing and commercial terms
Enterprise customers should work directly with Atlassian Support at the planning stage to determine the right approach to organization consolidation and product moves:
- Atlassian Support: Atlassian Support
Merging Sites with Different Identity Providers (IdPs)
If your organizations use different IdPs, you’ll need a clear identity strategy before you merge.
Planning and Prerequisites
- Choose your destination IdP strategy
- Decide which IdP will be authoritative for each verified email domain.
- One IdP per domain
- Atlassian Cloud supports a single IdP per verified domain.
- Verify domains
- Ensure all email domains are verified in the destination organization.
- Inventory users
- Identify overlaps and duplicates across IdPs and decide how you’ll map or re-provision accounts.
Risks and Impacts
- IdP consolidation
- Users tied to decommissioned IdPs may need to be migrated or re-invited under the destination IdP.
- Login experience changes
- The login page, SSO provider, and MFA requirements may change; communicate this proactively.
- SSO/SCIM changes
- You may need to reconfigure SSO and provisioning (SCIM), and deprovision/re-provision some accounts.
- Manual cleanup
- Expect some work resolving duplicate accounts and conflicting group memberships.
Best Practices
- Align on an IdP strategy early and test with a staging environment if possible.
- Document and communicate upcoming changes to the login experience.
- Coordinate with your identity/security teams on timing and user messaging.
Helpful references:
- Configure SAML SSO with AD FS:
Configure SAML single sign-on with AD FS | Atlassian Support - Understand user provisioning:
Understand user provisioning | Atlassian Support - Azure AD provisioning tutorial for Atlassian Cloud:
Configure Configure Atlassian Cloud for for automatic user provisioning with Microsoft Entra ID - Microsoft Entra ID
Merging Sites with Different Active Directory (AD) Setups
If your organizations use different AD setups, you’ll want a clear source of truth per domain.
Consider:
- Authoritative directory per domain
- Decide which AD/IdP combination is the source of truth for each domain.
- Align user attributes and group mappings accordingly.
- Provisioning and SSO flows
- Test SSO and provisioning flows before and after the merge.
- Document expected changes and potential rollback steps.
Quick Reference: Decision Matrix
|
Scenario |
Recommended Path |
Key Considerations |
|
Centralize billing and admin; keep data where it is |
Organization consolidation via Atlassian Support |
No data moves; expect group rename collisions and admin review |
|
Reduce number of sites; combine Jira/Confluence data |
Cloud-to-cloud migration (JCMA/CCMA) |
Test migrations first; review app/data limitations |
|
Sites live in different Atlassian organizations |
Product transfer + optional org consolidation |
Choose a destination org; update domains, SSO, billing |
|
Different IdPs or AD setups |
Consolidate IdP/AD per domain, then merge |
One IdP per domain; communication about login changes is critical |
Helpful Links
- Atlassian Support Portal:
Atlassian Support - Should I merge my organizations?:
Can I merge my Atlassian organizations? | Atlassian Support - Atlassian organization consolidation guide:
Atlassian Organization consolidation guide | Atlassian Cloud | Atlassian Support - Copy product data between sites:
Transfer data from one Atlassian app instance to another | Atlassian Support - Transfer products to another organization:
Transfer all apps to another organization | Atlassian Support - JCMA overview:
Jira Cloud Migration Assistant | Atlassian Support - CCMA overview:
Confluence Cloud Migration Assistant | Atlassian Support
Merging Atlassian Cloud sites and organizations is less about a single migration window and more about a coordinated program: aligning identity and security, choosing the right target architecture, cleaning up legacy data, and communicating changes clearly to your users.
As an admin, use this guide as a planning framework:
- Confirm whether you need organization consolidation, cloud-to-cloud data migrations, or both
- Involve identity/security owners early when multiple IdPs or AD environments are in play
- Run test migrations and validate permissions, apps, and user experience before committing to production
As a stakeholder, focus on the business outcomes you want (simpler governance, cost optimization, fewer tools, better security posture) and use those to guide scope, timelines, and risk tolerance.
For complex environments—multiple organizations, Enterprise plans, strict compliance needs, or a large app footprint—partnering with Atlassian Support or an Atlassian Solution Partner can significantly reduce risk and effort.
Have questions about a specific scenario, or want to sanity-check your merge plan? Share your context in the comments and the Community can help you think through options and trade-offs.
Was this helpful?
Thanks!
Heidi van Gennep
2 comments