The managed service vs project question is almost always argued on commercial ground. Fixed price against monthly retainer. Capital spend against operating spend. A defined scope you can hold someone to, against an arrangement that feels open-ended.
All of that is real, and none of it is the decision. Framing managed service vs project as a purchasing choice assumes the two are alternative ways to buy the same thing. They are not, and the reason is structural rather than commercial.
Two layers, and only one of them ends
Microsoft’s Cloud Adoption Framework splits cloud management into two layers of accountability: central, meaning platform responsibilities that apply across the whole estate, and workload, meaning responsibilities that attach to an individual application or service.
It then maps both layers across eight areas. The split is worth reading closely, because the pattern is the same in every row.
| Area | Central holds | Workload holds |
| Compliance | Defining operational procedures, enforcing governance policy, monitoring and remediating | Following the procedures, aligning design to policy |
| Security | Identity, access to subscriptions, security baselines, threat protection and incident response | Secure design, responding to workload alerts, assessing its own vulnerabilities |
| Resource management | The resource hierarchy, naming and tagging strategy, network topology, shared services, subscription limits | Its own resource groups, applying the standards, staying inside quota |
| Deployment | Standard pipelines and reference infrastructure-as-code templates | Using them, and adapting to workload needs |
| Monitoring | The monitoring strategy, central alerts, cross-estate dashboards | Its own observability and incident remediation |
| Cost | Budget allocation, estate-wide reporting, cost allocation to business units | Efficient design inside the budget |
| Reliability | Reliability requirements per workload priority, business continuity guidance, major incident management | Designing to meet those requirements |
Notice what the central column is made of. Strategies, baselines, hierarchies, standards, allocation models, incident management. Every one of those is a continuing responsibility. It does not complete. A naming standard is not delivered, it is enforced, forever, or it decays.
The workload column is different in kind. It has a beginning, a build, and a running state.
A project delivers workload responsibilities. That is what a project is: a scope, a deliverable, an end date and a handover. It can build a landing zone, but it cannot hold a governance policy, because holding a policy is not a deliverable. This is the whole argument, and it is why the commercial framing produces bad answers. The two options are not the same work bought differently. They address different rows of that table.
The question underneath is which operating model you are running
Once the two layers are separated, the real decision surfaces, and Microsoft names it directly. There are three cloud operating models, plus a hybrid.
| Model | Best for | How it works | The failure mode |
| Centralised | Startups, single-cloud estates, highly regulated industries | One team owns governance, security and operations across everything | Becomes a bottleneck as adoption scales |
| Shared management | Mid-size and enterprise estates, hybrid or multicloud | Platform teams build landing zones, run shared services and set guardrails. Workload teams work autonomously inside them | Requires clear responsibilities and strong coordination, or it degrades into neither model |
| Decentralised | Highly skilled teams, innovation programmes | Each team owns its own landing zone and every cloud task | Weaker standardisation and a higher risk of security gaps |
A hybrid is legitimate and common: core systems under a centralised or shared model, innovation teams operating more independently. Microsoft’s guidance is to evaluate team capability and business priority to decide where that adds value without weakening governance.
Now the question is answerable. A managed service is a way of resourcing the central layer. A project is a way of resourcing a workload. If your operating model says a platform team holds the guardrails and you do not have a platform team, that is a managed service conversation. If your operating model is decentralised and each team genuinely owns its own estate, a managed service across the middle would fight the model you chose.
If the boundaries themselves are unclear, that is a prior problem. Where subscription and management group boundaries should sit is the design decision that makes the central layer possible to hold at all.
What a project structurally cannot deliver
Not because project teams are worse. Because these things have no completion criteria.
- Change management. The framework is blunt that change is the major cause of failure in the cloud, and asks for a standardised process to manage it. A process is not a deliverable, it is a habit.
- Runbooks that stay current. The guidance is to build a library, store it centrally for on-call engineers, and review and revise it periodically to reflect operational adjustments and service updates. The library is deliverable. The revision is not.
- Continuous support. 24/7 coverage, either through follow-the-sun global teams or structured on-call rotations, with automated alerting routed to named people.
- Weekly operational reviews. Key metrics, recent incidents, changes deployed, risks anticipated. Weekly, indefinitely.
- Actively addressing resource sprawl and technical debt. Both accumulate as a function of time, which means neither can be fixed by an engagement that ends.
- Named primary and backup owners for every responsibility, so continuity survives absence and transition.
Read that list against a statement of work and the gap is obvious. Every item is a verb in the present continuous.
What we see when the central layer has no owner
Across our engagements the most common shape is not a failed project. It is a successful one.
The build lands, the workload works, the team demobilises, and the central responsibilities were never assigned to anybody because they were not in anyone’s scope. Nothing breaks that week.
Drift becomes measurable between months six and nine, which is the second full operational quarter after handover. Not eighteen months, which is the figure people expect, and the gap between those two numbers is the reason nobody catches it.
The first ninety days hide it. Hypercare is still running and the project team remains unofficially reachable, so problems get solved by someone who happens to still know the answer rather than by a process. That masks structural decay rather than preventing it. Three things then arrive at roughly the same time and remove the cover: the first significant process change or reorganisation that was never in the project specification, the departure or role change of the original sponsor or lead internal maker, and the first quarterly billing review where consumption anomalies can no longer be written off as implementation and testing.
The order it actually happens in
There is a sequence people expect, and it is wrong. The intuitive order starts with naming and tagging, because those are the visible standards. In production the decay runs almost exactly the other way.
| Order | What slips | When |
| 1 | Access and permission exceptions | Within weeks |
| 2 | Template and pipeline forking | Soon after |
| 3 | Naming and tagging discipline | As the forks multiply |
| 4 | Runbooks stop matching reality | Quietly, throughout |
| 5 | Cost allocation blind spots | When finance asks |
It starts with an urgent production issue or an expedited joiner, and a permission granted manually outside the project’s security groups or lifecycle pipelines. Direct user access to a production environment, or a service principal created by hand.
Then the standard deployment pipeline starts to feel slow for a fast-turnaround fix, so someone clones a template, changes an environment variable locally, and ships outside the central solution path. Ad-hoc resources and clone environments multiply to support those forks, and tagging is the first thing dropped to hit a deadline. The runbooks fall behind because none of the workarounds were fed back. Finally finance flags a spike in unallocated capacity, and nobody can attribute it, because the tags and names that would have made attribution possible broke two stages earlier.
That last step is why cost is usually where drift is first discussed, and it is the worst possible place to discover it. By then the evidence needed to diagnose it has already gone.
The leading indicator is the first manual permission bypass granted to hit an operational deadline. It happens within weeks of handover, it is visible in audit logs, and almost nobody is watching for it. Everything downstream follows from it.
The tell during procurement is a different question, and it is worth asking before the contract rather than after. Who enforces the naming standard on a resource created next March? If the answer is a team, you have a central layer. If the answer is a document, you do not.
The clause most contracts are missing
The framework contains a piece of partner guidance that reads like boilerplate and is not.
It says to clearly outline the scope of responsibilities for strategic partners, to specify which functions the partner owns such as platform operations, workload management or innovation initiatives, and to ensure these roles complement internal team responsibilities without overlap.
In our experience that last clause is where managed service arrangements actually fail, and the failure runs in both directions. Overlap produces two teams believing the other is watching an alert. Underlap produces a gap nobody notices until it is an incident. Neither is a service quality problem and neither is fixed by a better SLA, because the SLA describes response time to work that has been correctly routed to the right team in the first place.
The remedy is unglamorous. Take the eight areas, split each into central and workload, and write a name against every cell. Not a team. A name, plus a backup, which the framework asks for explicitly so that continuity survives absences and transitions.
Our position: decide the operating model before the commercial model
We would not take on a managed service for an organisation that has not decided its operating model, and we would say so rather than take the work.
A provider cannot operate in a vacuum. Where an organisation has not settled whether it runs a centralised, a shared or a hybrid model, the managed service becomes the place unresolved internal politics, contradictory change requests and unowned business logic are sent to live. Taking that retainer does not avoid the problem. It guarantees a failed service review around month six, and the provider will be the one holding it.
The stronger version costs less and is easier to defend internally: agree which operating model you are running, name who holds the central layer, and let the service description follow from that. If the model is shared management and the partner is the platform team, the scope is written already.
And the honest corollary, which is not in our commercial interest to state: a managed service is not a better project, and a project is not a cheap managed service.
Where an enterprise already has a mature platform engineering function handling governance, automated guardrails, environment lifecycle management and core telemetry, a broad horizontal managed service is redundant and wasteful. It duplicates a capability that already works. In those estates the useful commercial role is narrow: specialist escalation such as a deep-dive tenant migration or capacity architecture, or discrete project spikes. Not an ongoing operational retainer.
We have advised against a retainer on exactly those grounds and would again. Saying so in public costs us a certain kind of revenue and earns a better kind, because a provider willing to name the work it should not be doing is easier to trust on the work it should.
Where this connects
Two related questions come up in the same conversation.
The structural one is enterprise architecture, because an operating model is only implementable if the estate has boundaries that match it. The same logic reaches individual platform decisions: choosing between Container Apps and AKS should follow from who will operate the platform after handover.
The measurement one is harder and it applies to both delivery models. If you cannot show what the arrangement returned, the renewal conversation becomes a price negotiation. The baseline problem that makes value impossible to prove afterwards applies to a managed service exactly as it applies to an application, and for the same reason: the before state stops existing once the service starts.
Where to start
Before the commercial question, answer three:
- Which operating model are we running? Centralised, shared management, decentralised, or a deliberate hybrid.
- Who holds the central layer? Name people, primary and backup, against each of the eight areas.
- Where does a partner sit in that map, and what do they explicitly not own? The second half of that question is the one that prevents both overlap and gaps.
If you can answer all three, the managed service vs project question answers itself, and the commercial structure becomes what it should always have been, which is an implementation detail.
Veratas provides managed services for Microsoft platform estates, and we run the operating model work that decides what the service should cover.
If you have a well-delivered platform that nobody currently owns, talk to our team. That is a shorter conversation than it sounds.
Frequently asked questions
What is the real difference between a managed service and a project? A project delivers workload responsibilities, which have a scope and an end date. A managed service resources central platform responsibilities, which do not end by construction. Microsoft’s Cloud Adoption Framework splits cloud management into exactly these two layers across eight areas, and the central column is made of strategies, baselines and standards that are enforced continuously rather than delivered once.
Which cloud operating model should we choose? Centralised suits startups, single-cloud estates and highly regulated industries, but becomes a bottleneck as scale grows. Shared management suits mid-size and enterprise estates, particularly hybrid or multicloud, with platform teams setting guardrails and workload teams working autonomously inside them. Decentralised suits highly skilled teams and innovation programmes at the cost of weaker standardisation. Hybrids are legitimate and common.
What can a project genuinely not deliver? Anything without a completion criterion. Change management as an ongoing process, runbooks that stay current, 24/7 support coverage, weekly operational reviews, and the continuous work of addressing resource sprawl and technical debt. All of these are present-continuous activities, not deliverables.
How do we define what a partner owns in a managed service? Microsoft’s guidance is to specify which functions the partner owns, such as platform operations, workload management or innovation initiatives, and to ensure those roles complement internal responsibilities without overlap. Practically, take the eight management areas, split each into central and workload, and write a named owner and a backup against every cell.
Do we need a managed service if we already have a platform team? Possibly not. If the central layer has real owners and functioning guardrails, a managed service on top buys duplication rather than coverage. In that situation project delivery for workloads may be the only thing you need, and we have advised clients accordingly.
What is the warning sign that the central layer has no owner? Operationally, the first manual permission granted outside the project’s security groups or lifecycle pipelines to hit a deadline. It happens within weeks of handover, it is visible in audit logs, and everything else follows from it. Commercially, ask during procurement who will enforce the naming standard on a resource created six months from now. If the answer names a team, the layer is held. If the answer is a document, it is not.
How quickly does governance drift actually appear? In our engagements it becomes measurable between months six and nine, the second full operational quarter after handover, rather than the eighteen months people tend to assume. The first ninety days are masked by hypercare, when the project team is still unofficially reachable. The cover is removed by an unplanned process change or reorganisation, the departure of the original sponsor or lead maker, and the first quarterly billing review where consumption can no longer be attributed to implementation and testing.
Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.