200+ Spaces, 2,500 Customers, Zero External Users – How We Scale Collaboration Using Atlassian's SOW

[#1]

Anyone who has spent time in this community has seen the same questions return in different versions.

1. How do you give clients real visibility into their Jira spaces without turning your project managers into human status reports?
2. How do you stop dozens of spaces from drifting into different configurations?
3. And why does setting up another Jira space still eat an afternoon and need juggling with schemes, screens, and permissions?

At KUMAVISION AG, we’ve juggled with all three at once. We implement ERP-systems for around 2,500 clients and run 200+ active customer spaces. This involves collaborating across company boundaries, and for years we relied on a custom-developed SharePoint customer portal, complemented by Excel-based tracking and email communication. As our business grew, this setup reached its limits, resulting in information silos, delayed updates, and critical details getting lost across multiple communication channels.

People assume managing that is a headcount question. The honest answer is a platform decision. Atlassian's Teamwork Collection — Jira, Confluence, Loom, and Rovo — gave us the base for how our teams and our customers work together. The Marketplace gave us the piece Atlassian doesn't build itself: cross-instance syncing, through K15t's Backbone Integration Platform. Together they let us do something we could not have built alone — turn customer collaboration into a product.

We call it the package KUMAfoundation, and what started as a tooling decision became a packaging decision. If every customer needs the same environment, the environment should be repeatable, because that’s the only thing that scales.

That’s where Atlassian's System of Work comes into action and offers collaboration that scales across thousands of customer relationships while staying governed and secure. Let me show you what I mean.

What's in the package

Every customer gets their own Jira — a Standard Jira license for ten users — plus Backbone Work Sync for Jira. Their instance, their data, their single source of truth.

Around that core sits the Teamwork graph. Each customer space is synced with our internal Jira, where our teams also run internal tickets through Jira Service Management. Every customer gets a dedicated Confluence site for documentation. Our own interface, jira4project365, ties Jira to Microsoft Dynamics 365 Business Central — projects, budget lines, work items, and time tracking flow between the ERP and Jira, which turns daily collaboration into reporting and invoicing. Rovo drafts specifications, whiteboards, and work items, and Loom carries feature explanations, release updates, and customer walkthroughs.

The piece only the Atlassian Marketplace could provide

Here is the first of those community questions — external collaboration — and the part the Atlassian platform alone doesn't solve. Putting 2,500 customers inside our own Jira was never an option: when we first looked at it we had 600+ customers, and licensing them in would have meant enormous cost and a security risks we didn't want. Separate instances were the answer, but separate instances need a bridge.

That bridge is Backbone Integration Platform for Jira, from the Atlassian Marketplace. It is the reason "every customer gets their own Jira" is viable at all: customer data stays on the customer's instance, nobody gets access into ours, and the two sides still work as one. The Atlassian Teamwork Collection gave us the products, the Marketplace lets us run them across company boundaries, at a scale no shared instance could govern.

The newest piece: Cloning the foundation

The second and third questions, drift and new setup overhead, met the same answer. Jira's native copy brings schemes but not content, so our template structure, the epics and tasks every space begins with, was rebuilt by hand or carried over with CSV exports and imports, and the sync was configured separately afterwards. 2–4 hours of admin work per customer, at 200+ spaces, adds up.

Backbone's new Quick Connect feature helps us resolve that challenge. It allows us to clone our customer space template, the configuration plus starter work items with hierarchy intact, meaning the CSV workaround is retired.

More importantly, this helps us scale quickly as the next customer costs minutes of work, not an entire afternoon. And because every space starts from the same proven template, 200 spaces stay in one configuration with reduced risks of errors or inconsistencies.

What convinced me as an admin is the governance aspect. Before anything is created, the receiving instance sees a request log listing every piece of cloning data — work types, screens, workflow schemes — each marked as newly created or reused, with a plain statement of which schemes fall back to Jira defaults. Nothing lands on a your partner’s instance unseen.

The clone is a fresh copy of our template and it does not stay tied to the space it came from. If we improve the template next quarter, existing customer spaces stay exactly as they are, and that is what we want. The sync is the ongoing relationship: it connects each customer space to our internal space and keeps both sides current.

Here’s a quick Loom video of how the new update works.

Clone and Sync a New Jira Space in One Flow with Quick Connect 

That ongoing half is where the daily value lives after the initial setup is completed. Backbone Integration Platform gives us near real-time work item synchronization across 200+ active customer spaces. For example, customers raise development requests in their space and communicate updates via work item status, descriptions, comments, and time logs. And because everything is synced in real-time, no one has to jump across Jira instances and manually copy-paste information.

Two Atlassian ecosystem partners, one feedback loop

The KUMAfoundation is our offering, but it stands on layers we didn't build alone. Atlassian builds the platform, and K15t extends it with Backbone Integration Platform for cross-instance collaboration and scalability capability. And we, as a Solution Partner, assemble those pieces into something customers actually use.

What this proves

Scale, first. A repeatable foundation is the only reason 2,500 customer relationships and 200+ active synced spaces are manageable for a team our size. With starting a space now down to a few minutes, adding the next customer no longer competes with serving the current ones, that is what scalable collaboration means in practice.

Governed, second. Nothing reaches an instance unreviewed: the request log shows every piece of data being cloned before it exists. And after the cloning is completed, both sides get granular control over what Jira data exactly gets synced.

Secure, third. Customer data stays on the customer's instance. Nobody needs access into our internal Jira, and no external user ever works inside it.

Over to you

I said earlier that the clone and the sync are two different jobs that Quick Connect puts in one flow. In our world they belong together, every customer space needs the living connection.

But I keep thinking about the setups where they don't. Where the cloning part is the whole job: a sandbox, an internal rollout, a starting point for a new team, and no sync is needed.

I'm curious how this looks where you work. The last time you set up a space from an existing one — did it need to stay connected, or was it finished the moment it existed? And if the answer is "depends," what tips it one way or the other? Tell me in the comments.

P.S.
If you're running per-customer delivery on Atlassian and want to compare notes, reach me directly here on Community or visit our website.

Plus, Quick Connect just rolled out in Backbone Work Sync. If your workflows require anything related to Jira<->Jira syncing, it's worth a look at their Marketplace listing.

[Elena_Elevatic]

Hey @Carsten Severin _KUMAVISION AG_ Great breakdown of the governance angle especially — the "nothing lands unseen" request log is the part people underestimate until they've had a sync go sideways on someone else's instance.