Atlassian’s official recommendation for Jira Service Management: consolidate into fewer projects. Use custom fields like Components or Teams to logically separate work streams. Only break out when a team’s workflow becomes genuinely unique.
Every hyperscaler I have worked with runs the opposite pattern. Many projects, many spaces, sometimes multiple Jira instances entirely. Or they abandon Jira for a custom system like Google’s Buganizer.
Both are right. For different problems.
Why Atlassian recommends few
Fewer projects is easier to administer. Search works better. Automation rules apply cleanly. Reporting is uniform. Custom fields let you slice by team, service, or customer without needing new projects. For a company with 50 to 500 people and one production system, this is the right advice. The overhead of five projects with slightly different configs is not worth the isolation you get.
Why hyperscalers use many
At hyperscaler scale, three things break the consolidation model.
One: security and compliance boundaries
A customer-facing incident ticket cannot sit in the same project as an internal HR ticket. Different access, different retention, sometimes different regulatory scope (SOC 2 vs GDPR vs FedRAMP). Custom fields do not enforce boundaries. Projects do.
Two: blast radius
A bad automation rule, a permission mistake, a broken workflow update. In one big project, a mistake affects everyone. Split projects contain the damage. This is the same reason hyperscalers use cell-based deployments.
Three: team autonomy at scale
A hundred service teams do not want to negotiate a shared workflow. Each service owns its lifecycle, its priorities, its on-call rotation. Forcing them into one project’s config is a coordination tax that grows with headcount.
What breaks when you try one project at scale
Even if you push through and consolidate, the config collapses under its own weight past a certain size:
- Workflow bloat. Every team wants slightly different states. You end up with a shared 50-state workflow that everyone learns to ignore.
- Custom field explosion. 200+ fields, most irrelevant to most tickets. Create screens become unusable. Naming collisions (“Priority,” “Priority 2,” “Business Priority”) pile up.
- Blast radius. A bad automation rule, permission edit, or workflow update affects every team at once. There is no cell-based rollout for JSM config.
- Scheme coupling. Workflow, notification, screen, and permission schemes are all shared. Any team’s need becomes negotiation with every other team.
- Migration debt. When you eventually outgrow the model, splitting is expensive because everything is tangled: custom field references, automation rules, integrations, historical reporting all cross-cut the one project.
The one-project pattern works up to maybe 500 engineers or 20 service teams. Past that, the coordination cost of every config change exceeds the administrative benefit of a single project.
What Google does instead
Google’s internal system, Buganizer, is not many projects. It is one system with strong hierarchical components. Every bug is filed against a componentID that maps to a service and team. Permissions, routing, and ownership flow from the component tree. It is Atlassian’s “few projects, many components” pattern, but with the component tree treated as a first-class boundary, not a filter field.
That is the pattern that scales. One consistent system. Strong hierarchical structure. Boundaries enforced by structure, not by convention.
Why nobody else runs Buganizer
Google does not sell it. The external Google Issue Tracker is a narrow slice exposed to specific approved partners, not a general product. And even if it were, no competitor is going to run their internal operations on infrastructure owned by a rival cloud. AWS, Microsoft, and Meta each built their own. Microsoft eventually commercialized theirs as Azure DevOps. At hyperscaler scale, ticketing is deeply wired to how the company runs (deploy pipelines, alerting, on-call, code review, comp reviews). Replatforming to a competitor’s tool would be a multi-year project with negative business value. Every one of them ends up with a purpose-built system, either homegrown or forked from something they controlled.
What actually works, by scale
| Org size | Pattern that works |
|---|---|
| Under 100 | One JSM project, custom fields, one workflow |
| 100 to 1,000 | One customer-facing project, separate internal, dev, security |
| 1,000 to 10,000 | Multiple JSM projects grouped by domain, shared schemes, strict change control |
| Over 10,000 | Multi-instance Jira with strong boundaries, or a custom system with a component tree |
Five real reasons to split a project
Ignore org chart, headcount, or “team wants its own space.” Split when:
- Access requirements differ (customer data vs internal)
- Compliance scope differs (SOC 2 vs GDPR vs FedRAMP)
- Retention or deletion policy differs
- SLA structure differs (24x7 customer vs 9-to-5 internal)
- Workflow states genuinely cannot be unified without half the team ignoring them
If none of the five apply, Atlassian is right. Consolidate.
The trap
The failure mode most companies hit is neither too few nor too many. It is inconsistent. Twelve projects, each with a slightly different workflow, no shared schemes, no way to search across them. That is the worst of both worlds. Fewer overhead controls than one project. Less isolation than actual multi-tenancy.
Whether you consolidate or split, pick one and enforce it. The structure matters less than the discipline of keeping the structure clean.