What is co-managed IT?

Co-managed IT is an arrangement where an organization keeps its internal IT team and moves a defined, written slice of the work to an outside partner. It is not a partial outsource negotiated case by case — the defining feature is a task-level division of labour with a named owner for each recurring responsibility, an agreed escalation path, and a written statement of what is excluded. If you cannot point at a recurring task and say whose it is without calling a meeting, the arrangement is not actually co-managed; it is two teams sharing a queue.

How is co-managed IT different from a fully outsourced MSP contract?

A full outsource replaces the internal function: the provider owns the help desk, the tooling, the vendor relationships and the day-to-day decisions, and the client keeps a budget holder. Co-managed keeps the internal team as the owner of the environment and the business relationships, and buys depth in specific areas — identity, Microsoft 365, security engineering, project delivery — that a small internal team cannot practically maintain. The practical difference shows up in who approves change: under a full outsource the provider proposes and executes, under co-managed the internal team retains change approval.

What does the internal team usually keep in a co-managed arrangement?

Everything that depends on knowing the business rather than knowing a product. In practice that means first-line and user-facing support, ownership of line-of-business applications and the vendor relationships behind them, change approval, budget authority, and the internal communications that surround any change. Those responsibilities are difficult to transfer well because they are carried by relationships and institutional memory, not documentation. A partner who offers to take change approval off your hands is offering to remove the control that makes the arrangement safe.

What work is usually best handed to a co-managed partner?

Work that requires deep, current product knowledge and is performed infrequently enough that an internal generalist cannot stay sharp on it. Identity and directory hardening, Microsoft 365 tenant configuration and migration, endpoint and patch baselines, backup restore verification, and security engineering are the common candidates. The test is frequency against depth: if a task demands a specialist but arises a few times a year, an internal team pays for the learning curve every single time, while a partner amortizes it across many environments.

Who holds after-hours escalation in a co-managed arrangement?

It depends entirely on what was written down, which is why after-hours is where most co-managed disappointment originates. There are three honest models: best-effort callback with no commitment, scheduled after-hours windows for planned work such as cutovers and maintenance, and an always-on rotation that is staffed and priced as a separate line. Always-on coverage should never be assumed to be included by default. The clause worth insisting on is not a number but a definition — what counts as an after-hours event, who is entitled to declare one, and which phone rings first.

Who should own the RMM, monitoring and documentation tooling?

Whoever owns the tooling largely determines how reversible the arrangement is. If the remote monitoring platform, the endpoint agents and the documentation live in the partner's tenant, an exit means rebuilding all three under time pressure. If they live in the client's tenant with the partner holding delegated access, the arrangement can be unwound without losing history. Either model can be run responsibly, but the choice should be deliberate and written down, and the client should always know where the documentation and the monitoring history will be if the relationship ends.

How do you avoid a co-managed arrangement where your senior staff end up supervising a junior bench?

Ask staffing questions during diligence rather than capability questions. Ask who will be on the recurring call in month six, by name and by seniority. Ask what happens to a ticket the first responder cannot resolve — specifically how many hands it passes through before it reaches someone empowered to make a design decision. Ask whether the engineer who scoped the work is the engineer who performs it. Vendors answer capability questions with brochures; they answer staffing questions with names or with vagueness, and the vagueness is the finding.

When is co-managed IT the wrong answer?

Four situations. When there is no internal team, because co-managed requires a counterparty and without one it is simply an outsource with extra steps. When the goal is to spend less on the same coverage, because the model buys depth and reach rather than a discount. When nobody internally owns the relationship with authority to make decisions, because an unowned arrangement decays into a ticket queue within two quarters. And when the real problem is a single unfinished project — a migration, a remediation, a modernization — in which case the right purchase is that project with a defined end, not an ongoing arrangement.

Field notes · 12 min read · August 19, 2026

Co-managed IT: what it actually covers

