Co-managed or fully managed IT: which fits a business with one IT person

The comparison

What fully managed actually means

The provider owns the outcome. Monitoring, patching, helpdesk, backup, documentation, vendor management. When a user’s laptop will not connect, they call the provider. When something needs deciding, the provider recommends and you approve.

This works well when you have nobody internal, which describes most businesses under about 40 people. It also works when you have somebody whose job is something else entirely and who has drifted into being the IT person because they are good with computers. That arrangement costs you a good employee’s actual job.

The thing to watch for is opacity. A provider handling everything can become a black box where you have no idea what state your systems are in, no documentation you can read, and no administrative access of your own. That is not inherent to the model, it is a failure of the model, and it is why your own admin access and documentation matter even when someone else does the work.

Two questions settle whether a fully managed arrangement is healthy. Can you get a current network diagram and asset list on request? And do you hold your own global admin credentials, in your own hands, separate from the provider’s? If either answer is no, fix that before anything else.

What co-managed actually means

You keep an internal person. The provider covers specific things they cannot or should not cover.

The common shapes:

Provider covers after hours and overflow. Your person handles the day, the provider handles evenings, weekends and the days your person is off. This is the most common and the easiest to define.

Provider covers specialist work. Your person handles users and day-to-day. The provider handles firewalls, servers, migrations, cabling, anything that needs a specialist or a second pair of hands.

Provider covers tooling and monitoring. Your person does the work, using the provider’s monitoring, patching and documentation systems, so they are not building their own.

All three can work. What determines success is not which shape you pick.

Where co-managed goes wrong

It goes wrong in one specific way: the boundary is agreed verbally and generally rather than in writing and specifically.

The pattern is recognisable. Something breaks. The internal person assumes the provider is watching it. The provider assumes the internal person is handling it because it is their area. Nobody looks at it for a day and a half. Afterwards both parties can explain reasonably why it was not their responsibility.

The fix is unglamorous and takes an afternoon. Write down, for each category of system, who is primary, who is backup, and who is accountable. Servers. Firewall. Microsoft 365. Backups. Endpoints. Phones. Cameras. Line-of-business applications. Cabling. Each one gets a name.

Then write down what happens when the internal person is unavailable, and how the provider finds out that they are.

The other frequent problem is human rather than procedural. If your internal person believes the provider is there to replace them, they will not cooperate, and you will never be told about the things that are going badly. That has to be addressed directly and early, because a co-managed arrangement runs on someone choosing to share information.

The honest financial comparison

Fully managed: the per-user fee is higher, and there is no salary.

Co-managed: the per-user fee is lower, and there is a salary, plus benefits, plus the cost of that person being unavailable when they are ill or on holiday.

Co-managed is not the cheap option. It is the option that makes sense when the internal person is doing something a provider genuinely cannot do, which is usually knowing your business. Someone who understands your line-of-business software, your workflow, your customers, and which of your machines is the one that must never be touched during month end is genuinely valuable, and no external provider replicates that quickly.

Which suggests the useful test. If your internal person spends most of their week resetting passwords and unjamming printers, you are paying a salary for work a helpdesk does more cheaply, and either fully managed or a co-managed split that frees them up is better. If they spend most of their week on things specific to your business, co-managed is protecting something worth protecting.

The single-point-of-failure question

One internal person is a risk regardless of which model you choose, and it is worth naming.

If everything runs through one individual, then their holiday, their illness, and eventually their resignation are all business events. The value of co-managed is partly that somebody else already knows your environment, has documentation, and holds access. That converts a resignation from a crisis into a handover.

If you currently have one person and no provider, that is the situation to fix first, before optimising anything else.

The short answer

No internal IT, under about 40 staff: fully managed. Hold your own admin credentials and ask for documentation quarterly.

One competent internal person who is overloaded with routine work: co-managed, with the provider taking the helpdesk load and after-hours, and your person moving to projects and business systems.

One internal person who is the only one who understands a critical application: co-managed, and use the arrangement to get their knowledge documented while they are still there.

A provider you already have who cannot produce a network diagram: that is a different problem, and it is worth reading the signs honestly before assuming a model change fixes it.

Whichever you pick: put the boundary in writing. Every co-managed failure I have seen traces back to a boundary nobody wrote down.