Data center hallway with rows of server racks connected by glowing blue digital network lines.

Co-Managed IT vs. Managed Services: What You’re Actually Buying

Key Takeaways

Most companies searching for co-managed IT are actually buying staff augmentation or a precisely scoped managed IT support service. The difference comes down to who owns the SLA.
Company size predicts the model: enterprises buy people, the middle market buys narrow specialized managed services, and small teams with spiky demand are where true co-managed IT fits.
The real trigger is a gap in coverage or capability.
These engagements fail on the handoff, almost never on the technology: no transition plan, an undefined escalation path, or the wrong skills on the account.

Introduction

If you searched “co-managed IT,” you probably found a dozen articles telling you it’s the tidy middle ground between running IT yourself and outsourcing it entirely. You have a team, a provider supplements them, everyone shares the load.

That definition is accurate. It just doesn’t describe what most companies actually end up buying.

Co-managed IT describes a relationship we rarely encounter in practice. Companies may call it co-managed. But at the end of the day, one party owns accountability, and it’s almost always the client.

That gap between the search term and the reality is worth closing, because picking the wrong model is expensive.

What does co-managed IT actually mean?

There are three distinct arrangements hiding under the co-managed umbrella, and the difference between them comes down to one question: who owns the SLA?

Staff augmentation. External people, internal management. You place skilled resources inside the client’s org chart, and they follow the client’s direction day to day. The provider owns none of the service-level accountability. As Derive Technologies EVP Mitch Martinez puts it, staff augmentation is “the furthest away from outsourced managed services as you can get.”

Managed services. The provider owns a defined scope and is accountable to measurable SLAs: uptime, resolution time, resiliency. Critically, that scope can be narrow. A managed service doesn’t have to mean all of IT.

Co-managed IT. A shared-accountability model where the internal team and the provider each own defined pieces of the same environment, with overlapping escalation.

ModelWho manages day to dayWho owns the SLA
Staff augmentationThe clientNo one on the provider side
Managed servicesThe provider, within a defined scopeThe provider
Co-managed ITBoth, for defined piecesShared, with overlapping escalation

Most organizations think they want the third one. Most of them are actually shopping for the first or the second.

Which model fits your company size?

There’s no fixed rule, but there’s a very reliable pattern.

Enterprise (10,000+). Large banks, global tech firms, major financial institutions. These companies almost never outsource management of critical systems. Their leadership doesn’t want a third party accountable for uptime and data integrity, because the board holds them accountable. They’ll rent cloud capacity and colocation space all day long, but they buy people, not accountability. That’s a staffing model.

Middle market (roughly 1,000 to 10,000). This is where specialized managed services thrive. These organizations rarely outsource all of IT, but they’ll hand over a well-defined domain (data center operations, tactical work like installs, moves and changes) and hold the provider to deliverables.

Smaller teams with spiky demand. This is where true co-managed makes the most sense, and it’s usually driven by two conditions at once: a staff too small to cover every skill, and demand that isn’t flat across the year.

That second condition matters more than people expect. Consider a public-sector organization whose IT load spikes hard around primary and general elections and stays quiet the rest of the year. They can’t fully outsource, because the sensitivity of the work demands internal oversight. But they also can’t justify staffing for their peak, leaving people idle ten months a year and still short-handed during the other two. Co-managed is the best-fit model in this instance.

IT engineer working on a laptop in a data center aisle

Why does scope matter more than the label?

One of our healthcare clients is a large public hospital system. We support the medical carts used across their acute-care facilities, under a defined SLA. We own that accountability completely.

Is that “co-managed”? Not really. It’s a managed service with a deliberately narrow cross-section, chosen because the client has no workshop, no specialized tooling, and no realistic path to doing that work in-house. Almost no organization can.

Another client, a senior care provider, has strong end-user, cloud, and data center capability but almost no networking skill in-house. They never hired for it, because we own that cross-section for them. They keep their applications internally and go straight to the software manufacturers for support.

Neither one is buying “co-managed IT.” Both are buying a precisely scoped managed service that closes a specific capability gap.

What actually triggers the decision?

When executives evaluate this decision, they’re rarely thinking about team burnout. Burnout is real, and it’s a consequence, but it doesn’t drive the conversation.

What drives it is coverage and capability. The question sounds like this: I need 24×7 coverage. I have six people who work from nine to five. How do I get there?

Or: We need a skill set we’ve never hired for, and hiring for it now means one person with no backup.

What’s the real business case?

Here’s the arithmetic that closes these deals.

Two internal hires at $50,000 each. Add benefits, FICA, and overhead and the real cost is closer to $70,000 apiece. Call it $140,000, plus desk space, so roughly $150,000 all in.

A provider comes in and says: we’ll deliver that same function for $100,000.

The cost comparison is the easy part. The part clients underestimate is what else comes with it. Those provider resources are 100% focused on their specialty, sharpened across multiple environments. And you get a bench. When your one internal specialist is out sick, there’s no backup unless you already built one. When a provider’s engineer is out, someone equally qualified picks it up.

Where do co-managed engagements go wrong?

Almost never for technical reasons. Three failure modes account for most of it:

  • No transition plan. If you don’t build one up front, the early stages will be a disaster. The plan must document who owns which responsibility from ticket open to ticket close.
  • Undefined escalation. This is how work falls into the gap between two teams. It should be explicit: first call is owned by the provider; if it can’t be resolved in a defined window, it escalates simultaneously to the internal stakeholder accountable for the relationship and to management at the provider. Platforms like ServiceNow automate this. A ticket ages past five or seven days, and the workflow notifies both parties without anyone remembering to.
  • The wrong skills on the account. We’ve heard the same story from clients repeatedly: the provider staffed a project needing a level-three engineer with two people barely out of school, and the work didn’t get done. Related, and just as common, is a provider without the capacity to absorb the work. If you don’t have bench depth, you cannot meet an SLA.

The Takeaway for IT Buyers

Frequently Asked Questions

What is co-managed IT?

A shared-accountability model where an internal IT team and a provider each own defined pieces of the same environment, with overlapping escalation. In practice it is rarer than the search volume suggests.

What is the difference between co-managed IT services and managed services?

Under managed services, the provider owns a defined scope and is accountable to measurable SLAs. Under co-managed IT, accountability is shared between the internal team and the provider for defined pieces of the same environment.

Is staff augmentation the same as co-managed IT?

No. With staff augmentation, external people work under the client’s management and the provider owns none of the SLA accountability. It is the furthest model from outsourced managed services.

Why do co-managed IT engagements fail?

Almost never for technical reasons. The common causes are no transition plan, an undefined escalation path, and a provider without the right skills or the bench depth to meet its SLAs.

The Takeaway for IT Buyers

There is no universally right answer here. Size, industry, IT intensity, and existing skill gaps all move the line, and the line isn’t fixed.

What is fixed is the discipline: define the terminology, define who owns what, define the SLAs you’ll be measured against, and build the transition plan before anyone touches a ticket. Get those right and the label on the contract barely matters.

Not sure whether you need co-managed IT, a scoped managed service, or additional staff? Let’s map your environment against your actual capability gaps. Talk to Derive.