Most businesses that are unhappy with their IT provider do not leave. They complain to each other, they put up with it for another year, and they renew. Not because anyone talked them out of it, but because nobody could picture the week it would take, and the unknown felt more expensive than the problem.
We onboard businesses off other providers constantly, so we see that week from the other side. It is rarely as bad as people fear. But it is much worse when nobody checked a few things first, and almost all of the damage is done before notice is ever given.
So this is the buyer's side of the process. What to check, what to ask for, and where it goes wrong. It applies whoever you end up moving to.
Before you give notice, work out what you actually own
This is the whole ballgame. A handover is easy when the assets are yours and someone is simply handing back the keys. It is painful when it turns out your provider owns something you assumed was yours.
You can check most of this quietly, without involving your current provider at all.
- Your Microsoft 365 tenant. There is a difference between a provider who administers your tenant through a delegated relationship and a provider who created the tenant and holds the only global administrator account. The first is normal. The second means your email, files and identities sit inside something you do not control.
- Your domain name. Check the registrant at the registrar, not who happens to manage the DNS. A domain registered in your provider's name is your provider's asset, legally, however long you have been paying for it.
- Your licences. Microsoft licences bought through a provider's CSP agreement usually carry a twelve-month term commitment. That term does not vanish because you changed provider, and it is the single most common reason a switch has to be timed rather than simply actioned.
- Your backups. Find out where they physically live. If your backups sit inside your provider's tenant or their backup platform, under their licence, then your recovery capability leaves when they do.
- Your documentation. Ask to see it today. Not a promise that it exists, the actual thing. Most provider documentation lives in their own system, and what you are entitled to on exit is frequently an export nobody has ever tested.
None of these are exotic. All five are worth an afternoon before you make any decision at all, because the answers change what leaving costs and when you can do it.
Read the agreement before you say a word
People tend to give notice emotionally, in the week after a bad incident, and then discover the terms afterwards. Reverse that order.
- Notice period and renewal date. Many agreements roll over automatically, and a notice period that sounds short can still trap you for another full term if you miss the window by a fortnight.
- Offboarding and exit fees. Some agreements charge for the handover itself, sometimes at an hourly rate with no cap. Find the number before it becomes a surprise.
- What they owe you on exit. Look for an explicit clause on returning data, documentation and credentials. If there isn't one, that is worth knowing now rather than during the handover.
- Anything with a term attached. Licences, hardware on a payment plan, connectivity, telephony. These often outlive the managed services agreement and need to be dealt with separately.
The handover pack: what to ask for, in writing
When you do give notice, ask for all of it at once and in writing. A piecemeal request invites a piecemeal response spread over six weeks.
- Global administrator credentials for your Microsoft 365 or Google tenant, and confirmation of the tenant ID
- Registrar access for your domain, plus a full export of the current DNS zone before anything changes
- A complete asset register: every server, endpoint, firewall, switch, access point and printer, with serial numbers and warranty status
- Network documentation: IP ranges, VLANs, VPN configuration, firewall rules, and the reasoning behind any of it that isn't obvious
- Administrator credentials for every line-of-business application, not just the Microsoft stack
- Licence inventory showing what you hold, under whose agreement, and when each term expires
- Backup configuration and, critically, evidence of a successful restore test
- Any outstanding tickets, known issues and deferred work, so nothing lands on the new provider as a surprise in week two
- Vendor and supplier contacts, including who holds the account relationship with each
A provider who hands this over in a fortnight without friction was probably a reasonable provider who was simply not the right fit any more. A provider who cannot produce an asset register at all has just explained the last three years to you.
Where it actually goes wrong
In our experience the trouble is almost never the technical migration. It is one of these.
- The tenant was never yours. Recovering a Microsoft 365 tenant from an uncooperative provider is possible, but it is a formal process with Microsoft and it takes weeks you did not budget for.
- The domain is registered to them. Same problem, different vendor, and it holds your email hostage rather than your files.
- Security tooling leaves with the provider. The RMM agent, the antivirus or EDR, the email filtering and the monitoring are usually licensed to the provider, not to you. On the day they disconnect, those protections stop. This needs to be a planned cutover, not a gap.
- Nobody tested a restore. Backups that have never been restored from are an assumption, and a transition is a poor moment to discover that.
- One person knew everything and they are not at the new provider. Undocumented knowledge is the real handover risk, which is the same reason key person risk matters inside your own business.
How the timing usually works
For a typical small or medium business, budget thirty to sixty days from decision to fully transitioned, and expect the calendar to be driven by contract dates rather than technical work.
- Weeks one and two. The new provider audits your environment and documents what is actually there, which is frequently not what anyone believed was there.
- Week three. Notice is given, the handover pack is requested, and the cutover date for monitoring and security tooling is locked in.
- Weeks four and five. New agents deploy alongside the old ones, documentation is rebuilt, and the new help desk starts taking tickets in parallel.
- Week six. Old tooling is removed, credentials are rotated, and the outgoing provider's access is revoked deliberately rather than whenever someone remembers.
That last step gets skipped more often than it should. Revoking a former provider's administrative access is a security task with a date on it, not an administrative afterthought.
Your staff should barely notice
A handover done properly is invisible to everyone except the person coordinating it. Email keeps working, files stay where they were, and the only visible change is who answers the phone and how quickly. If a provider tells you the transition will be disruptive for your team, ask them specifically what will break and when. Vagueness there is usually a sign they are planning to do it the hard way.
The risk in switching providers is ownership, not migration.
Check who holds your tenant, your domain, your licences and your backups before you give notice. If the answer is you, the handover is administrative. If the answer is your provider, that is the problem to solve first, and it is a reason to start sooner rather than later.
We onboard businesses off other providers for free, and we put a ninety-day walk-away guarantee behind it, because the transition is the part people are actually afraid of and we would rather carry that risk than ask you to. If you want a second opinion on what you own before you decide anything, see switching IT providers, or book a 30-minute call. If you have not got as far as a shortlist, how to choose a managed IT provider is the better place to start.