To Merge or Separate: Which Approach Works Best During an Atlassian Cloud Migration?

[#1]

Moving your Atlassian instance to the cloud is more than just a technical upgrade — it’s an opportunity to rethink how your teams, data, and tools are organized. One of the key decisions you’ll face is whether to merge multiple instances into one unified cloud site or to keep them separate under multiple cloud sites. Neither approach is universally “right” — the best choice depends on your organization’s structure, compliance needs, and long-term goals.

Below, we explore the pros, cons, and important considerations for each path.

---

Why You Might Merge Instances During a Migration

1. Simplified User Experience & Unified Access

Switching between multiple URLs or instances introduces friction. Merging ensures that users log in to a single site and find all relevant projects, data, and dashboards in one place — reducing confusion and duplication.

2. Unified Data, Better Visibility

Having a single instance helps prevent data silos and duplicated information, improving consistency and making reporting and analytics far easier.

3. License & App Consolidation

Consolidating users across instances can help optimize app licensing. Rather than paying for multiple smaller user tiers, you may achieve efficiencies by leveraging a single, larger instance.

4. Efficiency in Post-Merger IT Integration

If your organization has recently been through a merger or acquisition, merging Atlassian systems can streamline governance, standardize configurations, and reduce overhead across IT operations.

---

Key Challenges When Merging

1. Project / Key Collisions

If two instances have projects with overlapping keys (e.g., “PROJ”), you'll need to rename keys or otherwise resolve collisions before migration — failing to do so may break linkages or cause data conflicts.

2. Increased App Licensing Costs

When you merge, the total number of users for each app may grow significantly. Even if many users don’t use certain apps, licensing tiers are often determined by the total user count — which can raise costs.

3. Security & Compliance Risks

Combining instances may inadvertently grant broader access to sensitive data. If some teams require tighter permissions or separate trust zones, merging could conflict with your compliance or internal security model.

4. Data Residency / Regulatory Constraints

If your current instances are bound to different geographic locations (for data residency or compliance), merging them may violate those requirements.

---

Why You Might Separate Instances During Migration

1. Control App Costs

By partitioning users into different instances, you can more precisely allocate app licenses only to those who need them — leading to potential cost savings in large organizations.

2. Maintain Data Isolation & Compliance

Separating instances ensures that teams, departments, or business units remain isolated. Sensitive or regulated data can stay in its own instance, reducing risk from broad access.

3. Meet Data Residency Requirements

If certain teams or regions must keep data within specific geographic boundaries, multiple cloud sites allow each group to adhere to distinct residency policies.

4. Enable Easier Divestitures

If one part of your organization may be spun off or sold in the future, keeping that division on a separate instance makes the separation process simpler and cleaner.

---

What to Consider Before You Choose

1. Licensing model & Cloud plan

If you’re not on Atlassian’s Enterprise Cloud plan, each instance may require its own license. For Standard & Premium plans, this could lead to duplication of licensing costs across multiple instances.

2. Project / Space Segmentation

You’ll need clarity on which projects, spaces, or data belong in which instance. Splitting data, especially when cross-team collaboration exists, can be complex.

3. App and Integration Compatibility

Some apps or integrations may not support multi-instance configurations or may complicate cross-instance workflows.

4. Org Strategy & Future Scale

What is your long-term plan? Do you aim to centralize tools, or will your business model require decentralized autonomy in the future?

5. Governance, Administration & Support Overhead

More instances mean more admins, more oversight, more homes for automation rules, and more complexity in maintaining consistency across instances.

---

Decision Framework: Merge vs Separate

Factor	Favor Merge	Favor Separate
User experience & simplicity	✅ Single login, unified dashboard	Might require switching between instances
Licensing & app costs	Potential for savings if usage overlaps	Better control — pay only for required users
Data governance / compliance	Risk of over-exposure unless carefully managed	Stronger boundary between teams / data domains
Data residency & locality	Challenging if instance boundaries differ	Easier to satisfy regional rules
Future spin-offs / divestitures	More complex disentanglement	Cleaner separation if a unit is spun off

---

Final Thoughts & Best Practices

• Assess first. Do a deep audit of your current instances — users, apps, cross-dependencies, data sensitivity, integrations — before making decisions.

• Engage stakeholders early. Compliance, security, business units, and IT all need a voice in whether merging or separating aligns with their priorities.

• Pilot smaller merges. Test the process on noncritical teams first to uncover pitfalls (app migrations, key collisions, permission conflicts).

• Document mapping & transformation decisions. Whatever your route, having a transformation playbook (renaming keys, reconfiguring permissions, mapping users, etc.) is essential.

• Plan for change management. Communicate to users, train, and offer transition support — migrating instances is not just technical, but cultural.

Ultimately, there is no one-size-fits-all answer — the “right” decision is the one that best supports your organization’s technical constraints, security obligations, financial model, and growth plans.