If you run IT for a 100- to 500-seat organization with one to five people on staff, you have almost certainly sat through the full-outsource pitch. It assumes the answer to "we are stretched" is "replace the team." For most organizations at that size it is the wrong answer, and you already know why: your people hold the institutional knowledge, the vendor relationships and the credibility that makes change possible. What you are short of is not headcount. It is depth in a handful of areas where a generalist team cannot stay current.

Co-managed IT is the other answer. The team stays; a specific, written slice of the work moves. The trouble is that "co-managed" has become one of the vaguest words in this market — it is used to describe everything from a shared ticket queue to a staffing contract to a full outsource with the client's IT manager left in place as a coordinator. This post is the plain-English version: what actually moves, what should never move, who holds which escalation, how after-hours and tooling ownership work, how the split changes at project time, and the situations where the model is simply the wrong purchase.

The one-sentence version: co-managed IT works when the division of labour is written down at the task level with a named owner, an escalation path and an exclusion list — and it fails, almost always, in one of two places: after-hours coverage nobody defined, or a senior internal engineer who ends up supervising the partner's junior bench.

What co-managed IT actually is

Strip away the marketing and a co-managed arrangement is three documents' worth of decisions. First, the split: which recurring responsibilities sit with the internal team and which sit with the partner. Second, the escalation model: who picks up what, in what order, and who runs an incident that crosses both. Third, tooling ownership: whose tenant the monitoring, endpoint and documentation platforms live in, and what leaves with whom if the relationship ends.

Everything else — the reporting cadence, the review meetings, the branded portal — is commentary. If those three things are ambiguous, the arrangement will drift toward whichever side is more conscientious, and that is usually the internal team, which is the opposite of the outcome you were buying.

The single most useful sentence to put in front of a prospective partner is this: show me the task-level split you would propose, including the exclusions. A partner who has done this work before will produce something concrete within a week. A partner who answers with a service tier chart is selling a package, not designing an arrangement.

The split that usually works

The organizing principle is simple and it holds up across most mid-market environments: the internal team keeps the work that requires knowing your business; the partner takes the work that requires knowing a product deeply. Frequency is the second test — a task that demands a specialist but arises three times a year is a task where an internal generalist pays the learning curve every single time.

Work	Usually sits with	Why
First-line and user-facing support	Internal	Your team knows the people, the applications and which requests are actually urgent. This is the hardest thing to transfer and the least valuable to transfer.
Line-of-business application ownership and vendor relationships	Internal	Carried by relationships and history, not documentation. A partner inherits the tickets but not the leverage.
Change approval and budget authority	Internal — always	This is the control that makes everything else safe. Moving it is how a co-managed arrangement quietly becomes an outsource.
Identity, directory and privileged-access design	Partner	Deep, current, high-consequence, and performed rarely. The Tier 0 boundary is the classic example of work that is worth doing properly once, with someone who does it constantly.
Microsoft 365 tenant configuration and migrations	Partner	Product surface changes faster than an internal generalist can track, and migration mistakes are expensive to reverse.
Endpoint baselines, patch rings and compliance posture	Shared, with a named owner per ring	Works well split — partner defines and maintains baselines, internal owns the exceptions, because exceptions are business decisions.
Backup verification and restore testing	Partner performs, internal owns the outcome	Verification is a discipline that decays without an outside cadence. Ownership of the recovery objective stays with the business.
Documentation	Shared, single source	Two documentation systems is the same as none. Decide whose it is on day one, not in month eight.
Software and licensing procurement	Internal or your reseller	We are labor-only and vendor-neutral — we do not resell, provision or manage licensing, so this stays where it already is.

Two of those rows carry more weight than the rest. The identity row is where most of the real risk in a mid-market estate lives, and it is the row that internal teams most often keep out of habit and least often have time to do properly — the mid-market version of that exercise is laid out in AD Tier-0 in 90 days, and it is the core of what identity, security and compliance work actually consists of. The change-approval row is the one to defend hardest, because it is the row that quietly moves.

Escalation: who holds which

A working co-managed arrangement has three escalation paths, not one, and they should be described in a paragraph a new hire can understand.

