When internal IT needs deeper support, not replacement.

Co-managed IT is a model for organisations that already have internal IT capability, but need more depth around the team. The internal IT person or team usually knows the business well — users, priorities, legacy decisions, urgent sensitivities and the operating context behind the ticket queue — and that knowledge is valuable and should not be displaced without reason. The challenge is that many internal teams are now carrying more than day-to-day support: Microsoft 365, identity, cybersecurity, cloud platforms, backup, infrastructure, vendors and project delivery all compete for the same internal capacity. Co-managed IT is designed for that situation. It gives internal IT access to external technical depth and operating support while keeping internal ownership where it matters.

Start with what co-managed IT actually means
What this guide covers

What co-managed IT means; how it differs from fully managed IT; when the model fits and when it does not; how responsibilities should be divided; how internal IT concerns should be handled; common risks in co-managed arrangements; and when to explore a co-managed support model. This guide is for organisations with an internal IT person or team that is capable, but carrying too much alone.

Definition

What is co-managed IT?

Co-managed IT is an operating model where an external IT provider works alongside an internal IT person or team. Internal IT remains close to the business. The external provider adds technical depth, operational support and specialist capability where the internal team is stretched.

In practice, co-managed IT may support areas such as Microsoft 365, identity, endpoint management, cloud, infrastructure, backup, cybersecurity baseline, vendor escalation and project delivery. The model is not the same as simply outsourcing IT. It is also not casual overflow support. A proper co-managed arrangement defines who owns what, how escalation works, how documentation is maintained and how internal and external teams work together.

Co-managed IT works best when the internal team should remain central to the business, but should not be left carrying the full technical and operational load alone.
Model clarity

Co-managed IT versus fully managed IT.

The difference is ownership, not capability. Both co-managed and fully managed IT can provide strong technical support. The difference is how responsibility is divided.

Co-managed IT
External depth around an internal team
  • Works alongside an internal IT person or team
  • Internal IT typically keeps business-facing ownership: users, priorities, internal relationships, day-to-day context and local knowledge
  • The external provider adds depth around areas that require more specialist capability or more capacity than the internal team can carry alone
Usually fits where internal IT is capable, trusted and worth supporting
Fully managed IT
Broader external responsibility
  • Gives the external provider broader responsibility for operating the environment day to day
  • The provider takes a broader role across support, monitoring, patching, Microsoft 365, infrastructure, vendors, documentation and security baseline
  • One accountable operating model rather than shared ownership
Usually fits where internal IT capacity is limited, not in place, or not intended to own operational IT

The useful question is not which model sounds better. It is: does the organisation need external depth around internal IT, or broader external ownership of IT operations? That distinction should be made before the engagement is structured.

Fit

When co-managed IT fits.

Co-managed IT usually fits when internal IT is capable but carrying too much. The trigger is usually not internal IT failure. It is environmental growth. More users, more sites, more cloud services, stronger cybersecurity expectations, more Microsoft 365 dependency, ageing infrastructure and increased vendor complexity all increase the load on internal IT. At some point, the internal team may still be capable, but the environment has become too broad for them to cover properly.

Common fit signals:

  • Internal IT understands the business and should stay close to users.
  • Support is being handled, but complex escalation is difficult.
  • Microsoft 365, identity and endpoint management need more structure.
  • Cybersecurity expectations have increased.
  • Infrastructure, backup or network work requires deeper engineering input.
  • Projects are delayed because daily support consumes internal capacity.
  • Vendor escalation is taking too much internal time.
  • Documentation and operating standards need improvement.
  • The business wants more resilience without replacing the internal team.
The value of internal IT is not only technical. It is contextual. Internal IT often knows which users need extra care, which applications are fragile, which executives need fast support, which processes are business-critical and which historical decisions still shape the environment. Co-managed IT should preserve that knowledge while adding the technical depth and operating structure around it.
Qualification

When co-managed IT does not fit.

Co-managed IT is not the right model for every environment. A co-managed model only works if there is meaningful internal capability to build around. Where internal IT is not in place, has no capacity to remain involved, or cannot own any meaningful part of the operating model, fully managed IT is usually cleaner.

Co-managed IT may not fit when:

  • there is no internal IT person or team
  • leadership wants one provider to own the whole environment
  • the internal role is too junior to carry operational ownership
  • the internal person is already beyond sustainable workload
  • the business needs structured managed IT, not shared responsibility
  • the desired outcome is fewer internal decisions and less coordination
  • the organisation wants casual overflow support rather than an operating model
