Migrating an outsourced IT service desk to an embedded offshore team means ending or reducing a third-party managed service contract and rebuilding the same capability as a dedicated, office-based team that you direct yourself, usually in a lower-cost location. Done properly it is a phased transition over three to six months, not a switch you flip. The two things that determine whether it works are the baseline you capture before you start, and how seriously you treat knowledge transfer.
This is a playbook for UK companies and MSPs that already outsource their service desk and have concluded the arrangement is not working. It assumes you are not returning the function to expensive UK headcount, and that you want to keep the cost position while taking back control.
Key takeaway
Most failed service desk migrations fail for the same reason: the business never measured what it had. Without a pre-migration baseline you cannot prove improvement, you cannot hold anyone to account, and you will not spot degradation until users complain. Capture the baseline before you serve notice, not after.
Why companies leave an outsourced service desk
The decision to move rarely comes from a single failure. It builds up over a contract term, and the pattern is consistent enough to be recognisable.
Shared agents rather than dedicated ones. Multi-tenant service desks are efficient for the provider precisely because agents work across several clients. That efficiency is what makes the price attractive. It is also why the agent handling your ticket may know very little about your environment, and why the person who solved the same problem last month is now on a different account.
Attrition inside the provider. Contact centre and service desk roles carry high turnover across the industry. When your desk sits inside a provider, that churn is invisible to you until it shows up as declining resolution quality. You do not choose the replacements, you are not told when experienced people leave, and each departure takes undocumented knowledge with it.
Change requests become the commercial relationship. Anything outside the original statement of work is a variation, and variations are priced. Teams learn to stop asking. The desk gradually stops adapting to how the business actually works, and the gap between what you need and what you contracted for widens every quarter.
Institutional knowledge ends up in the wrong place. Runbooks, known error records, workarounds and the informal understanding of who to call are all built inside the provider's systems and people. That knowledge is an asset your business paid for. Whether you can actually take it with you depends entirely on what your contract says, which is why the contract review comes early in this playbook.
SLAs that are met while the service gets worse. Response-time targets are easy to hit and easy to game. A ticket can be acknowledged within minutes, bounced between tiers for a week and closed without the user's problem being solved, and the contract will show green. If your SLA reporting looks healthy while your users are unhappy, you are measuring the wrong things.
None of this makes outsourcing wrong. Traditional outsourcing genuinely suits stable, high-volume, well-documented processes where you want someone else to own the outcome. We set out where each model fits in our comparison of BPO versus an embedded offshore team. The problem arises when a process that needs contextual judgement and institutional memory has been handed to a structure designed for neither.
Step one: baseline your current desk before you do anything else
This is the step companies skip, and skipping it is the single most common cause of a migration that cannot be defended afterwards.
A word on industry benchmarks. You will find plenty of published figures for cost per ticket, first contact resolution and mean time to resolve. Treat them carefully. The genuinely rigorous benchmarking datasets, such as those produced by MetricNet, are commercial products and their figures are not publicly available. A great deal of what circulates freely online as an industry benchmark traces back to vendor marketing rather than to research, and often carries no stated sample or methodology. Comparing your desk against an unverifiable average tells you very little.
Your own historical performance is a far better yardstick, and you already own the data. Capture at least three months, and ideally twelve, of the following before you serve notice.
| Measure | Why it matters in a migration |
|---|---|
| Ticket volume and mix | Determines how many people you need and at what skill level. Splitting by category, priority and requester group tells you which queues can move first. |
| First contact resolution | The clearest early indicator of failed knowledge transfer. If FCR drops after cutover, your new team does not know what the old one knew. |
| Mean time to resolve | Measure by priority band, not as a single average. A blended figure hides the degradation that users actually feel. |
| Escalation rate | Rising escalations after cutover mean tier one is out of its depth. This is your earliest warning signal. |
| Reopen rate | Catches the tickets closed to hit a target rather than because the problem was solved. |
| Cost per ticket | Your true baseline cost, including internal management time spent on the provider relationship. That time is real and routinely omitted. |
| User satisfaction | Run your own survey before you move. Provider-reported satisfaction is measured by the party being judged. |
Extract this data yourself, from your own ITSM tooling where you can. If the only route to it is a report the provider generates, request it well before you give any indication that you are considering leaving.
Step two: read the contract properly
Three provisions determine how difficult your exit will be, and they are worth finding before you build a plan around assumptions.
Notice and termination. Establish your notice period, whether you can terminate for convenience or only for cause, and whether there is an early termination charge. Managed service contracts commonly run to multi-year terms with substantial notice, so the calendar may drive your plan more than anything else.
Exit management and transition-out obligations. A well-drafted contract obliges the provider to co-operate with an orderly handover: supplying data, documenting processes, and supporting a successor for a defined period. A poorly drafted one leaves you dependent on goodwill from a supplier who has just lost your account. Find out which you have before you serve notice, because your leverage is highest beforehand.
Data and intellectual property. Who owns the knowledge base articles, the runbooks, the ticket history and the configuration data? If ownership sits with the provider, or the contract is silent, you may be entitled to far less than you assume. Ticket history in particular is valuable: it is the record of how your environment actually behaves.
Where TUPE may apply
The Transfer of Undertakings (Protection of Employment) Regulations 2006 can apply when a service provider changes, not only when a business is sold. Acas confirms that transfers can include both business transfers and service provider changes, which means employees currently delivering your desk may in principle have rights on a change of provider.
Where the work moves offshore, the position is more specific than it first appears. The service provision change rules require the organised grouping of employees to be situated in Great Britain immediately before the change, so moving a service wholly outside the UK will often fall outside that limb of TUPE. A business transfer analysis can work differently, and government guidance notes that employees of a UK business based outside the UK may still be protected in a business transfer. The facts decide it, so take employment law advice early rather than assuming either outcome.
Step three: treat knowledge transfer as the main risk
Every service desk runs on a large body of undocumented knowledge. Which application breaks after a particular update. Which supplier actually answers the phone. Which director should never be left waiting. None of this is in the knowledge base, and none of it transfers by itself.
A structured transfer has three stages, and compressing them is where migrations go wrong.
Documentation and extraction. Pull the knowledge base, runbooks and known error records into your own systems. Then audit them honestly against real ticket history, because documentation that has not been maintained is worse than none: it produces confident wrong answers.
Shadowing. Your incoming team observes the current desk handling live tickets. This is where the undocumented context surfaces, and it needs long enough to cover the monthly and quarterly cycles, not just a fortnight of routine traffic.
Reverse shadowing. Your incoming team handles the tickets while the experienced team observes and corrects. This is the stage most often cut when the timetable slips, and cutting it is precisely why first contact resolution collapses after cutover.
Build the transfer plan around ticket complexity rather than a flat calendar. Password resets and access requests transfer in days. Anything touching a bespoke application, an integration or a regulated process takes considerably longer, and those are the tickets that damage your reputation internally when they are handled badly.
Step four: phase the cutover
A single-date switch concentrates all your risk on one morning. Phasing spreads it and gives you a route back if something breaks. A realistic sequence for a mid-sized desk looks like this.
| Phase | Indicative duration | What happens |
|---|---|---|
| Discovery and baseline | 4 to 6 weeks | Capture metrics, review the contract, map ticket categories, decide the target operating model and location. |
| Build the team | 6 to 10 weeks | Recruit, onboard, set up the office, tooling and access. Runs in parallel with the notice period. |
| Knowledge transfer | 4 to 8 weeks | Documentation, shadowing and reverse shadowing, sequenced by ticket complexity. |
| Pilot queue | 2 to 4 weeks | The new team takes one contained category end to end. Measure against baseline before widening. |
| Dual running | 4 to 8 weeks | Both desks live, volume shifting progressively by category or shift. Your safety net. |
| Full cutover | 1 to 2 weeks | Remaining volume transfers. Provider access revoked on a planned schedule. |
Dual running costs money, because you are paying twice for a period. Put that cost in the business case from the beginning. A migration presented without it will look cheaper than it is, and the gap will surface at exactly the wrong moment.
Step five: work the risk register
| Risk | Mitigation |
|---|---|
| Provider disengages after notice | Extract data and documentation before serving notice. Tie a meaningful proportion of final payment to transition-out obligations being met. |
| Service dips during cutover | Expect a dip and plan for it. Publish the transition to users, set expectations, and keep dual running until the pilot metrics hold. |
| Access and identity gaps | Provision the new team fully before revoking anything. Run a joiners and leavers schedule for the transition itself, and audit it afterwards. |
| Out-of-hours cover lapses | Transfer in-hours volume first. Move out-of-hours and major incident cover last, once the team has proven itself in daylight. |
| Key person dependency returns | Document as you go rather than afterwards. If one analyst becomes indispensable, you have rebuilt the problem you left. |
Data protection: the detail most comparisons get wrong
Where your team sits has direct consequences under UK data protection law, and this is worth getting right early because it can influence the location decision itself.
Giving an overseas organisation access to personal information you hold counts as a transfer, even if no data leaves your systems. The Information Commissioner's Office uses exactly this scenario as its worked example: a UK business that allows an organisation in India to access personal information on its systems to support customer services is making a restricted transfer. Every restricted transfer must be covered by UK adequacy regulations, appropriate safeguards, or an exception.
| Location | UK adequacy position | What that means in practice |
|---|---|---|
| Romania | Covered, as an EEA member state | Personal information can flow freely without additional transfer safeguards. |
| South Africa | No UK adequacy regulations | Restricted transfer. Requires a safeguard such as the International Data Transfer Agreement, plus a transfer risk assessment. |
| India | No UK adequacy regulations | Restricted transfer. Same requirement: an appropriate safeguard and a transfer risk assessment. |
This is not a reason to rule out South Africa or India. It is an administrative step, not a barrier, and a very large number of UK companies complete it routinely. But it is work, it needs owning, and it belongs in the plan rather than being discovered late. Note also that you carry this obligation whether the team is yours or a providers. Outsourcing does not transfer it away.
Choosing where the team sits
For a UK service desk, time zone tends to matter more than raw salary differential, because a desk that cannot answer at 09:00 is not really your desk.
South Africa suits UK-hours service desk work particularly well. Cape Town runs one to two hours ahead of the UK depending on the season, so the working day overlaps almost entirely. English is a first language for a large part of the professional workforce, and the country has an established base of UK-facing service operations. For a desk whose users are in the UK and expect a live answer during business hours, this alignment is the deciding factor.
India offers the deepest technical talent pool and the strongest cost position, and the time difference becomes an advantage where you need genuine overnight or follow-the-sun cover. Be realistic about the human cost of permanent night shifts supporting UK daytime hours, since sustained night working is associated with higher attrition, which is the very problem you are trying to solve.
Romania makes most sense where you serve EU users as well as UK ones, need European language coverage, or where the adequacy position materially simplifies a compliance-heavy environment.
A multi-hub approach is worth considering rather than treating this as one choice. In-hours cover from a time-aligned hub with overnight cover elsewhere is a common and sensible pattern, and it removes the single-location dependency that makes some boards uncomfortable. We compare the underlying options in our guide to offshoring, nearshoring and onshoring.
What good looks like ninety days after cutover
Set the success criteria before you start, and judge against your own baseline rather than an external average.
By ninety days, first contact resolution should be at or above your pre-migration baseline. Mean time to resolve should be back to baseline by priority band. Escalation and reopen rates should be stable or improving. User satisfaction, measured by your survey rather than a supplier's, should be at least level. And the team should be adding knowledge base articles rather than only consuming them, which is the clearest sign that institutional memory is now accumulating inside your business instead of someone else's.
Expect a dip in weeks one to four. A migration that shows no dip at all usually means volume has not really moved yet. What matters is the shape of the recovery, and whether it is trending back to baseline by the end of the first quarter.
Where Potentiam fits
Potentiam builds and operates embedded offshore teams for UK and European companies across four hubs: South Africa, Romania, India and Brazil. For service desk and ITSM work we provide the office, the local management, the recruitment and the in-country HR, while you keep ownership of priorities, processes and quality standards. The team works to your standards inside your tooling, and the institutional knowledge accumulates in your business.
If you are weighing up a migration, the most useful first step is the baseline. You can do that work yourself with the table above, and you should do it whether or not you end up moving. Our guide to offshore service desk teams covers how the operating model works once the transition is complete, and the embedded offshore team model explains the wider approach.
Frequently asked questions
How long does it take to migrate an outsourced service desk to an offshore team?
Typically three to six months from decision to full cutover, though the contractual notice period often sets the pace rather than the operational work. Discovery and baselining take four to six weeks, team build six to ten weeks, knowledge transfer four to eight weeks, and a phased cutover with dual running a further six to twelve. Much of this runs in parallel.
Does TUPE apply when moving a service desk offshore?
TUPE covers service provision changes as well as business transfers, so bringing a service back in house or moving it between providers can trigger it. Where the work moves offshore, the service provision change rules require the organised grouping of employees to be situated in Great Britain immediately before the change, so a wholly offshore move often falls outside that route. A business transfer analysis can differ. This turns on the facts, so take employment law advice before committing to a timetable.
Who owns the knowledge base and ticket history in an outsourced service desk?
It depends entirely on your contract. Some agreements give the client full ownership of documentation and ticket data; others leave ownership with the provider or say nothing at all. Establish this before serving notice, because your ability to insist is greatest while the relationship is still live.
Do I need extra data protection measures for an offshore service desk?
If the team is outside the UK and is a separate legal entity, giving them access to personal information is a restricted transfer under UK GDPR, even if the data never leaves your systems. Romania is covered by UK adequacy as an EEA member state. South Africa and India are not, so transfers there need an appropriate safeguard such as the International Data Transfer Agreement together with a transfer risk assessment. This applies equally to an outsourced provider.
Will service quality drop during the transition?
Expect a dip in the first four weeks. The way to contain it is to phase the cutover, run both desks in parallel while volume shifts, start with a contained pilot queue, and move out-of-hours cover last. Judge recovery against your own pre-migration baseline, which is why capturing that baseline first matters so much.
Which location is best for a UK service desk?
For UK business-hours cover, South Africa aligns most closely: Cape Town sits one to two hours ahead of the UK and English is widely a first language. India suits overnight and follow-the-sun cover and offers the deepest technical talent pool. Romania fits where you also serve EU users or need the simpler adequacy position. Many organisations combine hubs rather than choosing one.
