Co-Managed IT vs Fully Managed IT: Which Model Fits Your Business?
Co-managed IT vs fully managed IT, compared plainly: who does what, when each model fits, how the cost models differ, and what to ask before you sign.
Short answer
Co-managed IT keeps your internal IT staff in place and adds an outside provider to fill specific gaps — extended coverage, security depth, tooling, project capacity. Fully managed IT hands the whole function to the provider, who becomes your IT department. The deciding question is not budget. It is whether you have internal IT capability worth building around.
Definitions: what each model actually is
Fully managed IT. The provider owns the function end to end: helpdesk, monitoring, patching, backup, security operations, vendor coordination and strategic planning. One place to call, one organisation accountable. Usually priced per user or per device, per month.
Co-managed IT. You keep internal IT — a solo admin, an IT manager, or a small team — and the provider works alongside them under an agreed division of labour. Your people keep what depends on institutional knowledge: line-of-business applications, internal relationships, day-to-day user requests. The provider takes what needs scale, depth or continuous staffing: round-the-clock monitoring, security tooling and alert triage, patch pipelines, escalation engineering, migrations, and coverage while your person is away.
One more term, because it gets confused with co-managed: staff augmentation adds hands that work under your management, processes and ticketing. Co-managed IT is a shared-responsibility arrangement where the provider owns defined areas outright. Providers use both terms loosely, so ask which is in the proposal.
Side-by-side comparison
| Co-managed IT | Fully managed IT | |
|---|---|---|
| Internal IT staff | Required — the model assumes someone internal | Not required; often none |
| Who holds institutional knowledge | Your team retains it | Transfers to the provider; depends on their documentation discipline |
| Accountability | Shared, so it has to be written down | Single point — one organisation owns the outcome |
| Typical provider scope | Named gaps: monitoring, security, tooling, escalation, projects, coverage | Everything operational, plus strategy |
| Best fit | A capable but stretched internal team | No internal IT, or internal IT retiring or leaving |
| Cost shape | Internal salary plus a narrower provider scope | One provider fee replacing most internal cost |
| Main risk | Ambiguous ownership — issues land between the two teams | Over-dependence on one vendor; weaker internal knowledge over time |
| Management overhead on you | Higher — someone has to run the relationship | Lower — that’s part of what you’re buying |
When co-managed IT is the right call
- Your internal IT person or team is good but underwater. The problem is capacity and depth, not competence.
- You need coverage your headcount cannot provide — nights, weekends, holidays, the two weeks your only admin is away.
- You need specialist depth occasionally: security operations, cloud migration, compliance evidence, network redesign. Hiring for that full-time is not justifiable.
- You want enterprise-grade tooling (monitoring, EDR, patch management, backup verification) without running the platforms yourself.
- You are in a regulated environment and want internal staff to keep control of sensitive systems while offloading monitoring and documentation.
- Your internal IT is strategic by design — a director who should be planning, not resetting passwords.
When fully managed IT is the right call
- You have no internal IT, or IT is somebody’s unofficial second job.
- Your sole IT person is leaving or retiring, and their knowledge is about to walk out with them.
- You want one accountable party. In a small organisation, managing a split can cost more than the split saves.
- You need breadth immediately — security, cloud, networking, compliance, helpdesk — and cannot assemble it internally on any realistic timeline.
- Your IT spend is unpredictable and you want it to be a fixed monthly line.
Neither model is the mature choice. Businesses move between them in both directions, and the right answer changes when headcount, compliance exposure or internal staffing changes. The adjacent decision — outsource or hire — is covered in outsourced IT vs in-house IT.
How the two cost models differ
The structure matters more than the number.
- Fully managed is one recurring per-user or per-device fee replacing most internal IT cost. Predictable, and easy to compare between providers.
- Co-managed is a narrower provider fee on top of internal salary and benefits. It is often called the cheaper option, and the invoice usually is smaller — but the total cost of the function includes the people you keep. Compare the function, not the invoices.
- What moves either price: users and devices; how much security sits in the base plan versus bolted on; whether continuous coverage is included or triggered; compliance scope; onboarding; and whether project work, licensing and out-of-hours response are in scope or billed separately.
- What to insist on in a co-managed quote: exactly which responsibilities the fee covers. A co-managed quote priced as a full managed plan minus a discount is a fully managed plan with a discount — not a defined split.
There are no market price bands on this page by design. A number without a scope attached is not information.
Who does what: a responsibility split you can start from
Illustrative only — a worked example of the kind of split a co-managed agreement should spell out, not any specific provider’s scope. Bring your own version to the first conversation and make each candidate mark it up.
| Responsibility | Internal IT | Provider |
|---|---|---|
| Day-to-day user support (tier 1) | Owns | Overflow and out-of-hours |
| Line-of-business application support | Owns | Consulted |
| Continuous infrastructure monitoring and alert triage | Informed | Owns |
| Patch management and maintenance windows | Approves | Owns execution |
| Endpoint security tooling and alert response | Informed | Owns |
| Security incident response | Co-owns (decisions) | Co-owns (execution) |
| Backup configuration and restore testing | Consulted | Owns |
| Identity, access, joiners and leavers | Owns | Tooling and audit support |
| Vendor and ISP coordination | Owns relationships | Escalation support |
| Project delivery (migrations, refreshes) | Approves scope | Owns delivery |
| Documentation of the environment | Co-owns | Co-owns — both must be able to produce it |
| Technology roadmap and budget | Owns | Advises |
Two rows matter more than the rest. Restore testing — “we have backups” and “we have tested a restore” are different statements, and in a split model it is the easiest thing for each side to assume the other is doing. And documentation, because the value of keeping internal staff is institutional knowledge; if nobody writes it down, you are paying for a benefit you are not getting.
The failure mode this prevents. Co-managed arrangements fail in one specific way: an incident lands in a gap, both teams reasonably believe the other owns it, and the clock runs. It is rarely bad faith — almost always an unwritten assumption. The matrix, one escalation path with named humans, a shared ticketing view and a standing joint review are what stop it. If a provider cannot produce a matrix from a previous co-managed client — redacted is fine — they have probably not run one.
Moving from in-house-only to either model
A transition is a known quantity. It should be boring.
- Discovery and documentation. Inventory systems, licences, vendors, admin credentials, backup state, and where the undocumented knowledge lives. Skip this and everything after it is a guess.
- Decide the split before signing. For co-managed this is the contract.
- Tooling and access handover. Monitoring, endpoint, patch and backup platforms deployed; admin access granted deliberately and logged.
- A defined onboarding window. Ask every candidate for their 30/60/90-day sequence.
- Protect your internal person’s standing. The fastest way to break a co-managed arrangement is to let your admin believe the provider is there to replace them.
Going the other way — fully managed to co-managed, usually after hiring an IT manager — needs the same matrix exercise and a renegotiated scope.
Questions to ask any provider before you sign
- Which model are you proposing — co-managed, fully managed, or staff augmentation? One sentence.
- Show me your responsibility matrix. Which rows do you own on day one?
- What are your response targets, and do they differ for critical and non-critical issues?
- Who covers nights, weekends and holidays, and what triggers a response outside normal hours?
- Which security controls are in the base fee, and which are add-ons?
- What is explicitly out of scope and billed separately?
- How do you work with an existing internal IT person — a concrete example, not a philosophy?
- Who tests restores, how often, and will you show me the last result?
- What tooling do you bring, and who owns the data and configuration if we part ways?
- What does offboarding look like — what do we get back, in what format, how fast?
Question 10 is the one providers least expect. The answer tells you how they think about the relationship. For a wider version of this exercise, see our buyer’s checklist for choosing a managed IT provider, and for the service-level half of it, managed IT SLAs: response time vs resolution time.
FAQ: co-managed IT vs fully managed IT
What is the difference between co-managed and fully managed IT?
Co-managed IT keeps your internal IT staff and adds a provider to cover specific gaps under an agreed division of labour. Fully managed IT outsources the whole IT function to a provider who acts as your IT department. The difference is who owns which responsibilities, written down.
Is co-managed IT cheaper than fully managed IT?
The provider invoice is usually smaller, because the scope is narrower. The total cost of the function is not necessarily lower, because you are still paying internal salary and benefits. Compare the total cost of running IT, not the two invoices.
Do I need an internal IT person for co-managed IT?
Yes. Co-managed assumes someone internal owns part of the outcome. Without that, the split has nobody on one side of it, and you are buying fully managed IT with extra coordination overhead.
What happens if our internal IT person leaves?
In a co-managed arrangement this is the stress test. If the provider already holds documentation, tooling and monitoring, they can absorb more scope while you rehire. If the arrangement depended on undocumented knowledge in one person’s head, you have a gap. Ask any provider how they handle it before you need the answer.
Can we start fully managed and move to co-managed later?
Yes, and plenty of businesses do once they hire an IT manager. It means renegotiating scope and redoing the responsibility matrix. A provider who treats that conversation as a threat is telling you something.
Who is responsible when something breaks in a co-managed setup?
Whoever the written responsibility matrix says. That sentence is the whole argument for having one. Without it, both teams can reasonably believe the other owns the issue while the outage continues.
Is co-managed IT the same as IT staff augmentation?
Not quite. Staff augmentation adds people who work under your management and processes. Co-managed IT is a shared-responsibility arrangement where the provider owns defined areas outright. Providers use the terms loosely, so ask which is in the proposal.
Talk it through
Bring your own responsibility matrix. We will mark it up honestly, including the rows where the answer is “that should stay with your team.”
If you would like an outside read on your current IT setup — what is covered, what is not, and where the gaps are — contact TVG Consulting for an IT review. No obligation, and no pressure to pick a model in the first conversation.