User-facing issues start and usually end internally. The partner should not be in this path at all, because inserting them adds a hop and removes context.
Platform issues — identity, tenant, endpoint management, backup — go straight to the partner, with the internal team informed rather than in the middle. If your engineer has to relay the symptoms, you are paying twice for the same diagnosis.
Business-impacting incidents engage both, with one named incident commander agreed in advance. Not a role, a person, with a named alternate.

The reason to name the commander before you need one is a specific, common failure. Consider a Monday morning where sign-ins start failing for one department. The internal team sees a wave of tickets and starts working the user path. The partner sees a monitoring alert and starts working the platform path. Both are competent. Nobody has declared an incident, so nobody is coordinating, and forty minutes disappear before anyone connects the tickets to a conditional-access change made on Friday. The technical work was never the problem; the absence of a declared owner was.

After-hours, honestly

This is where most co-managed disappointment originates, and it is almost always because the arrangement was sold with a warm sentence rather than a definition. There are three honest models, and the right one depends on what your business actually does at night:

Best-effort callback. Someone will probably answer. Nothing is promised. This is adequate for organizations whose after-hours risk is genuinely low, and it should be stated as plainly as that rather than dressed up.
Scheduled after-hours windows. Planned work — cutovers, maintenance, migrations — performed outside business hours by arrangement. This covers the majority of what mid-market organizations actually need after hours, because most of it is planned.
Always-on rotation. A staffed on-call roster. It is a real cost to the party providing it, so it is priced as its own line rather than folded into a base arrangement. Anyone including it for free either is not staffing it or is charging for it somewhere you cannot see.

Whichever model you pick, the clause that matters is the definition, not the promise: what counts as an after-hours event, who is entitled to declare one, and which phone rings first. Pro IT NW treats always-on coverage as an explicit add-on rather than an assumption, and the same is true of the exclusion list generally — the boundaries of ongoing support belong in the agreement, not in a conversation held during an incident.

Tooling ownership decides how reversible this is

Ask a prospective partner whose tenant the remote monitoring platform, the endpoint agents, the documentation system and the password vault live in. The answer tells you how hard it would be to leave, which is worth knowing on the way in rather than on the way out.

Both models are defensible. Tooling in the partner's tenant is cheaper and faster to stand up, and the partner carries the platform maintenance. Tooling in your tenant with the partner holding delegated access costs more to establish and means an exit does not take your monitoring history and documentation with it. What is not defensible is not having decided. The question to settle in writing is narrow: if this arrangement ends, what do we still have?

There is a security dimension to this that is easy to miss. Whoever owns the console, the remote management agent runs on your machines with standing privileged access — it is Tier 0 infrastructure in your estate, defended by controls someone else operates. That is not an argument against co-managed IT; it is an argument for asking a short list of specific questions, which we set out in your provider's RMM is Tier 0. A partner who answers those crisply is telling you something about how they run everything else.

Project time versus steady state

The steady-state split is not the project split, and treating them as the same thing is one of the more predictable ways a good arrangement sours.

During a project — a tenant migration, an identity remediation, a server modernization — the partner should take design and execution, and the internal team should take environment knowledge, user communications, change approval and acceptance testing. Those are different responsibilities from the steady-state ones, they consume real internal hours, and they need to be scheduled as work rather than absorbed. The failure mode is familiar to anyone who has lived it: the steady-state split is left in place, the project lands on top of it, and your own staff quietly do project work in the evenings while their day job accumulates. That is how a migration ships late and a team burns out at the same time. It is also why our delivery methodology puts wave sequencing and named client-side owners in the plan rather than in the kickoff call.

The reverse failure is quieter and more expensive. A project completes, nobody rewrites the steady-state split, and the partner carries on performing tasks that were project-scoped while the internal team assumes they were always included. Six months later somebody notices, and the conversation is unpleasant on both sides. The fix is a scheduled review at project close: what changed, what returns to whom, what is now permanently different.

The failure mode nobody sells against

