Most businesses that move to co-managed IT have the same concern: that the transition will disrupt the team, create a gap in support, or leave the new internal hire and the MSP working at cross purposes before they have found their rhythm. Those risks are real. They are also entirely manageable if the transition is structured correctly. This article is the structure.
Three signals show it is time to move from fully outsourced to co-managed IT
Businesses rarely decide to bring IT in-house on a whim. In practice, three triggers show up again and again.
The first is headcount. Once a business grows past the point where a single external helpdesk can respond fast enough, the lag becomes visible to everyone, not just IT. The second is a compliance requirement that needs a named internal owner, whether that is Cyber Essentials Plus, ISO 27001, or a sector-specific regulation. The third is a defined project such as an office move, a platform migration, or M&A activity, where the business needs an IT presence on the ground at a pace an MSP alone cannot match.
These are observable signals, not abstract thresholds. If one of them is already true for your business, the decision has effectively already been made.
Co-managed IT does not mean your MSP does less work
The most common misconception about co-managed IT is that it means the MSP steps back. It does not. The scope of MSP work typically stays the same or grows. What changes is that first-line, business-context work moves to the internal hire, which frees the MSP to operate at a higher level. If the expectation going in is that the MSP contract will shrink the moment someone is hired internally, the transition starts on a misaligned assumption.
Four things must be agreed before the transition starts
Transitions that skip any of these four tend to surface the skipped item as the first real point of friction.
The responsibility matrix should be signed off before day one. A written matrix, not a drafted one, needs to exist before the internal hire starts. Without it, both teams operate on assumption rather than agreement.
The MSP contract needs a scope review before the internal hire starts. The existing fully outsourced contract almost certainly includes first-line support that is about to move internally. This is not about cutting costs. It is about making sure the MSP’s remaining scope is clearly defined, with no gap between what the internal hire covers and what the MSP covers. This is the step most businesses leave too late.
System access should be provisioned before the first day, not requested on it. The internal hire needs an admin-level seat in the DMS (formerly MDM), access to the helpdesk system, visibility into monitoring alerts, and credentials to the key business platforms they will support. The MSP should run this provisioning as part of the transition. It is a useful early test of how the arrangement will actually function.
Employees need a simple communication plan for who to contact. The message should be plain: from this date, day-to-day IT questions go to the internal hire; anything they cannot resolve comes back to the MSP. If employees do not know the new arrangement exists, they will keep contacting the MSP for everything, which defeats the model before it starts.
The first 90 days follow three distinct phases
| Phase | Focus | Who Owns Tickets |
|---|---|---|
| Days 1 - 30 | Observation and shadowing | MSP retains full ownership |
| Days 31 - 60 | First-line ownership | Internal hire owns first-line; MSP is the escalation point |
| Days 61 - 90 | Cadence and review | Shared, with a formal check-in cadence in place |
Days 1 to 30 are for observation and shadowing, not independent decisions
The internal hire should not be making independent decisions in the first month. Their job is to learn how the MSP operates, shadow ticket resolution, get familiar with the device estate and DMS configuration, and start building relationships with the team. The MSP should treat this as onboarding the internal hire, not handing over to them. Ticket volume and resolution responsibility should not shift materially during this phase.
Days 31 to 60 shift first-line ownership to the internal hire
The internal hire starts owning first-line tickets, with the MSP remaining the escalation point for anything outside agreed scope. This is where the responsibility matrix gets its first real test, since grey-area incidents will arise. The first one should be discussed openly rather than resolved by whoever gets there first, because that resolution becomes the precedent for everything after it.
Days 61 to 90 introduce a formal review cadence
By day 90, there should be a weekly or fortnightly check-in between the internal hire and the MSP account manager, and the first formal review of the responsibility matrix should happen at this point. The point of the review is not to overhaul the matrix, but to confirm that what was agreed on paper matches how the arrangement is actually running. Anything that has not worked as expected should be documented and addressed before it becomes a habit.Three Friction Points Cause Most Co-Managed Transitions to Struggle
An internal hire who escalates everything recreates the old model
The most common early failure mode is an internal hire who lacks confidence, or has not been given clear scope, and escalates every ticket to the MSP. This quietly recreates the fully outsourced dynamic under a different name. The prevention is clear scope in the responsibility matrix, an agreed list of ticket types the internal hire is expected to resolve independently, and a regular check-in where escalation patterns get reviewed.
An MSP that steps back too quickly leaves a support gap
The mirror problem is an MSP that reads the co-managed arrangement as permission to reduce engagement, assumes the internal hire will ask when they need help, and is not visible enough in the early weeks. The prevention is agreeing an explicit minimum engagement level for the first 90 days: weekly check-ins, shared ticket visibility, and a named MSP contact the internal hire can reach directly.
A responsibility gap at the worst moment is what the matrix should prevent
The scenario every transition should plan for is a security incident or business-critical outage that falls in the gap between internal and MSP scope. The responsibility matrix is designed to prevent this, but only if it explicitly names escalation paths for incidents, not just routine support. A useful early step is a tabletop exercise in the first 30 days: walk through a hypothetical incident and confirm both teams know who owns what at each stage.
What this means for your business
A co-managed transition succeeds or fails on sequencing, not intent. The matrix, the contract review, the access provisioning, and the communication plan all need to happen before the internal hire’s first day, not during their first week. Get that sequence right and the first 90 days become a predictable ramp rather than an improvisation.
If you are planning a move to co-managed IT and want to structure the transition correctly from the start, Dr Logic can run a pre-transition review. We co-manage IT for Mac-first businesses across the UK and can tell you quickly what needs to be in place before your internal hire starts.
Related articles
- Co-Managed IT vs Fully Outsourced IT: Which Model Actually Fits Your Business?
- Co-Managed IT: Who Actually Owns What? A Responsibility Matrix for Mac-First Businesses
- MSP vs In-House IT vs Apple Specialist: Which Actually Works?
FAQs
What is the difference between co-managed IT and fully outsourced IT?
Fully outsourced IT means an MSP handles all support for your business. Co-managed IT means an internal hire owns day-to-day, first-line support while the MSP continues to provide specialist depth in areas like security, compliance, and Apple device management, working to an agreed scope rather than replacing the internal team.
How long does the transition to co-managed IT usually take?
The structured transition typically runs over 90 days: the first 30 for observation and shadowing, the next 30 for the internal hire to take on first-line ownership, and the final 30 for establishing a formal review cadence. The pre-transition setup, including the responsibility matrix and access provisioning, should be complete before day one.
Does moving to co-managed IT reduce our MSP contract cost?
Not usually, and it should not be the goal of the transition. The MSP’s scope typically shifts rather than shrinks, moving away from first-line support and towards specialist and strategic work. Treating co-managed IT primarily as a cost-cutting move tends to create the exact scope confusion the transition is meant to avoid.
What system access does an internal hire need before their first day?
They need an admin-level seat in the DMS (formerly MDM), access to the helpdesk and ticketing system, visibility into monitoring alerts, and credentials to the key business platforms they will support. Provisioning this before day one, rather than requesting it during onboarding, avoids an early and avoidable delay.
