This question only arrives once you already employ somebody technical. You are not deciding whether to get outside help — that part is settled. You are deciding how much of the estate your own staff keep hold of, and where the boundary sits between them and whoever you bring alongside.
Co-managed means your people stay in charge of a defined slice and a provider covers the rest. Fully managed means the whole estate transfers, with your organisation setting direction rather than operating anything. Both are legitimate, and the wrong one produces friction that no amount of technical competence repairs.
The distinction is not how much you spend. It is who holds the pager, who owns the roadmap, and who is accountable when something is missed. Those questions have different answers in each model.
| Co-managed | Fully managed | |
|---|---|---|
| Who owns the estate | Split by agreement. Your team keeps named domains; the provider takes the rest. | The provider, end to end, within an agreed scope. |
| First response to a ticket | Either party, depending on how routing is configured. This has to be explicit or users guess. | The provider's helpdesk, every time. |
| Overnight and weekend cover | Usually the provider's, which is frequently the entire reason for the arrangement. | The provider's, as a matter of course. |
| Tooling | Needs a decision. Running two monitoring or ticketing systems in parallel is the most common failure in this model. | One stack, deployed and administered by the provider. |
| Roadmap and budget | Your internal lead usually keeps it, with the provider advising. | Proposed by the provider, approved by you at review. |
| Where blame lands | Ambiguous unless the boundary is written down. This is the model's central risk. | Unambiguous. That clarity is much of what you are buying. |
| Effect on internal staff | Usually positive — the interesting work stays, the queue leaves. | Depends entirely on how the change is introduced and what their new role becomes. |
If you have competent internal staff, handing everything over often wastes people you have already invested in. Co-managed exists because the problem is rarely capability — it is bandwidth, coverage and the disciplines that do not fit around a day job.
The arrangement works best when the split follows a clear principle rather than a list. A durable one: your team keeps anything requiring knowledge of the business, the provider takes anything requiring scale, shift coverage or specialist tooling. Under that rule an internal administrator keeps the finance system integration and the vendor relationships, while patch cycles, backup verification, the ticket queue and overnight monitoring move across.
Be honest about the motive. Co-managed is a poor choice if it is being used to avoid a difficult conversation about an internal hire who is not performing. Splitting the work will not fix that, and it usually makes the situation harder to see clearly.
The strongest argument for handing over the whole estate is singular accountability. When one party is responsible for everything, nothing falls into a gap, and you stop adjudicating between two groups who each believe the other should have caught it.
It is also the better answer when the internal role was never really an IT role. Many organisations have an operations manager or an office administrator who inherited the technology because they were the most patient person in the room. Fully managed gives that person their actual job back — usually a bigger win than anything on the technical side of the ledger.
If you have not yet decided whether to employ anybody technical at all, that is an earlier question — see Managed IT vs In-House IT. Our co-managed IT page describes how the split works in practice.
Comparing these two on price alone is misleading, because co-managed leaves salaries on your books that fully managed may not. What is worth understanding is which decisions actually move each number.
The provider's share is usually scoped to specific functions, so it costs less than a full engagement — but your internal salaries remain, and the true comparison is the combined figure. The provider's portion rises with the breadth of the slice, the hours it must be covered, and how much of your own tooling they are asked to work inside rather than replace.
A single figure covering the estate, so it looks larger in isolation and frequently is not once salaries, licences and recruitment are accounted for. It climbs with genuine complexity: unsupported systems still in production, several locations, unusual compliance obligations, and any expectation of on-site attendance rather than remote resolution.
The cost most co-managed arrangements miss is duplication. Two monitoring platforms, two ticketing systems, overlapping security licences and two people reviewing the same alert. It rarely appears as a line item — it shows up as effort and confusion. Decide early which stack is authoritative and retire the other one deliberately.
These assume you have already decided to bring in outside help. The variable is how much your own people keep.
That is not what the model is for, and a provider proposing it as a redundancy exercise has misunderstood the brief. The usual effect is the opposite: routine tickets, patching and overnight monitoring move away, and the internal person gets back to the projects that were being postponed. Where redundancy is genuinely the intention, fully managed is the more honest structure and should be discussed openly with the individual concerned.
By writing the boundary down before anything starts, in specific terms rather than categories. A responsibility matrix that names each function — patching, backups, identity, network, telephony, the business applications — and assigns exactly one owner to each removes most of the ambiguity. Review it at every account meeting, because the split that suited you at the outset will not suit you two years later.
Yes, and that progression is common, usually triggered by a resignation or by growth that outpaces the internal team. It is a smaller step than the initial engagement was, because documentation, tooling and access are already shared. The reverse also happens: organisations that hire a strong internal lead sometimes pull functions back.
Sometimes, but it should be an explicit decision rather than a default. A provider working inside your existing monitoring and ticketing systems is workable and occasionally preferable. What does not work is both parties running their own stack in parallel — two versions of the truth, duplicated licence spending, and alerts each side assumes the other is watching.
Fully managed is usually simpler to evidence, because one party can produce the whole record. Co-managed can meet the same obligations, but only if the responsibility split is documented and each side can demonstrate its portion. NetFusion Designs holds a SOC 2 Type 2 attestation covering our controls under either model — but under co-managed you must still evidence the functions your own team retained.
The right split depends on who you already employ and what they are good at. We are happy to say when handing everything over would waste people you already have. Read next: Break-Fix vs Managed Services, or our outsourced IT support overview.
%20(1).webp){kind=logo}
%201.webp)