Here is the one that matters most, because it is structural and because nobody puts it on a comparison chart.

Co-managed arrangements are sold on senior expertise and staffed, very often, with a junior bench. The escalation path then runs upward through your own senior engineer, because they are the only person in the conversation who can make a design decision quickly. You have paid for depth and received a queue, and your most expensive internal person now spends their week supervising it.

The symptoms are recognizable long before anyone names the cause. Your best engineer's calendar fills with clarifying questions. Tickets come back requesting information that was in the original ticket. Every non-routine change waits on the partner's one escalation engineer, who turns out to be a single person, who is on holiday. Work that should be routine arrives as a proposal for your review, which means you are doing the thinking and paying someone else to type.

Three questions surface it during diligence, and none of them are about capability:

Who is on the recurring call in month six — by name and seniority? Not the pre-sales engineer. The person who will actually be there.
What happens to a ticket the first responder cannot resolve? Count the hands it passes through before it reaches someone empowered to decide, not just to escalate.
Is the engineer who scoped the work the engineer who performs it? When the answer is no, ask what carries the context across the handoff, and be unsatisfied by "documentation."

Pro IT NW's answer to this is structural rather than aspirational: senior engineers, US-based, with no tier-one queue to escalate out of and no junior staff learning on your environment. That model has a cost — it does not scale to unlimited-everything support, and we are candid about that below — but it does mean the direction of escalation is the right way round.

Where co-managed is the wrong answer

Four situations where the honest recommendation is something else:

You have no internal team. Co-managed requires a counterparty. Without one it is an outsource with extra coordination overhead, and you should buy the outsource deliberately instead of arriving at it by accident.
You want the same coverage for less. The model buys depth and reach in areas a small team cannot cover. It is not a discount mechanism, and an arrangement entered into as a cost play tends to get cut in the first tight quarter — usually right before it would have paid off.
Nobody internally owns it. An arrangement with no named internal owner holding real authority decays into a ticket queue within two quarters. The owner does not need to be the most technical person; they need to be able to make decisions and be answered.
The real problem is one unfinished project. If the pain is a stalled migration, a remediation nobody has time for, or a modernization that keeps slipping, buy that project with a defined scope and an end date. Wrapping it in an ongoing arrangement makes it more expensive and less likely to finish.

We work with regulated mid-market organizations across Seattle and the wider Puget Sound region, and that fourth case is the most common thing we see mislabeled — a project problem sold as a support problem. It is also why our own boundary is drawn where it is: Pro IT NW does not sell ongoing support as a standalone engagement. Support is how we stay on after delivering something, because senior-led support only works when we already know the estate — which in practice means we built or remediated it first. If what you need today is a monthly support contract with no project attached, we are the wrong firm, and we would rather say so on the first call than discover it in month three.

How to write the split down

The document does not need to be long. One page, reviewed quarterly, containing five things:

A task-level responsibility list with a single named owner per row. Not a tier chart.
An exclusion list. The genuinely valuable half. Unsupported and end-of-life systems named specifically, project work called out as separately scoped, and anything else that could be assumed into scope during an incident.
The escalation model, including who declares an incident and who commands one.
The after-hours definition, in the terms above — what qualifies, who declares, which phone.
Tooling ownership and exit terms — whose tenant, and what you keep.

If a prospective partner resists writing any of these down, that is the answer to a question you did not have to ask.

The 30-second version

Co-managed IT keeps your team and moves a written slice of the work. The split that holds up gives the internal team everything that depends on knowing the business — user support, application ownership, change approval, budget — and gives the partner the deep, infrequent, high-consequence work: identity and privileged access, Microsoft 365 tenant and migration work, endpoint baselines, restore verification. Name an incident commander before you need one. Define after-hours rather than promising it. Decide whose tenant the tooling lives in and what you keep on exit. Rewrite the split at project close. And watch for the failure that never appears on a comparison chart: a junior bench escalating upward into your own senior engineer, which is the opposite of what you thought you bought.

