Skip to content
MQ-self-managed-daas-3

Self-Managed or Managed DaaS?

A Buyer's Guide to the Tradeoffs 

How to use this guide

This guide is for IT and infrastructure leaders weighing how to run a DaaS environment, either building the capability in-house or handing it to a managed provider. It lays out why these projects stall, what makes DaaS different from a standard platform purchase.

Read it straight through, or go to the path you are weighing: 

▶️Run it Yourself

▶️Hand it Off to a Vendor

▶️Take the Assessment

When it comes to de-risking a DaaS project, the digital workspace experts usually use three methods: review demos thoroughly, call vendor references, and test the pilot in a slice of their environment. This process gives buyers a snapshot of how the platform will run, but it fails to measure what breaks when it scales to meet the full volume of your workforce.

Standard vetting doesn't take into account an organization's legacy applications, their obscure compliance rules (especially if you're in financial services, healthcare, insurance, or utilities), and the bank of users who work outside of the established personas. And although the decision about which DaaS environment you go with is important, potentially more important is establishing who will own and run the environment after launch. Whether your team has that expertise or you go out of house, that decision will outweigh almost every other call you make in the project.

Are we a managed vendor that runs DaaS environments?

Yes. Is engaging with an organization like us right for every organization? No. That's why we created this guide.

The data says you are not alone

This is a common story, and the numbers show how common. Large IT projects tend to run late, run over budget, and deliver less than they promised. McKinsey and the University of Oxford measured how much, across more than 5,400 large IT projects, and found that on average they ran 45 percent over budget and 7 percent over schedule, while delivering 56 percent less value than predicted.

Zero in on the last two numbers, because the gap between them is the point. These projects came in only 7 percent over on schedule, which is close to on time. Yet they delivered 56 percent less value than they were supposed to. A project that lands nearly on schedule but far short on value did not fail at building and shipping. It failed at producing the outcome the business needed, and that failure happens in how the environment is run, not in the technology. So the question worth asking is what drives it.

daas-stat-value-gap

The same research locates the cause, and it is not the technology. Failing to manage strategy and stakeholders accounted for about half of all cost overruns. The people side of the work carries the same weight. Prosci's research across more than 2,600 change practitioners found that projects with excellent change management are up to seven times more likely to meet or exceed their objectives, and that 79 percent of projects with extremely effective sponsors met their goals, against 27 percent with extremely ineffective ones. Buy-in and readiness are not soft factors around the edges of the project. They are the largest predictors of whether it works.

DaaS is not like other platform purchases

DaaS is different because you are not installing an application, you are relocating the place your entire workforce does its work. A DaaS environment ties together identity, security, application delivery, and compliance controls at once. It has to hold all of them steady for every user on every shift. A missed detail in a standard software rollout is an inconvenience. A missed detail in a DaaS rollout is someone who cannot do their job.

There is also a difference of scale. A pilot proves the platform works for a controlled slice of users, and the environment rarely fails there. It fails when it scales to the full workforce and has to hold that scale every day, because volume surfaces the legacy applications, the edge-case users, and the capacity limits a small slice never touches.

Migration Consideration

Despite best efforts to choose the "right platform," migrations seem to be inevitable. Moving from one platform to the next carries the same readiness risk as the first rollout, and it lands on a schedule you do not control. Anyone working through a Citrix exit or the Broadcom licensing shift already knows the feeling. Teams that treat the first rollout as the finish line get caught flat when the next migration lands. Their knowledge, documentation, and operating plan were never built to survive a platform change.

Read About Citrix Migration Paths
DaaS-platforms

The bigger difference is that a DaaS estate does not stand still, because the platforms underneath it keep changing. In the environments we operate for regulated enterprises, the most disruptive events of the past two years were not internal decisions. They were changes in the ecosystem. Broadcom's acquisition of VMware reset licensing and packaging across a large installed base, and VMware's end-user computing business was divested and now operates as Omnissa under KKR ownership. Each shift forced organizations to re-evaluate a platform they had considered settled.

Those are the pitfalls that make DaaS its own category: the breadth of what it touches, the human dependency on getting it right, and the certainty that the ground will move under it. With that understood, the decision in front of you comes down to who carries that weight.

The two ends of the spectrum

Start at the two ends, where the tradeoffs are clearest. You can run the environment yourself, building and holding the operational capability in-house. Or you can hand the run to a managed provider and keep your team focused elsewhere. Most enterprises settle somewhere between these two, and the later sections cover that middle. But the two ends are the clearest place to see what you are trading. Each end has a version that works and a version that does not, and the difference is rarely the one people expect.

Whether you weighing self-managed (you have mature Day 2 capacity, stable staffing, and a strong need to hold control) or you are considering managed , here are a few paths to help you along your way: 

Self-Managed DaaS

You have mature Day 2 capacity, stable staffing, and a strong need to hold control.
 
What's the trade off?

Vendor-Managed DaaS

Your estate is complex or heavily regulated, a migration is on the horizon, or your team is already committed to other priorities. 
How to balance control?

You're Not Sure

You have conflicting opinions across your organization and need an external perspective. 
 
Take the Assessment

Self-Managed DaaS

Running it yourself: the good, the bad, and the ugly

Running DaaS in-house means your team owns the build, the daily operations, and every decision in between. You know your environment better than any provider will on day one. If you have the depth to run it, keeping it in-house is a real choice, and sometimes the better one. That depth pays off when it is current and strong. It leaves you exposed when it is not. The full ledger looks like this.

The good. Running DaaS in-house gives you full control and no external dependency. Decisions happen at your pace, and institutional knowledge builds up inside your team. For a team with mature operations and stable staffing, the cost is predictable too. When you own every layer, nothing sits behind a partner's ticket queue.

The bad. That control has a staffing cost that is easy to underestimate. Running DaaS in-house means holding deep, current expertise across shifts for every Day 2 function, continuously and not only at launch.

Self-Managed DaaS Tradeoffs

Run it in-house and your team carries all of this, every day:

You keep patching and the image lifecycle current.
You manage capacity and govern cost.
You own incident response and escalation.
You monitor user experience and catch drift before users feel it.

 

daas-stat-sponsor-access

The ugly. The migration you did not plan for does the most damage. When the platform underneath you changes, a team already running at capacity has to absorb a full re-platforming on top of its daily work. The cost of that shows up in one McKinsey figure: every extra year a project runs adds 15 percent to its cost overruns. At the far end, the same research found that 17 percent of large IT projects go so badly they threaten the company's survival. These are not launch failures. They are the slow, compounding cost of an environment no one had the capacity to keep current.

The managed path exists to move that weight off your team, and it has its own ledger.

Managed DaaS

Handing it off: the good, the bad, and the ugly

Handing the run to a managed provider means trading a measure of direct control for operational depth your team does not have to build or keep current. It is the right instinct for organizations that would rather aim their people at the business and let a specialist carry the environment. The trade runs in both directions, and the ledger below accounts for both sides.

The Good

A managed provider carries Day 2 operations, so your team does not have to build and keep that depth in-house. The expertise is on tap. Outcomes are steadier, because running these environments is the provider's whole job, not a side task. And the recurring migrations become the provider's problem to plan and run, not yours to absorb. For regulated enterprises with complex, multi-cloud estates, that handoff is the point.

The Bad

Handing off the run means depending on the provider, and the relationship only works when both sides stay closely aligned. A managed engagement also takes longer to scope than a platform purchase, because the provider defines the outcome before committing to it, not after. That longer evaluation is easy to read as friction. But the scoping is what makes the environment run the way the business needs. Skip it, and you create the value gap the data keeps showing.

The Ugly

The managed path fails when expectations were never set. A provider that extends its reach through partners can deliver consistently or unevenly, and the coverage map will not tell you which. The variability is almost always something scoping never resolved, so evaluate the operating model directly, not the footprint.

daas-two-path-comparison

Ask any provider before you sign:

  • Who runs Day 2 operations, by name and team, and on which shifts?
  • What is the escalation path when something breaks at three in the morning?
  • Who is accountable for the outcome when a partner sits in the delivery chain?
  • How is delivery consistency measured across regions, and can you see the data?

If a provider cannot answer these specifically, that is your answer. Consistency is a property of the operating model, not the geography.

Both ledgers are real, but they are the two ends of a range, not the only two options.

The middle ground is where most enterprises land

The two ledgers are poles, not the only two choices. Between running everything yourself and handing the whole environment to a provider sits a range of shared models, and in regulated enterprises that range is where most organizations operate.

  • Co-managed is the most common of them. You keep an internal team and split Day 2 by function or by the clock. Your people own the work they are closest to: the images, the user support, the business-hours desk. A provider carries the rest: the after-hours coverage, the patching, the capacity, the escalations. Both sides write the split down, and that is what separates a co-managed model that works from one that blurs.

  • Supported self-managed sits one step closer to in-house. You run the environment, and a provider gives you tooling, monitoring, and expert help on demand. When something breaks that no one on staff has seen, you are not facing it alone. You keep the operations, and you keep a number to call.

  • There is also a transitional version worth mentioning. A provider stabilizes a struggling environment, runs it through the hard part, and hands operations back once it is healthy. Stabilizing first and settling the long-term model later is a legitimate first choice rather than a fallback, especially when an environment is already in trouble.

The takeaway is that this is a spectrum, and you can sit anywhere on it. The three factors in the next section decide where.

The decision is cultural, technical, and procedural

The first line is cultural. It comes down to how much control your organization needs to hold, how well it handles change, and whether leadership will sponsor the work out loud, which the Prosci data shows is decisive. An organization that will not let go of control will struggle with a managed model, however good the technical fit. One that has no appetite to run complex operations will struggle just as much in-house.

The second line is technical. It is the complexity of your environment, the regulatory load it carries, and the migration burden ahead of you. A simple, stable estate is far more viable to run in-house than a multi-cloud environment under strict compliance obligations with a platform transition already on the horizon. The heavier the technical load, the more the offload of a managed model earns its cost.

The third line is procedural. It is the Day 2 capacity you have, the maturity of your operational processes, and the governance already in place. This is the line teams misjudge most often, because capacity on the org chart is not the same as capacity that is free. Reading these three lines clearly is the work, and it is easier to do with the environment in front of you than in the abstract.

daas-decision-triad-b

See where your environment lands

This tool takes your cultural, technical, and procedural inputs and returns the delivery model that fits, along with what to weigh before you commit. It is a starting point for the conversation, not a verdict, and it is built to surface the tradeoffs rather than to route you toward a single answer.

Two minutes, five questions

Which DaaS delivery model fits your environment?

Answer a few questions about your team, your environment, and what you need most right now. You'll get a starting point for the decision, along with what to weigh before you commit.

This is a starting point, not a substitute for a scoping conversation about your specific environment.

Question 1 of 5

Your environment

 

Your result

 

Taking you to your full breakdown now.

Not redirected? Open your result.

The value gap

The failure rates look grim, but the failure modes are well understood and, for the most part, avoidable. The value gap is not a limit of the technology. It is a readiness gap, and readiness is a choice you make before you sign rather than a repair you make after go-live. Whichever path you choose, the projects that plan for adoption and for Day 2 succeed at far higher rates than the ones that do not.

Run your choice through these four checks before you commit.

Cultural

Does your organization need to hold control, and will leadership sponsor the work visibly? If not, a managed model is the safer fit.

Technical

How complex and regulated is your estate, and is a migration ahead? The heavier the load, the more a managed model earns its cost.

Procedural

Do you have Day 2 capacity that is genuinely free, not just present on the org chart? If it is already committed, in-house will stall.

Readiness

Have you scoped the work, named who owns each function, and planned for the next platform change? If any answer is no, fix that first, on either path.

Answer those plainly and the right model is usually obvious. The outcome is far more in your hands than the industry averages suggest. If those checks point you in-house, keep it in-house. A managed relationship that does not fit is worse for both sides than no managed relationship at all, so the right move is sometimes to walk away from one, ours included.

What delivery model is right for your DaaS environment?

We built an engine to help you turn your real-world circumstances into a useful assessment of the best path forward for your DaaS environment based on your technical specs, cultural nuance, and people resources. You might find us in the results if the situation warrants it (we have been on the Gartner® Magic Quadrant™ for Desktop as a Service for four years in a row), but if we're not the right fit, we'll tell you.

Get Your Recommendation

Win the DaaS game with Anunta

If DaaS complexity has you down, let us help. Schedule time to talk to an engineer (we'll set up the call), or reach out to our solutions team to dig deeper into what's next. 

Get time with an EngineerLearn about our Solutions