Insight: How to switch IT providers (without the downtime you're afraid of)

Most of the work in switching IT providers is choosing who you switch to. That is the single most important decision in the whole process, and it deserves its own conversation. We've covered how to choose in detail elsewhere Choosing an IT provider?, How to Choose the Right IT Provider, How To Choose An IT Support Company, so I won't repeat it here. But I will say one thing before we get into the mechanics.

Matrices and spreadsheets don't cut it. Think about any organisation you know, large or small. The ones that work are the ones with good leadership, good management, good culture and good relationships. Plenty of firms with impressive credentials are disorganised and chaotic underneath. The science isn't everything. When you're choosing an IT provider you're really choosing a partnership, so ask yourself whether you'll work well with these people day to day. Not the sales professional who came to pitch. The people you'll actually deal with. That cultural and relationship match matters more than the number of engineers or the vendor badges on the website.

Right. Let's assume you've made your pick, or you're close to it, and you want to know how the switch actually works.

The downtime fear is out of date

The anxiety most people carry into this is downtime, data loss, or being locked out of their own systems mid-handover. It's a hangover from the dark ages of IT, when servers sat in a cupboard and a switch meant physically moving things.

For a firm of twenty to a hundred staff today, your key platforms will be cloud based. Email and files live in Microsoft 365 or Google. They don't stop working because you've changed provider. Taking over the licensing and subscriptions, including Azure and AWS, is a straightforward exercise for the incoming provider. Done properly, there is no downtime whatsoever, and being locked out absolutely should not happen.

The real risks are different. Frustration. Wasted time and energy. Confusion, disagreements and unclear responsibilities. That's what a badly run switch looks like now, and it's entirely avoidable.

What a proper handover looks like

A switch is not complicated, but it does need to be run like a small project. That means clear communication, good planning, tracking, and keeping everything updated. The same things that make any business process work.

Specifically, you want three things agreed 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 switch. A stakeholder and project manager on the client side, even for a small firm. Once everyone's aligned, the rest can happen over email and tickets. Allow an overlap of around a month.

Offboarding will expose your old provider

Here's something worth knowing in advance. Very often the provider you're leaving 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 the switch

Expect to pay for this, on both sides, and treat that as a good sign rather than a cost to negotiate away.

For the outgoing provider, handover is not day to day support. Coordinating, gathering admin credentials, handing over documentation, perhaps a walkthrough. It's a project, and it's reasonable for it to be chargeable.

For the incoming provider, budget for onboarding too. At least the equivalent of a month's fees, possibly double depending on the state of things. Put simply, if you try to get the 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.

What the onboarding month actually looks like

We schedule onboarding projects to run for a month, starting with a kickoff meeting and introductions. Along the way we'll be meeting your team, because rapport and a collegiate working relationship matter as much as anything technical. This post isn't about the onboarding itself, so I won't get into passwords, documentation, tooling and security measures here, but know that there are a lot of moving parts.

Two things worth understanding up front. First, support can usually transfer during the onboarding rather than at the end of it, as long as there's enough information to do the job. You should still expect a clear go-live cutover, so there's never any doubt about who your team calls. Second, most onboardings run longer than the month on paper, and that's fine. The reality of a firm of twenty to a hundred staff is that this takes investment on both sides, and availability gets in the way. An office manager on leave. An operations manager buried in something urgent. The project should fit around your business, not dictate to it and get in the way of business as usual. Doing it right beats rushing it.

Your side of the bargain is showing up. Attend the meetings, share information, act as the conduit when needed, and put the time into learning how to work with the new provider: their processes, their procedures, sharing your policies. That investment is as much a part of the switch as anything else.

And expect the odd surprise. We've onboarded firms where a domain came up for renewal mid-transfer. A bit of extra fuss, but the answer was simple: renew it where it sat, keep everything running, and transfer it soon after. The priority in that scenario is always keeping everything running. It just needs surfacing and agreeing, and we've seen it more than once. 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, and untangling them became its own mini project alongside the main migration. And we've audited servers during an onboarding and found the backups weren't fit for purpose. That's not a disaster. It's rather the point: onboarding is your chance to properly understand your risks and fix them. But it does produce unexpected work, which is exactly why onboardings have to be flexible.

The information that matters

If you haven't already got these documented, the switch 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.

Red flags to watch for

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.
• 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. It's a small project and well worth doing.
• Data or backups held where you can't get at them. Note that backup contracts with bona fide third-party cloud 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.

Importantly, 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 are all working from the same list of what access exists, which should already be in the access log. Make sure it's done and ticked, not assumed.

Phones, internet lines and hardware leases

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 switch.

Check your contract before you serve notice

Most IT contracts auto-renew, usually yearly, sometimes longer. That's common across the industry and it works both ways: the provider can plan staffing and cloud commitments, you get price stability. But it means you should check three things before you do anything else. Your notice period, the required method of notice, and whether offboarding fees are specified. Ideally that was all clear from the outset. If you're reading this before you've signed with anyone, make sure it's clear in the next contract.

Expect some standardisation

One last thing. 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.

Where to start

If you're weighing up whether your current provider is the problem, take the Scorecard . It'll show you where you stand in a few minutes. And if you're ready to talk about what a switch would look like for your firm, start here.