Most of the attention in switching IT providers goes on who you're moving to. That's right. It's the most important decision in the whole process. But the handover itself, getting out cleanly from the provider you're leaving, gets far less thought, and it's where most of the friction comes from.
If you want the full picture of how a switch works week by week, start with How to switch IT providers. This piece is about the handover: the three parties involved, what your outgoing provider owes you, what it costs, and what to check before their access is gone.
The risk isn't downtime any more
For a firm of twenty to a hundred staff, your email and files live in Microsoft 365 or Google. They don't stop working because you've changed provider. Done properly, there is no downtime and nobody gets locked out.
The real risks in a handover are different. Frustration. Wasted time and energy. Confusion, disagreements and unclear responsibilities. That's what a badly run handover looks like now, and it's entirely avoidable.
Get all three parties in the room
A handover is not complicated, but it does need to be run like a small project. Agree three things up front:
- Who does what. One pair of hands on the steering wheel at any time, and everyone knows exactly who is responsible for each piece.
- When. Dates for when each service transfers, agreed by all three parties.
- What. What access, what documentation and what information needs to hand over.
Get the outgoing provider, the incoming provider and yourself aligned at the start. That usually means a direct meeting or two, and you should be in the room. Occasionally an outgoing provider will refuse to deal with the new one at all, on the grounds that they're not the client. Technically true, and easily solved: get all three parties round the table on a Teams or Zoom call. Your job in that meeting is mostly to say you want this clean, tidy, on time and on budget, then sit as a witness and take the minutes.
Beyond that, name someone on your side to own the handover. Even in a small firm, that means a stakeholder and project manager. Once everyone's aligned, the rest can happen over email and tickets. Allow an overlap of around a month.
What your outgoing provider owes you
The outgoing provider's job is not to teach the new one how to do IT. A capable incoming provider does its own discovery and verifies everything it inherits.
What the outgoing provider does owe you is cooperation. That means attending the handover meetings, answering questions, providing clarifications, and handing over admin credentials, documentation and anything else the new provider needs to take responsibility. Sometimes a walkthrough of anything unusual.
None of that is day-to-day support. It's a project, and it's reasonable for it to be chargeable.
Offboarding may expose your old provider
It's worth knowing in advance that the provider you're leaving often simply doesn't have the information. They don't have the documentation, they don't have the process, and they've never put much importance on that kind of thing. That may well be part of why service was poor and why you're leaving. Offboarding exposes those gaps like nothing else.
Don't let it derail you. It just means the incoming provider has some discovery work to do, and that needs to be planned and paid for.
Budget for both sides
Expect to pay for the handover on both sides, and treat that as a good sign rather than a cost to negotiate away.
For the outgoing provider, that's the offboarding project described above. For the incoming provider, the market norm is an onboarding charge of around a month's fees, set as a fixed project, which usually lands in the low thousands. Done properly, the work involved is often considerably more than that.
If you try to get offboarding and onboarding done for free, whoever's involved is incentivised to half do it or not do it at all. That creates real risk down the line: the new provider takes responsibility without the information to do the job. Then one day you can't print, can't sign in, or something simple like a domain, an SSL certificate or a VPN comes up for renewal that nobody knew about, and everyone's scrambling in an emergency.
The investment now buys you a provider who has gone and found the information, documented it, and can genuinely be responsible for it. If your old provider never had it, you're paying the new one to build what should have existed all along.
The information that needs to hand over
If you haven't already got these documented, the handover is the ideal time to align on them:
- Key processes: new starters, new computers, and just as importantly leavers, decommissioning and tracking of equipment.
- Permissions and approvals: where you need an audit trail or a business case for access to folders, SharePoint sites, files and email, whether for regulatory reasons or your own governance.
- Who should be consulted, who your VIPs are, and any particular locations or time zones that need handling differently.
- The non-discoverable essentials: your Microsoft or Google tenant, domain registrations, firewalls and security tools, local admin accounts on computers.
What tends to surface during a handover
Expect the odd surprise. We've taken over firms where a domain came up for renewal mid-transfer. The answer was simple: renew it where it sat, keep everything running, and transfer it soon after. The priority is always keeping everything running. It just needs surfacing and agreeing.
We've found domains muddled into an old provider's single registrar account alongside all their other clients, because that was the quickest way of doing it at the time. Untangling them became its own mini project alongside the main handover. And we've audited servers during an onboarding and found the backups weren't fit for purpose.
None of that is a disaster. It's rather the point: the handover is your chance to properly understand your risks and fix them. But it does produce unexpected work, which is why the project has to be flexible.
Red flags during the handover
Most handovers are civil and professional. But watch for these:
- No clear path or timeline to handing over credentials and access. If you or the new provider are accepting responsibility, there is no legitimate reason to withhold it.
- Refusing to deal with the incoming provider. Solved with a three-way call, but worth noting how the relationship is being handled.
- Your domain registered under the provider's account rather than your own. We see this constantly, usually with the excuse that it's tangled up with other clients on the same account. This is the ideal time to set up your own registrar account and move your domains cleanly into it.
- Data or backups held where you can't get at them. Backup contracts with bona fide third-party providers such as Microsoft, ConnectWise, Kaseya or Datto can often be novated, meaning the contract transfers to the new provider rather than starting from scratch.
- Compliance gaps in the transition. If email archives or backups matter for compliance, you may need to run old and new systems in parallel for a period. Plan for it rather than discovering it.
Removing the old provider's access
This is the step everybody forgets. Once handover is complete, the outgoing provider's access needs to come out of everything. Admin accounts, remote access tools, and anywhere they're listed as an authorised contact, such as your ISP or other suppliers.
This is a process the business should own, not the IT provider. In practice the new provider will do most of the work: removing access, cycling accounts and credentials, and making sure no third party can get in. But it should be documented and reported back to you, and it should sit on your own access control register. If you work to Cyber Essentials, FCA requirements or ISO 27001, that register is part of your governance anyway. Ideally the old provider, the new provider and the business all work from the same list of what access exists. Make sure it's done and ticked, not assumed.
What doesn't need to move
Some things may not be able to move, and it genuinely doesn't matter. You're not going to change your internet lines; at most the billing changes. Telephony and hardware leases can stay where they are too. As long as the phones keep working there's no real dependency, and worst case those contracts simply run on under the old arrangements while everything else transfers. Don't let them hold up the handover.
Expect some standardisation
If your new provider is taking responsibility for your security and uptime, expect to move onto their firewall and their security tooling. That's not a lock-in tactic. It's alignment, and it's an investment in them being able to stand behind the service. A provider who takes responsibility for an environment they didn't build and don't standardise on is making you a promise they can't keep.
Before you serve notice
Check your contract first: your notice period, the required method of notice, and whether offboarding fees are specified. Most IT contracts auto-renew, so timing matters. We cover the contract trap and when to start looking in How to switch IT providers.
Where to start
If you're weighing up whether your current provider is the problem, take the IT Provider Scorecard. It'll show you where you stand in a few minutes. And if you want to see how we run a switch from the other side, see changing your IT provider.
