Managed services or in-house IT: a decision framework

The version we are usually asked is: we are around a hundred people now, our one systems administrator is overwhelmed, do we hire two more or hand it to a provider? Framed as a cost comparison, that question rarely produces a good answer, because the two options are not the same product.

Hiring buys availability and context — someone in the building who knows why the warehouse system was configured strangely in 2019. A managed contract buys coverage and depth — a team that has seen your problem before, and someone awake at three in the morning. Those are different goods, and which one you need depends on what your systems demand rather than on which line item is smaller.

What follows is a framework based on operational maturity rather than headcount, plus an honest way to compare the costs once you know what you are comparing.

The comparison most companies run is a salary against a monthly contract. That is not a comparison; it is one column of a two-column problem. Build the in-house figure properly using your own numbers — we deliberately give no figures here, because the ones that matter are local to your city, sector and role, and any number we printed would be wrong for you.

Collect these for the in-house column

• Gross salary for each role you would hire.
• Statutory contributions, benefits, insurance and bonus — your finance team can give you the multiplier they already use for loaded cost.
• Recruitment cost, amortised over expected tenure. Specialist infrastructure roles are not quick hires.
• Workspace, equipment, and the software and tooling licences per person.
• Training and certification to keep skills current — a real annual line, not an optional one.
• Management overhead: the share of a senior person's time spent directing and reviewing the work.
• Cover for leave, illness and departure. This is the item most often omitted and the one that hurts most: a single administrator means no coverage for four weeks a year, and a resignation leaves a months-long hole.

And these for the managed column

• The contracted monthly fee at your actual estate size.
• Onboarding and transition cost — real, one-off, and often underestimated at three to six months of partial double-running.
• Work outside scope. Read the scope carefully: projects, migrations and new deployments are frequently billed separately from steady-state operations.
• Your own retained effort. Someone internal must own the relationship, set priorities and hold the provider to account. Budget a real fraction of a role for it.
• Tooling you still license yourself, if any.
• Exit cost and notice period, should you bring it back in-house later.

Compare over three years, not one. In-house costs rise with salary inflation and tend to require a second hire before you expect it; managed contracts tend to step up at renewal and as the estate grows. Model both curves rather than two points.

Even where the three-year totals land close together, the two options behave differently, and that behaviour is often the deciding factor.

• In-house cost is a step function. One engineer covers a range of workload; the next unit of demand requires a whole additional person. Between steps you are either underloaded or, more commonly, quietly overloaded.
• Managed cost is closer to a slope. It scales with the estate in smaller increments, which suits a business whose systems are growing steadily.
• In-house carries concentration risk. With a team of one or two, a resignation is an operational incident. The cost of that risk is real even though it never appears in the budget.
• Managed carries dependency risk. Knowledge of your environment accumulates outside the company, and reversing that takes deliberate effort and documentation you must contractually require.
• Out-of-hours changes everything. Genuine 24/7 coverage in-house needs enough people for a rota. If your systems need it, the in-house column grows considerably, and this single requirement decides many of these comparisons on its own.

Rate your organisation on five dimensions, from 1 to 5. The pattern of scores points to the model far more reliably than headcount does.

1. Estate complexity. 1 = a handful of standard cloud services and laptops; 5 = multiple environments, legacy systems, integrations and a datacentre footprint.
2. Change rate. 1 = a few changes a quarter; 5 = continuous deployment and constant new work.
3. Availability demand. 1 = business hours, some downtime tolerable; 5 = round-the-clock, minutes matter, contractual commitments exist.
4. Regulatory load. 1 = none; 5 = audited controls, evidence requirements, data residency obligations.
5. Differentiation. How much of this technology is your actual competitive advantage rather than plumbing? 1 = it is all plumbing; 5 = the platform is the product.

Reading the pattern