A poorly matched co-managed arrangement creates confusion. Internal IT assumes the provider owns something. The provider assumes internal IT owns it. Users do not know where to go. Projects stall. Security tasks fall between teams. The model needs to match the reality of what internal IT can genuinely own.
Scope

What co-managed IT can support.

There is no single fixed template for co-managed IT. The right scope depends on what the internal team already handles well and where external depth is required. A good co-managed model does not duplicate internal IT. It strengthens the areas where the internal team needs more capacity, specialist skill or operational coverage.

01
Specialist escalation

Internal IT may continue handling day-to-day user support, access requests and business-facing priorities. More complex issues can escalate to external engineers who understand the environment.

02
Microsoft 365, identity and endpoint management

Many internal teams are expected to manage Microsoft 365, Entra ID, MFA, Conditional Access, device management and licensing without dedicated platform depth.

03
Cloud and infrastructure

Internal IT often becomes stretched when the environment includes a mix of cloud platforms, on-premises infrastructure, ageing servers, backup systems, firewalls and network dependencies.

04
Cybersecurity baseline

Security has become part of everyday IT operations. A co-managed model can help make sure baseline controls are actively operated rather than assumed.

05
Backup and recovery oversight

Backup and recovery need visible ownership. Co-managed support can help clarify backup posture, recovery assumptions, monitoring and escalation.

06
Vendor escalation

Many IT issues cross vendor boundaries. A carrier blames the firewall. The application vendor blames Microsoft 365. The hardware supplier refers back to another provider. Internal IT is left coordinating the conversation.

07
Project delivery

Internal teams often struggle to deliver projects while also keeping day-to-day support moving. Co-managed support can add delivery capacity for migrations, upgrades, documentation, security uplift and infrastructure work.

The exact support model should be shaped around the internal team's strengths, not a fixed provider template.

The scope of the external layer should be agreed explicitly before the engagement begins — not discovered gradually through friction. What the MSP owns, what internal IT owns and where escalation happens should be written down and agreed.

What organisations gain

The value of co-managed IT is not simply more help. It is better leverage.

Internal IT stays focused on the business while the external partner covers the deeper operational load that would otherwise create fragility, bottlenecks or key-person dependency. When the model is designed well, the gains are practical and visible from early in the engagement — not theoretical benefits that arrive later. A well-structured co-managed arrangement should help internal IT spend less time drowning in escalations and more time doing higher-value work for the business.

Common outcomes after 6 to 12 months include:

  • faster access to senior technical escalation without expanding internal headcount
  • stronger cloud, security and infrastructure depth than the internal team could carry alone
  • more project capacity without sacrificing day-to-day support continuity
  • better-defined ownership across internal IT, external support and vendors
  • reduced key-person dependency in the internal team
  • improved monitoring, backup discipline and operational visibility
  • a more sustainable operating model as the business grows or adds sites
Operating model

How responsibilities should be structured.

Co-managed IT only works when ownership is explicit. The most important part of a co-managed arrangement is not the toolset or ticket queue. It is the division of responsibility.

The internal team and external provider need to know:

  • who owns each part of the environment
  • who handles escalation
  • how users request support
  • how changes are approved
  • how vendors are managed
  • how documentation is maintained
  • how security responsibilities are divided
  • how projects are scoped and handed over
Ambiguity is the most common source of friction. In co-managed IT, vague scope turns into vague billing.

The most important thing is not whether the commercial structure is simple. It is whether both sides can clearly understand what is included, what sits outside scope and how responsibilities connect to cost. The best commercial models are the ones that make operational boundaries obvious before the engagement begins. Typical structures include a fixed monthly retainer for defined operational scope; separate project pricing for migrations, upgrades, tenant restructures, branch rollouts and security uplift; and surge or after-hours support only where the environment requires it.

Responsibility model

A practical split of responsibilities.

Internal IT typically owns
Close to the business
  • User support — business context, first-line triage, internal priorities
  • Microsoft 365 — user administration, licence requests, access approvals
  • Endpoint management — local user context, device handover, onboarding and offboarding coordination
  • Infrastructure — site context, physical access, local coordination
  • Cybersecurity — internal policy communication, approvals, user awareness
  • Vendors — business relationship, contract decisions
  • Projects — requirements, stakeholder input, internal approvals
  • Roadmap — business priorities, budget context, internal communication
