What to hand over first

Deciding what to outsource is easier when the question is reframed. It is not "what can someone else do more cheaply", it is "what work is continuous, undifferentiated, and currently consuming people who should be doing something else".

That framing produces a fairly consistent answer, and it also identifies what should stay.

The functions that give the fastest return

Out-of-hours coverage

Almost always the first thing worth transferring, because it is the hardest to build internally and the most expensive to fake.

Genuine round-the-clock cover needs five to six people once leave, illness, training and turnover are accounted for. Below a certain scale that is not a resourcing decision, it is an impossibility. What most organisations actually have is an on-call rota that quietly burns out the two people who know how everything works.

Transferring this gives back the thing your team is most short of, which is uninterrupted time, and removes a retention risk that is usually larger than it appears.

First-line support

High volume, largely repetitive, and it fragments the day of whoever handles it. Password resets, access requests, printer problems, basic application questions.

The return here is not primarily cost. It is that your engineers stop being interrupted. An engineer interrupted eight times a day is not doing engineering, and the cost of that is invisible on any report.

Transfer it with a clear escalation boundary, and expect the first two months to involve refining where that boundary sits.

Monitoring and alerting

Watching dashboards is a poor use of skilled people and a task humans do badly for long periods. It also needs to happen continuously, which means it needs the coverage model above.

What should stay with you is deciding what is worth alerting on. That is a judgement about your business, and it should not be delegated along with the watching.

Patching and routine maintenance

Continuous, necessary, and reliably deprioritised when anything more interesting appears. That is precisely the profile of work that benefits from being someone's contractual obligation rather than someone's intention.

Retain the decisions: which systems are exceptions, what the maintenance windows are, what risk you accept for the systems that cannot be patched. Transfer the execution and the evidence.

Backup operation and restore testing

Backup configuration is usually fine. What lapses is verification, and it lapses because nothing fails when it does. The gap only becomes visible at the worst possible moment.

Handing over the operation and, crucially, the scheduled restore testing converts an intention into an obligation with a report attached.

What should stay

Architecture and standards. What the estate looks like, what technologies are chosen, how things are meant to be built. This is where your specific business context matters most, and it is the capability hardest to rebuild if you lose it.

Vendor and contract relationships. Who you buy from, on what terms, and the leverage that comes with the relationship.

Anything genuinely specific to your business. The application your operations depend on, the integration nobody else understands, the process that is actually your competitive advantage.

Risk acceptance and prioritisation. Which risks you carry, what gets funded, what order things happen in. A provider advises. The decision stays.

Enough knowledge to be a competent customer. This is the one most often lost. An organisation that transfers everything eventually cannot evaluate whether the service is good, cannot specify what it wants, and cannot leave. Keep at least one person who genuinely understands the estate.

Sequence it

Transferring everything at once is how these arrangements go badly. A workable order:

First, out-of-hours monitoring and first-line. Immediate relief, limited risk, and it establishes the working relationship on functions where mistakes are recoverable.

Then, routine maintenance and patching. Once the relationship is working and the provider knows the estate.

Then, second-line support and infrastructure operations. Deeper access, more trust required, and by now they have earned the context to do it well.

Reassess before going further. By this point you will know whether the relationship is one you want to deepen.

Each stage should run for a couple of months before the next begins. The temptation to compress this is strong when the internal team is stretched, and compressing it is the most common cause of a difficult first year.

What to prepare before the transfer

The quality of a transition depends almost entirely on what exists on day one.

• A current asset list. Imperfect is fine; absent is not.
• Documented escalation paths, with tested contact details.
• The unwritten knowledge, written. The system that must not be restarted before the nightly job. The application whose vendor support requires a specific patch level. Every estate has ten of these and they live in two people's heads.
• Agreed authority. What the provider may do without asking, per action, including out of hours.
• A definition of what good looks like for each transferred function, before the agreement is signed.

The unwritten knowledge is the one that determines whether the first three months are smooth or painful. It takes a couple of days to capture and it is worth more than any other preparation.

The test to apply

For any function you are considering transferring, ask whether the work is the same in your organisation as it would be in a similar one down the road.

If yes, it is a candidate. Someone who does it across many organisations will do it more consistently, and it is not where your advantage lies.

If not, and doing it well requires knowing something specific about your business, think harder. That is either work to keep, or work where the provider needs to be genuinely embedded rather than merely contracted.