• Mostly 1s and 2s. Neither a team nor a heavy contract is warranted. A light managed arrangement plus one capable generalist who also handles internal support is usually the right shape.
• High availability or regulatory load, low differentiation. The clearest case for managed services. You need depth and coverage you cannot economically hire, on systems that are not where you compete.
• High change rate and high differentiation. Build in-house. Where the platform is the product, the feedback loop between engineering and operations is too valuable to place outside the company.
• High complexity, mixed elsewhere. Hybrid. This is where most growing companies genuinely sit.
• Everything high. A retained team for the differentiating platform and a managed layer underneath it — and a serious conversation about whether the estate needs simplifying before either.

Hybrid is the common answer and the easiest to do badly. Done well it is a deliberate split; done badly it is an unowned overlap where both sides assume the other is watching.

The line that works is between what differentiates you and what does not. Keep in-house the things that require business context and shape your product: application knowledge, data and integration decisions, vendor and architecture choices, and the relationship with the business. Place with a provider the things that require depth, breadth and coverage: infrastructure monitoring, patching, backup operations, network and endpoint management, out-of-hours response and first-line support.

Making the split hold

• Write down who owns each system, singularly. Shared ownership of an alert means nobody owns it.
• Define escalation in both directions — when the provider hands to you, and when you hand to them.
• One toolset, shared visibility. If the provider monitors in their system and you monitor in yours, incidents are debated rather than resolved.
• Documentation as a contractual deliverable. Runbooks and configuration in your repository, kept current. This is what keeps the arrangement reversible.
• A monthly service review with real numbers — incidents, response times, recurring causes, changes delivered. Without it, the relationship drifts into ticket-shuffling within a year.

The internal role this leaves — someone accountable for the whole picture, setting direction and holding the provider to account — is not optional. Organisations that outsource without it get exactly the service they specify and no more, which is rarely what they wanted. Where that direction-setting is itself the gap, advisory work is a better first step than either hiring or contracting.

Rather than reassessing on a calendar, watch for these. Each is a reasonably reliable indicator that the current arrangement has been outgrown.

Signs your in-house arrangement is under strain

• Patching, backups and certificate renewals slip regularly, not through negligence but because firefighting always wins.
• One person is a single point of failure and cannot take leave without anxiety.
• Nobody has time for improvement work; every week is consumed by keeping things up.
• Incidents outside working hours are handled by whoever happens to see the message.
• You keep buying point solutions because there is no capacity to run anything properly.

Signs your managed arrangement has stopped fitting

• Every request is met with “that is outside scope” and a change order.
• Tickets are closed within the agreed response time and the underlying problem recurs monthly.
• Your own team routinely works around the provider because going through them is slower.
• The provider cannot tell you why something is configured the way it is, and neither can you.
• Your strategic direction has moved into territory where the technology is now a differentiator.

The second list matters as much as the first. Managed services suit a stage of a business, not a business forever, and bringing work back in-house as you grow is a normal progression rather than an admission of error — provided the documentation you required in the contract makes it possible.

If you are in the middle of this decision, work in this order. It takes two or three weeks and replaces an argument about cost with a comparison of two specified options.

1. Inventory the work, not the systems. List what actually gets done in a month — patching, backups, user administration, monitoring, incidents, projects — and estimate hours against each. Most teams find that routine operations consume far more than anyone assumed.
2. Separate keep-running from build-new. They need different people and are often best sourced differently. Conflating them is why improvement work never happens.
3. Score the five maturity dimensions with both a business leader and a technical one in the room.
4. Set the availability requirement explicitly. If you have not sized recovery objectives per workload, do that first — our RTO and RPO primer covers it, and the answer frequently decides this whole question.
5. Build both cost columns fully loaded over three years, with your own local figures.
6. Decide, and write down the boundary. Who owns what, how escalation works, and what would cause you to revisit. Set a review date twelve months out.

One closing observation from doing this repeatedly: the organisations that get the most from managed services are not the ones with the least internal capability. They are the ones with a clear internal owner who knows precisely what they have outsourced and why. Whichever way this decision goes, that role is the one to fill first.