External provider typically owns
Depth behind the team
  • User support — complex escalation, technical resolution, support overflow where agreed
  • Microsoft 365 — tenant configuration, identity governance, security settings, escalation
  • Endpoint management — Intune, endpoint policy, patching, device standards, technical troubleshooting
  • Infrastructure — server, network, firewall, backup and lifecycle support
  • Cybersecurity — security configuration, monitoring, control uplift, escalation
  • Vendors — technical escalation, carrier and vendor coordination, issue ownership
  • Projects — technical design, implementation, documentation and handover
  • Roadmap — technical recommendations, sequencing, risk and lifecycle input
The split above is a starting point, not a fixed template. The final model should reflect the environment, internal capability and the level of external responsibility required.
Internal team perspective

Co-managed IT should strengthen internal IT, not sideline it.

The most common reason co-managed IT arrangements create friction is that the internal IT person feels threatened by the engagement rather than supported by it. This is a legitimate concern and it is worth addressing directly rather than hoping it resolves itself. Internal IT typically understands the business, the people and the operational priorities better than any external provider ever will. That knowledge is genuinely valuable and worth preserving.

The right co-managed provider knows this and structures the engagement to strengthen the internal team's position, not undermine it. A good co-managed provider does not go around internal IT, compete for influence, or use early findings to make the internal team look weak. The role of the external provider is to add capability where the internal team is stretched and make the internal team more effective. The internal IT person or team may reasonably ask whether a co-managed arrangement is the first step toward replacement. That concern should be addressed directly.

“Will the provider take over my role?”

The model should define what internal IT owns and what the provider owns before the engagement begins. Internal IT should retain the areas where it provides the most value: business context, user relationships, internal priorities and operational knowledge.

“Will the provider go around me to leadership?”

A co-managed arrangement should support internal IT's leadership conversations, not bypass them. The provider may contribute technical roadmap input, but internal IT should remain part of the conversation where they are responsible for the environment.

“Will the provider expose everything we have not fixed?”

Every environment has gaps. The purpose of reviewing them is to make the environment stronger, not assign blame. A mature provider distinguishes between inherited risk, capacity limitations, technical debt and actual negligence.

“What happens if the model works?”

If the model works properly, internal IT usually moves into a stronger position. They spend less time carrying every escalation alone and more time working on business priorities, improvement work, stakeholder management and higher-value technology decisions.

The clearest signal of a well-structured co-managed relationship is that the internal IT person feels their role has become more capable and better supported, not more precarious.

Risk and trade-offs

Common risks in co-managed IT.

Co-managed IT works well when structured properly. The risks are mostly design risks. The model itself is not fragile, but it does require discipline. Most failures come from unclear ownership, weak provider depth or poor relationship handling.

Blurred accountability

If responsibilities are unclear, issues fall between teams. The fix is documented ownership and clear escalation paths.

Provider behaves like a replacement

If the provider sidelines internal IT, the model becomes political. The internal team should remain informed, respected and close to the business.

Weak technical depth

Some providers position co-managed IT as collaboration but deliver only overflow helpdesk support. The model needs real capability behind it: Microsoft 365, cloud, infrastructure, cybersecurity, backup and project delivery.

Security assumptions

If patching, MFA, backup, endpoint controls or monitoring are assumed rather than explicitly owned, the environment becomes exposed.

Key-person dependency

A co-managed provider should reduce dependency, not create a new one. Knowledge should be documented and shared across the delivery team.

Static scope

The right co-managed scope today may not be right in 18 months. The model should adapt as internal roles, business priorities and technical complexity change.

Provider fit

What to look for in a co-managed provider.

Not every MSP is suited to co-managed work. Some providers are designed for full operational handover. They can struggle when they need to work beside an internal IT team. A good co-managed provider should be comfortable with shared ownership and clear boundaries. They should improve the internal team's position, not compete with it.

Look for:

  • experience working alongside internal IT
  • clear ownership and escalation models
  • senior capability behind the front line
  • depth across Microsoft 365, cloud, cybersecurity, infrastructure and backup
  • comfort with documentation and handover
  • practical project delivery capability
  • commercial clarity
  • ability to adapt as the environment changes
  • respect for the internal IT role