If you want a senior engineer to map the split against your actual environment — including the exclusions — the project intake form takes about three minutes. Two-business-day response with scope and a fixed-fee range.

Questions we get asked

What is co-managed IT?: Co-managed IT is an arrangement where an organization keeps its internal IT team and moves a defined, written slice of the work to an outside partner. It is not a partial outsource negotiated case by case — the defining feature is a task-level division of labour with a named owner for each recurring responsibility, an agreed escalation path, and a written statement of what is excluded. If you cannot point at a recurring task and say whose it is without calling a meeting, the arrangement is not actually co-managed; it is two teams sharing a queue.
How is co-managed IT different from a fully outsourced MSP contract?: A full outsource replaces the internal function: the provider owns the help desk, the tooling, the vendor relationships and the day-to-day decisions, and the client keeps a budget holder. Co-managed keeps the internal team as the owner of the environment and the business relationships, and buys depth in specific areas — identity, Microsoft 365, security engineering, project delivery — that a small internal team cannot practically maintain. The practical difference shows up in who approves change: under a full outsource the provider proposes and executes, under co-managed the internal team retains change approval.
What does the internal team usually keep in a co-managed arrangement?: Everything that depends on knowing the business rather than knowing a product. In practice that means first-line and user-facing support, ownership of line-of-business applications and the vendor relationships behind them, change approval, budget authority, and the internal communications that surround any change. Those responsibilities are difficult to transfer well because they are carried by relationships and institutional memory, not documentation. A partner who offers to take change approval off your hands is offering to remove the control that makes the arrangement safe.
What work is usually best handed to a co-managed partner?: Work that requires deep, current product knowledge and is performed infrequently enough that an internal generalist cannot stay sharp on it. Identity and directory hardening, Microsoft 365 tenant configuration and migration, endpoint and patch baselines, backup restore verification, and security engineering are the common candidates. The test is frequency against depth: if a task demands a specialist but arises a few times a year, an internal team pays for the learning curve every single time, while a partner amortizes it across many environments.
Who holds after-hours escalation in a co-managed arrangement?: It depends entirely on what was written down, which is why after-hours is where most co-managed disappointment originates. There are three honest models: best-effort callback with no commitment, scheduled after-hours windows for planned work such as cutovers and maintenance, and an always-on rotation that is staffed and priced as a separate line. Always-on coverage should never be assumed to be included by default. The clause worth insisting on is not a number but a definition — what counts as an after-hours event, who is entitled to declare one, and which phone rings first.
Who should own the RMM, monitoring and documentation tooling?: Whoever owns the tooling largely determines how reversible the arrangement is. If the remote monitoring platform, the endpoint agents and the documentation live in the partner's tenant, an exit means rebuilding all three under time pressure. If they live in the client's tenant with the partner holding delegated access, the arrangement can be unwound without losing history. Either model can be run responsibly, but the choice should be deliberate and written down, and the client should always know where the documentation and the monitoring history will be if the relationship ends.
How do you avoid a co-managed arrangement where your senior staff end up supervising a junior bench?: Ask staffing questions during diligence rather than capability questions. Ask who will be on the recurring call in month six, by name and by seniority. Ask what happens to a ticket the first responder cannot resolve — specifically how many hands it passes through before it reaches someone empowered to make a design decision. Ask whether the engineer who scoped the work is the engineer who performs it. Vendors answer capability questions with brochures; they answer staffing questions with names or with vagueness, and the vagueness is the finding.
When is co-managed IT the wrong answer?: Four situations. When there is no internal team, because co-managed requires a counterparty and without one it is simply an outsource with extra steps. When the goal is to spend less on the same coverage, because the model buys depth and reach rather than a discount. When nobody internally owns the relationship with authority to make decisions, because an unowned arrangement decays into a ticket queue within two quarters. And when the real problem is a single unfinished project — a migration, a remediation, a modernization — in which case the right purchase is that project with a defined end, not an ongoing arrangement.

Related service

Co-managed IT support

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Share on LinkedIn Follow Pro IT NW