Scaling Jira DevOps: A Guide to Multiple Sandboxes in Jira Cloud

For years, Atlassian admins have faced a bottleneck that would make any DevOps engineer cringe: the single sandbox limitation.

If you are managing a complex Jira Cloud instance, you know the drill. You have one team trying to test a new workflow, another team validating a Marketplace app update, and a third trying to dry-run a project migration. With only one sandbox, everyone is stuck in a single lane. Work gets overwritten, configurations clash, and eventually, someone says:

Let's just build it in Production and hide it with permissions.

(We all know how that ends.)

With Multiple Sandboxes now generally available for Jira Cloud Premium and Enterprise, we finally have the infrastructure to run parallel work streams safely. But just having more environments doesn't solve the chaos—it just scales it if you don't have a strategy.

This guide explains how to architect, manage, and govern multiple sandboxes to build a robust change management pipeline.

---

The Context: Why One Sandbox Wasn't Enough

In the past, the single sandbox acted as a staging environment for everything. It was the wild west where scripts, automations, and schemes mingled together.

The risks were tangible:

• Configuration Conflicts
  Team A changes a shared screen scheme that breaks Team B’s testing.

• Refresh Fatigue
  Refreshing the sandbox to get fresh production data wipes out everyone's work-in-progress, not just yours.

• Bottlenecks
  Critical hotfixes wait in line behind long-term development projects.

The new capability allows:

• Enterprise plans to provision up to 5 sandboxes (allocatable across sites)
• Premium plans to purchase additional sandboxes beyond their complimentary one

This shifts us from a "Sandbox" model to a true "DevOps" model.

---

Prerequisites & Setup

Before spinning up environments, ensure you meet the requirements.

License Requirement

• Jira Cloud Premium or Enterprise

Role Required

• Organization Admin
  (Site admin is not sufficient)

Cost Implications

• Enterprise: 5 complimentary sandboxes included
• Premium:
  • 1 complimentary sandbox per site
  • Additional sandboxes ≈ $10,000/year (verify current pricing)

---

Strategic Use Cases: How to Utilize Your Environments

Don’t create sandboxes just because you can. Assign a clear purpose to each environment.

Below are the three most effective architectures used in real client deployments.

---

1. The Classic CI/CD Pipeline (Dev → UAT → Prod)

The gold standard for strict ITSM governance.

• Sandbox 1 – Dev
  The dirty room. Rapid experimentation, mocked data, broken configs allowed.

• Sandbox 2 – UAT / Staging
  A strict mirror of Production.
  Only validated changes arrive here. Business stakeholders perform UAT.

• Production
  The live environment.

---

2. The "Project Omega" Isolation

Ideal for massive restructuring initiatives.

Example:
Merging two Service Management help desks or renaming Project Alpha to Project Beta.

• Dedicated Sandbox
  • Used exclusively for the initiative
  • Refreshed once from Production

Benefit:
Weeks of heavy reconfiguration without worrying about:

• Weekly refreshes
• Other admins overwriting schemes

---

3. The "App Safety" Zone

Marketplace apps are powerful—but invasive.

• Dedicated Sandbox
  • Test new apps
  • Validate major upgrades of critical tools
    (e.g., ScriptRunner, Automation for Jira changes)

---

Step-by-Step: Managing Multiple Sandboxes

Creating sandboxes is easy. Managing their data lifecycle is where expertise matters.

1. Navigate to Admin Hub
   admin.atlassian.com → Products → Sandbox

2. Create Sandbox

   • Click Create sandbox
   • Select the production site to mirror

3. Name It Clearly
   ❌ sandbox-1
   ✅ finance-flow-upgrade, staging-environment

4. Data Copy Options

   • Copy production data (attachments/media often excluded or limited)
   • Or start empty

5. Plan for Time

   • Large instances may take hours to copy
   • Schedule for off-hours if needed urgently

---

Common Pitfalls & Debugging Tips

Even with multiple environments, problems happen. Watch for these.

---

1. The ID Mismatch Trap

Jira Cloud relies on internal IDs (customfield_10023) which often differ between environments.

Issue:
An automation exporting JSON using id=10023 in Sandbox fails in Production where the field is id=10045.

Fix:

• Reference fields by Name, not ID
• Use smart values or dynamic lookups wherever possible

---

2. Integration "Ghosting"

After copying production data:

• Webhooks and integrations may:
  • Be copied but disabled
  • Or worse—still active and pointing to live systems

Debug Tip:
Immediately after refresh:

• Disable all outgoing webhooks
• Disable mail handlers
  This prevents spamming real users with "Test" notifications.

---

3. App Data Persistence

Third-party app data is not always copied.

Action:

• Verify app-specific behavior
• Some apps (Assets, Timesheets, etc.) may require:
  • Separate XML export/import
  • App-level sync or reconfiguration

---

Best Practices for Optimization

Establish a Refresh Cadence

• Dev Sandbox: Monthly or on-demand
• UAT Sandbox: Only before major release cycles

Assign "Sandbox Owners"

• One admin per sandbox
• They control refresh timing

This eliminates:

“Who deleted my config?!” Slack messages

Use Configuration Managers

Sandbox testing is native—but promotion is still manual.

Consider tools that support diff & merge:

• Salto
• Appfire CMJ

These reduce human error during deployment.

---

Conclusion

Multiple Sandboxes mark a maturity milestone for Jira Cloud.

They move teams away from:

• Cowboy coding in Production
  towards:
• Professional, reliable Atlassian administration

By isolating development streams:

• Risk decreases
• Deployment stress drops
• Velocity increases

Start small.
Spin up a second sandbox for your next major initiative—and experience how fast teams move when Production is no longer fragile.

---

👉 Contact me for expert Atlassian consulting
📬 Subscribe for more Atlassian automation ideas, real-world tips, and strategies