What does co-managed IT mean?
In a fully managed setup, the provider runs everything. In co-managed IT, responsibility is shared and written down. Your team might handle staff laptops, software requests and day-to-day questions, while the provider looks after the servers, backups, patching and security monitoring. Both sides can see the same systems, and both know where their part ends.
It works best when the split follows skills and time, not job titles. If your developer is great at your application but doesn’t want to be woken at 3am by a full disk, that’s a natural line to draw.
Who does what in co-managed IT?
| Area | Your team | Provider |
|---|---|---|
| Staff devices and office | Yes | No (in our case) |
| Business applications | Day-to-day use and requests | Server side, performance |
| Servers and hosting | Visibility and approvals | Setup, patching, tuning |
| Backups | Knows how to request a restore | Runs, stores off-site, tests |
| Security | Staff accounts and policies | Hardening, firewalls, scanning |
| Out-of-hours alerts | Escalation contact | First response |
Every business draws the line differently. The important thing is that it is drawn — in writing.
When does co-managed IT make sense?
- You have one or two technical people who are stretched thin or can’t cover holidays and nights.
- Your team knows the business but not servers — for example, a developer who builds your app but doesn’t want to run Linux in production.
- You’re moving to the cloud and need experience your team doesn’t have yet.
- You need a second pair of eyes on security and backups.
- You want to keep control and inside knowledge, rather than outsourcing everything.
What are the pros and cons?
Benefits
- Your team keeps its knowledge and control
- Cover for nights, weekends and holidays
- Specialist skills when you need them
- Less pressure on one key person
- Grows with you, area by area
Watch-outs
- Gaps appear if the split is vague
- Two teams need one source of truth
- Changes need agreed approval rules
- Access must be tidy and audited
- Someone must own the relationship
What should a co-managed IT agreement cover?
The agreement doesn’t need to be long, but it should be specific. Write down which systems the provider is responsible for, how alerts reach each side, who can approve changes and how quickly, and what happens out of hours. Add how access is granted and removed, where documentation lives, and how either side can end the arrangement with a clean handover. The clearer this is on day one, the fewer “I thought you were doing that” moments later.
How do you set up co-managed IT well?
- Map what exists — Servers, accounts, backups, who has access.
- Draw the line — A written list of who owns each area.
- Agree how changes happen — Who approves, how you’re told, how to roll back.
- Share the view — Same monitoring, same documentation, same alerts.
- Review regularly — Adjust the split as your team and systems change.
How we work alongside your team
We focus on the server and infrastructure side: Linux servers on AWS, Azure, Google Cloud, Hetzner, DigitalOcean, Vultr, OVHcloud or our own, plus hosting, backups and security hardening. Your team keeps owner access. Our engineers make changes like performance tuning with your approval. We can also look after staff PCs and Macs remotely, and we work happily alongside an in-house person or a local technician for hands-on jobs. See our server management service for details.
Questions we get asked
What is the difference between managed and co-managed IT?
Managed IT means the provider runs the agreed systems on its own. Co-managed IT means your team and the provider share the work, with a written split of who owns what.
Will a co-managed provider replace my IT person?
No — the point is to support them. Your team keeps the work it does best and gains cover and specialist help.
Who has admin access in co-managed IT?
Both sides usually do, for their areas. Each person should have their own named account, so every change can be traced.
Can we start with just servers?
Yes. Many businesses start with one area, such as web or application servers, and add more later.
Something else on your mind? Ask us directly →
