Outsourcing IT: when it pays off, and when it doesn't

The two wrong questions

"Is it cheaper?" and "is it more secure?" are the questions you hear most often about outsourcing IT, and they are the wrong ones: the answer depends too much on the specific case to be useful in the abstract. The questions that really help you decide are different: what do I want to keep under my direct control, what am I prepared to delegate, and what level of service do I really need, rather than the one that looks most reassuring on paper.

What can be outsourced, and what is better kept in-house

In theory, almost anything can be handed to an external provider: user support, server and network management, backup, security, development. In practice, the choice depends on how close that expertise is to the core of the business.

Operational, repetitive work (day-to-day support, infrastructure maintenance, monitoring) is often the first candidate: it needs continuity and up-to-date skills that a specialist provider can guarantee more easily than a small in-house team. Strategic decisions on what to do and why, on the other hand, are best kept in the hands of people who really know the business, even when carrying them out is delegated.

The models available

What to look for in a provider

• Written, measurable SLAs: response and resolution times for each severity level, not vague phrases such as "as soon as possible".
• References you can check: talking to real clients tells you more than any brochure.
• Continuity: what happens if your usual technician changes jobs, or if the provider closes down. A good provider has a team, not a single person who knows everything.
• Transparency about data: where it is held, who has access to it, what happens if the relationship ends.
• A documented working method, not just a list of technical skills.

Common mistakes

• Depending on a single person. If only your usual technician really knows the infrastructure, their absence or departure becomes a business risk, not an inconvenience.
• Contracts without measurable KPIs. Without figures to check, "everything is fine" is an opinion, not a fact.
• No clear way out. Documentation, credentials and configurations held only by the provider make switching almost impossible: it is a silent lock-in, often discovered only when you try to leave.
• Going for the lowest price, without looking at what the SLA actually includes.

How to make the transition without interrupting work

1. Map what is there today: systems, contracts, credentials, existing documentation, or the lack of it.
2. Define the SLA you really need, according to how critical each system is, not a single level for everything.
3. Plan a handover period, with the outgoing provider if possible, to transfer knowledge without interruption.
4. Make sure you have access to everything: credentials, licences, configurations, documentation, before the old arrangement actually ends.
5. Measure the first few months: actual response times compared with the promised SLA, not just the general impression.

Quick checklist

• I have written, measurable SLAs, not just vague promises;
• more than one person at the provider really knows my infrastructure;
• I know where my data is held and who has access to it;
• I, not just the provider, have direct access to credentials, licences and documentation;
• I know what would happen, in practice, if I decided to change provider tomorrow;
• actual response times are measured, not just perceived.

In short