This does not replace a broader provider evaluation process — for that, see how to choose a managed IT provider. It clarifies whether the provider is suited to co-managed work specifically.

A useful test before signing: ask any co-managed provider directly — what happens if our internal IT person and your engineer disagree about the right approach? The answer tells you a great deal about how the relationship will actually work.
Inlight IT view

Co-managed IT is strongest when it protects internal knowledge while adding external depth.

The value of internal IT is often underestimated. A capable internal IT person or team carries business knowledge that cannot be replaced quickly: people, systems, history, sensitivities, priorities and operational workarounds. The risk is leaving that internal team to carry every technical layer alone.

Co-managed IT is most useful when it preserves internal ownership but adds structure around the areas that have become too broad or too specialised: Microsoft 365, cybersecurity, backup, cloud, infrastructure, networks, monitoring, vendors and project delivery. The model works best when it is not treated as a political compromise between outsourcing and hiring. It should be treated as an operating model with defined responsibilities, clear escalation and practical technical depth behind the internal team.

Co-managed IT should not make internal IT smaller. It should make the operating model stronger.

A useful test

If your internal team is capable but carrying every technical layer alone, the model is already under strain — a structured review shows where external depth would change the load.

Test the model with a review →
Common questions

FAQs about co-managed IT.

What is co-managed IT?
Co-managed IT is a model where an external IT provider works alongside an internal IT person or team. Internal IT remains close to users and business priorities. The external provider adds technical depth, monitoring, security capability, infrastructure support, vendor escalation and project delivery where the internal team needs more support.
Is co-managed IT the same as IT staff augmentation?
There is overlap. IT staff augmentation usually means adding external capability alongside an existing team. Co-managed IT is more structured. It defines ongoing responsibilities, escalation paths, documentation expectations and operational ownership between internal IT and the provider.
How is co-managed IT different from fully managed IT?
Co-managed IT works alongside internal IT. Fully managed IT gives the external provider broader responsibility for day-to-day IT operations. Co-managed is usually better where internal IT is capable and should stay central. Fully managed is usually better where internal IT capacity is limited, not in place or not intended to own operational IT.
Who is co-managed IT best suited to?
It is best suited to organisations with internal IT capability that needs more depth, scale or specialist support. Common triggers include Microsoft 365 complexity, cybersecurity expectations, infrastructure work, backup concerns, vendor escalation, project delays and internal capacity limits.
What does co-managed IT include?
It can include specialist escalation, Microsoft 365 administration, identity and endpoint management, cloud and infrastructure support, cybersecurity baseline, monitoring, backup oversight, vendor management, project delivery and roadmap input. The exact scope should depend on what internal IT already handles well and where external support is needed.
Does co-managed IT replace internal IT?
It should not. A well-structured co-managed model strengthens internal IT. Internal IT remains close to users, priorities and business context. The external provider adds technical depth and operating support behind the internal team.
What are the risks of co-managed IT?
The main risks are unclear ownership, provider overreach, weak technical depth, assumed security responsibilities, key-person dependency and scope that does not evolve. These risks are managed through clear documentation, agreed responsibilities and a provider that is genuinely suited to co-managed work.
Is co-managed IT cheaper than hiring more internal staff?
Sometimes, but cost should not be the only decision point. Co-managed IT can provide access to broader capability than a single hire: cloud, infrastructure, Microsoft 365, cybersecurity, backup, monitoring and project delivery. The value is flexibility and depth, not just cost reduction.
Can a co-managed model become fully managed later?
Yes. Some organisations move between models as internal roles change, the environment grows or leadership wants a different operating structure. A good provider should support that transition without disrupting users or weakening documentation.
How do we decide whether co-managed IT is the right model?
Start by clarifying what internal IT can genuinely own, where the environment is under strain, what security or infrastructure risks need attention, and whether leadership wants shared ownership or broader external responsibility. If internal IT is capable but stretched, co-managed IT may be the right model. If internal IT capacity is limited or not in place, fully managed IT may be cleaner. The next step is to understand how a co-managed arrangement would work in practice for your environment.
Practical next step

See how co-managed IT support can be structured around your internal team.

Define responsibilities, escalation and ownership around your internal team — external technical depth behind internal IT, not in place of it.

View Co-Managed IT