17 minute read
- One Azure DevOps project for a large estate is not the risky option; it is the option whose risks are visible, ownable, and governable.
- Multiple Azure DevOps organisations should be treated as temporary debt where coordination exists, not as long-term architecture. see why — jump to the section that argues this
- Fragmented Azure DevOps estates already run serious unmanaged coordination risks whose costs are diffuse, invisible, and borne by people without power to change them. see why — jump to the section that argues this
- Write explicit risk registers for both the current fragmented Azure DevOps estate and a proposed single-project estate before deciding on consolidation.
- Treat multiple Azure DevOps organisations where coordination exists as temporary debt with a repayment date, not long-term architecture.
One Azure DevOps Project for fifty products and fifteen hundred people sounds like a considerable risk: a large backlog, shared administration, and structural mistakes that could affect many teams. A Project per product family offers a recognisable kind of containment. If you are advising on that decision, the difficult question is what the separation will do to work that crosses those product boundaries every day.
I keep being asked a version of this question. The recent one came with four specific concerns. Hundreds of people creating shared queries could make a mess; restricting creation to a few people could create a queue. Pipelines could become difficult to navigate and secure. Analytics could return more data than a useful view needs. Azure DevOps Team administration could become so restricted that managers cannot do their jobs.
Those concerns belong in the decision. So do duplicated bugs, manual handovers and reporting maintained outside the platform. For products whose teams coordinate frequently, a shared Project is the stronger starting point, provided leadership funds permission reviews, configuration ownership and exception decisions, and delegates administration deliberately. Neither headcount nor the apparent containment of separate Projects settles which option carries the greater risk.
Both options can have a risk register. Compare them using the work people actually do, including the risks the existing arrangement already carries. Shared administration is an explicit obligation in a consolidation proposal. Duplicate records, repeated checks and reporting maintenance can be spread across everyday work, making their combined cost less obvious. Bring both into the comparison; neither arrangement is exempt from ownership and review.
The risks of one shared Project
The four concerns in the original question expose risks that need explicit design and ownership:
The consequences of structural mistakes become wider. A poorly designed permission model or product hierarchy can affect many products. Area Paths, which classify work and configure Team scope, need deliberate ownership. Access decisions need review appropriate to the information involved.
A common work-tracking process needs agreement. Business units with genuinely incompatible processes may need separate Projects. Consolidation does not remove that disagreement; it makes resolving it a prerequisite.
Shared resources need navigation and curation. Repository naming matters. Pipelines have folder and object permission mechanisms, so they should not be treated as one unavoidable flat list. Useful Analytics views need an explicit scope. Shared query folders need owners who can maintain them without making every change a central administration request.
Administration needs delegation. Keeping a small set of Project administrators is compatible with delegating narrower responsibilities. Decide which teams can manage which configuration and access. Simply removing managers’ former Project administrator rights leaves the work they used those rights for unresolved.
Scale needs a resource assessment. Microsoft’s guidance warns against concentrating many thousands of repositories and most permission-protected resources in a single Project. Its permission guidance also discusses the cost of complex access-control structures. Neither establishes a comfortable repository threshold for your configuration, and neither makes 1,500 people a capacity test.
Leadership can approve consolidation without funding its governance. If it never settles who can change the shared structure, who maintains it, or how exceptions are decided, teams can become dependent on an overloaded central group. It can also leave nominal standards that nobody has the capacity to enforce or improve.
These obligations need named owners and continuing capacity in the business case. A shared Project without that commitment can make administration worse. Separate Projects can contain some local mistakes, although cross-product work will still need its own owners and controls.
The risks of separating connected work
In twenty years of consulting on organisations using fragmented Azure DevOps configurations, I have repeatedly encountered a different set of costs. Organisations call for help when something already hurts. That experience does not establish that every organisation with multiple Projects has these problems.
The recurring pattern is that the work remains connected while its records, permissions and planning views are separated. People compensate:
- Bugs acquire duplicate records. One team tracks the customer problem while another tracks the component fix. Unless someone owns the relationship and completion condition, either record can close while the customer’s problem remains.
- People assemble their work from several Team views. End-to-end testing and cross-product coordination can require repeated checks across boards. A board that shows a team’s local work does not necessarily show everything needed to resolve the customer’s issue.
- Planning and execution acquire mirror backlogs. Copies can have different descriptions, access restrictions and update habits. Someone must maintain the correspondence and resolve disagreement.
- Reporting acquires external maintenance. Native cross-Project features exist, but they have limits. Where those limits matter, custom dashboards or reporting integrations require continuing support. That cost belongs alongside the cost of shared-Project administration.
- Shared components remain without clear ownership. A link or repository reference can reveal a dependency without identifying who will resolve it. Consolidation can improve visibility; it cannot assign responsibility on its own.
Ask who owns a bug from the first customer report through to a verified fix across products. If the answer is clear and the handover works, record that strength in the current arrangement. If it is unclear, investigate the records, permissions and completion rules that produced the gap. An organisation can govern these costs across Projects; the question is whether yours does, and at what effort.
Project creation often happens locally, in response to a product, permission or administrative need. Its coordination consequences can extend beyond the person making that decision. Leadership has to settle the structural decisions that shape what people can see and change, rather than rely on instructions to compensate for those decisions. Technical practitioners can expose those consequences. They cannot fund continuing governance or settle competing business obligations by changing a tool setting.
Separate the Project decision from the Organisation decision
Azure DevOps Project: a container for work tracking, repositories, pipelines and Team configuration. Lowercase project refers to an initiative or the ordinary business meaning.
Azure DevOps Organisation: the platform container that holds Projects. Lowercase organisation refers to the business.
Azure DevOps Team: a configured grouping within a Project, with its own work views and settings. Lowercase team refers to the people working together.
Area Path: a node in the hierarchy used to classify work items and configure a Team’s scope.
An Azure DevOps Organisation can contain several Projects. A decision to use several Projects within one Organisation differs from a decision to distribute those Projects across Organisations. Reporting, work item movement, identity and billing do not encounter the same constraints at Project and Organisation boundaries.
This distinction matters when someone says that moving a bug loses its history, that reporting cannot span several Organisations, or that people need another licence. Establish which platform boundary and operation they mean before adding that cost to the business case.
The word project also invites a poor structural choice. An Azure DevOps Project can outlive a funded initiative and hold work for products that persist through many initiatives. Creating another container whenever a new initiative starts can leave the enduring product work distributed across containers after the original funding arrangement ends. Choose the Project boundary around the work that needs to stay connected, with explicit reasons for exceptions.
Work item movement needs particular care. Microsoft’s documented native move within an Organisation retains parent-child links, although child items do not move with the parent and State and Reason reset. Some work item types cannot use that operation. Cross-Organisation copying or migration is a different operation with different limitations. A client’s observation, “It does appear to work, but it’s lossy”, came from that broader cross-Organisation handover discussion. It is an illustration of their experience, not evidence that every cross-Project move loses history or links.
Licensing also needs its own check. Multiple Organisations do not inherently mean multiple licences. For eligible users, Microsoft’s multi-Organisation billing can charge once across Organisations linked to the same billing Azure subscription. Check billing arrangements and exclusions before claiming consolidation will save that money.
What the platform supports across Project and Organisation boundaries
Microsoft recommends a single Azure DevOps Project as the default. Multiple Projects need a specific business justification. Its Organisation guidance follows the same principle: start with one and introduce additional Organisations where security, compliance or independent governance requires separation.
“In general, we recommend that you create a single project [per business unit].”
“Each business unit within your company gets its own organization in Azure DevOps”
One shared process does not mean every team must work the same way. Teams can configure their own boards, adding columns that represent their workflow while mapping them to shared work item states. Different board layouts are not a reason to create separate Projects. Agree the common work-tracking structure and let teams configure how they manage their work within it.
I recommend one Project per business unit, within its own Organisation. This keeps the business unit’s connected work together while allowing its Azure DevOps costs to be billed to its own Azure subscription.
One business unit, one Organisation, one shared Project. Keep connected work together, give teams control of their boards, and require a specific justification for additional boundaries.
Within an Organisation, queries can span Projects, but queries for work items linked across Projects are not supported. The Azure DevOps capacity-planning feature does not support planning across Projects. Some dashboard widgets can show information from other Projects, while Analytics and Power BI offer cross-Project reporting. A cross-Project query cannot be opened in Excel through that integration; exporting to CSV is a separate option. These distinctions matter more than a blanket claim that reporting stops at a Project boundary.
Delivery Plans can show up to twenty Team backlogs across Projects. Their rollups require child items to be in the parent’s Project, and their dependency display does not support remote link types. Across Organisations, remote work item links do exist. They do not make the Organisations equivalent to a single planning and query scope.
The design decision is whether the native capabilities cover the coordination you need, and what it costs to maintain the remainder. A limitation that does not affect your work is a weak reason to migrate. A limitation encountered on every important handover deserves more weight.
I have described how to structure a shared Project elsewhere: use Area Paths to organise product work, Teams to configure focused views, and permissions that match responsibilities. That companion covers implementation. My preference for connected work in a shared Project goes back to areas over Team Projects in 2010 and one Team Project in 2012. Its usefulness still depends on the work and the current platform constraints.
The evidence from a current consolidation also prevents a simple numerical argument. An analysis of several thousand work item links compared whether the linked records would share a Project, share an Organisation, or sit in different Organisations after the move. Some linked records would move from different Projects in one Organisation to different Organisations. Others would move closer together, into a shared Project or Organisation. The two groups contained nearly the same number of links. These classifications matter to the native planning and query capabilities described above; they do not establish that a hyperlink stops working. The raw count was approximately balanced. The case for the chosen boundary rested on a judgement that frequent bug handovers and coordination between active teams mattered more than many older references. Crossing frequency had not been measured, and the inventory still needed further checks.
Frequency alone is insufficient. An infrequent dependency can have a severe consequence when it fails. Assess both how often people need a connection and what happens when that connection is difficult or unavailable. Consolidation can change Project boundaries, Organisation boundaries, or both. The proposed location needs evidence, including the work that will remain outside it.
The trade at each level of the business
The benefits and obligations fall on different people. The tables describe what a shared Project can enable when teams maintain the relevant records and leadership supplies the required governance.
Portfolio leadership
| Potential gain | Required work or remaining risk |
|---|---|
| Native relationships between portfolio Epics, Features and delivery work can make a connected backlog easier to inspect | Teams must maintain those relationships, and business units must agree a suitable work-tracking process |
| Fewer Project boundaries constrain dependency queries and rollups | Useful views still need filters, maintained data and an agreed question to answer |
| A shared view can expose disconnected work and competing demands | Leadership must decide what to stop or change; visibility supplies no decision authority |
| Project-level governance can be reviewed together | A structural or permission mistake can affect more products, and Organisation-level access obligations remain |
When a programme reports that a feature is complete, leaders need to inspect the contributing work and any unresolved dependencies. A consolidated backlog full of missing links and outdated records cannot show whether that completion claim holds.
How leaders use the view also matters. If the response to unexpected work is punishment for departing from a plan, people have reason to hide it. If evidence can change priorities and funding, the same visibility can support better decisions. A shared Project makes some information easier to assemble; it does not establish that learning will follow.
Management of programmes and products
| Potential gain | Required work or remaining risk |
|---|---|
| Teams can coordinate around the same work item instead of maintaining a copy solely to cross a Project boundary | Ownership and completion rules still need agreement, particularly where several products contribute to a fix |
| Some changes to product structure can use Area Path edits instead of moving work between Projects | Team views, access, integrations and organisational responsibilities still need assessment |
| Reporting can use a shared set of records | Definitions and data quality need maintenance; comparable-looking charts can describe different work |
| Team administration can be delegated within a common structure | Managers need usable permissions and a route for changes outside their authority |
Area Path nodes have stable identifiers, and Microsoft documents automatic updates to work item and query references when paths are renamed or moved. That removes some tooling work. It does not make a reorganisation a tree edit. Product ownership, funding, access obligations and working relationships remain decisions people must make.
The ability to change structure matters because today’s product and team arrangement will not necessarily remain useful. A common Project can reduce particular migration costs when that arrangement changes. The business case should identify those costs specifically, rather than promise that every future reorganisation becomes cheap.
Delivery teams
| Potential gain | Required work or remaining risk |
|---|---|
| A team’s board can show its work within a shared product structure | People coordinating across teams may still need several views; consolidation does not guarantee one board per person |
| A cross-product handover can retain one work item and its conversation within the Project | Teams must accept responsibility for the handover and agree when the customer’s problem is resolved |
| Fewer Project and Organisation boundaries can simplify sharing supported resources | Repository, pipeline and resource permissions still need design; common location does not grant access |
| Teams can maintain focused views and a suitable cadence | Query, tag and administration permissions must support that autonomy without uncontrolled shared configuration |
Personal queries and shared queries have different permission rules. Contributors can create personal queries, while contributing to shared query folders requires the relevant permission. Creating new tags is governed separately. Treating all three as “anyone can create anything” obscures the actual delegation decisions.
The shared-Project case is strongest where these changes remove recurring coordination work and where the necessary governance is available. My consulting experience favours it in those conditions. That is practitioner judgement, not a measured result showing a lower total cost for every organisation.
Budget for continuing governance
The platform supplies configuration and permission mechanisms. Your organisation supplies the ownership: who curates shared queries, manages naming and tags, reviews access, handles joiners and leavers, and decides structural changes. Those responsibilities continue after migration.
Configuration as code is a pattern I build with larger clients to support that work. Store the intended structure in version-controlled files, review proposed changes, and automate the supported configuration. The review gives people somewhere to negotiate a change before applying it. Repeated differences between declared and actual configuration should prompt investigation: the declaration may no longer fit the work, or the permissions may allow changes without the necessary review.
The Azure DevOps governance-as-code repository illustrates that approach. Its implementation covers selected configuration, so assess the operations and coverage of the revision you intend to run.
Automation can reduce repetitive administration. It cannot decide whether a proposed product boundary makes sense, approve an access exception, or provide the capacity to maintain the configuration. If the consolidation proposal has no named ownership and standing governance capacity, the expected benefit is not yet supported by an operating arrangement.
When separation is justified
Different board columns are already accommodated within a shared Project. A separate Project needs a work-tracking requirement that the shared process cannot reasonably support, or a justified need for independent administration or information access. Identity, geographic or compliance constraints can also justify separate Organisations. Some of those constraints persist. Treat an arrangement as temporary only when there is an actual reason and authority to end it.
Where coordination is limited, the cost of maintaining separate Projects may be small compared with the benefit of independent administration. Where coordination is substantial but isolation is required, design and fund the handovers that must cross the required access boundary. Consolidation cannot make a genuine isolation requirement disappear.
Where an organisation with multiple Projects already measures coordination costs, assigns owners and maintains reliable handovers, apparent containment is backed by evidence. Compare that evidence with the transition cost and continuing obligations of the proposed shared Project.
Evidence could change the preferred answer: comparable delivery results at equivalent governance investment, native capabilities that remove an important limitation, or a dependency inventory showing that the proposed Project or Organisation boundary separates more consequential work than it connects. My experience, including merging Team Projects and building migration tooling, informs the preference. It does not substitute for that comparison in your organisation.
Start with a handover you can inspect
Trace the last bug whose cause was in a different product from the customer report. Find the records people used, the views they consulted, what was copied or lost, and who verified the fix. Then check whether the proposed topology would remove the difficult step or merely move it elsewhere.
That is evidence a technical team can collect. Use it with a wider dependency inventory to compare the current and proposed risk registers. Include migration costs, required isolation, resource scale and the governance capacity each option needs. Take the resulting process, funding and authority decisions to the leaders who own them.
One shared Project deserves serious consideration where products depend on each other frequently. Its value is the possibility of clearer coordination and less tooling work when the organisation needs to adapt. Realising that value requires people who maintain the structure, inspect the evidence and have authority to act on what they learn.
To discuss the coordination and governance costs in your own organisation, book a conversation about Azure DevOps consolidation.
Subscribe to Martin's articles
Writing since 2006
Articles, usually weekly on Mondays. One click to leave.
References
- Cross-Project FAQs
- About Projects and scaling your Organisation
- Permissions and performance recommendations
- Move work items between Projects
- Multi-Organisation billing
- Review Team plans
- Set query permissions
- Change Project-level permissions
- Pipeline permissions
- Set Area Paths
- Plan your Azure DevOps Organisation structure
- Azure DevOps governance as code
Enjoyed this? One click, no account.
Questions this answers
Should I use one Azure DevOps project or many projects for a large organisation with multiple products and teams?
For a large organisation, using a single Azure DevOps project for many products and teams is not the inherently riskier choice; it exposes risks you can see and govern, whereas a fragmented many-project estate hides the same coordination risks out of sight. One project concentrates visible governance work (structure design, standardisation, delegated administration) but avoids the ongoing, unmanaged coordination costs and signal loss that occur when work, bugs, and teams are split across many projects. Both options carry risk, but only consolidation lets you write and own a meaningful risk register and align the tooling boundary with where your real coordination and traffic actually are.
What are the risks of using one large Azure DevOps project versus many smaller projects?
Using one large Azure DevOps project centralises risks such as estate‑wide impact from bad structural decisions, the need to negotiate a single process model and standards, a flat namespace for repos and pipelines, and the requirement for deliberate delegated administration and governance. In contrast, many smaller projects suffer from lossy cross-project work item movement, duplicated and lost bugs, engineers juggling multiple boards, mirror backlogs, shadow tooling, duplicated spend, and unowned coupling—risks that are already materialising but are diffuse, unmanaged, and typically have no explicit owner or register.
When are multiple Azure DevOps projects actually the right choice instead of a single consolidated project?
Multiple Azure DevOps projects are appropriate when there are hard boundaries such as separate business units with no shared money, people, work, or customers; genuinely different work-tracking processes; strict access-to-information requirements; or legal and regulatory walls that require people must not see across. In these cases, a separate project honestly reflects a real organisational boundary with no coordination risk to hide, though you should still aim for a single organisation where any coordination does exist and treat extra organisations as temporary debt forced by constraints like tenancy or data residency.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.