Why switching feels risky (and why it usually isn't)
The risk is never really about the technology. It is about the unknowns: a network nobody documented, passwords that live in one engineer's head, a domain registered in the provider's name rather than yours. When the relationship is good, none of that matters; when it frays, those unknowns become leverage. A structured handover turns the unknowns into a list, and a list is something a competent new provider can work through.
In practice, the mechanics of a switch are straightforward. Monitoring moves across, security tooling is re-pointed, the helpdesk number changes, and the new provider picks up the same hardware and the same tenancy. What makes it feel risky is the gap between noticing a problem and being able to fix it — and that gap is exactly what a good onboarding closes.
What to audit before you give notice
This is the single most useful thing you can do, and most businesses only do it after they have already given notice, which is the wrong order. You want to know, while everything is still cordial, who holds each critical piece of access. Print the list, screenshot the consoles, and keep it somewhere you control.
Domain ownership and registrar access. Your domain name is the front door to your email, your website and your Microsoft 365 tenancy. If it is registered in the provider's account, you do not own it — they do. Check the registrar, confirm the registrant contact is yours, and make sure you hold the login. Transferring a domain out of a reluctant provider is possible but slow; doing it while the relationship is still warm is trivial.
Microsoft 365 global admin. There should be at least two global admin accounts you control, with MFA, that are not the provider's break-glass account. If the only global admin belongs to the MSP, a billing dispute can lock you out of your own email overnight. Add your own, verify it works, and then talk about switching.
Line-of-business application admin. Accounts software, practice management, CRM, the warehouse system — each has an administrator account. Find them, confirm the password is known, and check whether the vendor's support contract is in your name or the provider's. The provider's is fine for day-to-day; it is not fine if it is your only route to the vendor.
Firewall and switch admin. A managed firewall is often registered to the provider's cloud management organisation (Nebula, Meraki, Sophos Central). If it is, you want the device released or re-onboarded to an organisation you own before the switch, not after. Otherwise the new provider cannot manage it without a factory reset.
Backup access and encryption keys. Backups are the one thing you cannot afford to lose access to during a handover. Confirm where they live, that the console is accessible, and — critically — that the encryption key or passphrase is held by you, not solely by the outgoing provider. A backup you cannot decrypt is not a backup.
DNS records and MFA enrolment. DNS controls where your mail and web traffic go. Export the full zone record before anything changes. Similarly, confirm your users' MFA is enrolled against your tenant and that conditional access policies are documented, so a switch does not silently lock half the team out on a Monday morning.
What a proper handover pack contains
A handover pack is not a polite gesture; it is the document that lets a new provider support you from day one without rediscovering everything. If your current provider cannot produce one, that itself tells you something. At a minimum it should contain the following.
An asset and inventory list. Every server, workstation, laptop, switch, access point and firewall, with model, spec, serial, warranty status and assigned user. It does not need to be pretty; it needs to be complete.
A network diagram. Internet line, firewall, switches, VLANs, Wi-Fi, VPN — enough that an engineer can visualise the topology without walking the building. Include IP ranges, guest networks and any third-party links.
A password vault export. The admin credentials for every system above, in a format a new provider can import into their own vault. If this does not exist, the handover will take weeks longer than it should.
Licence ownership. Which Microsoft 365 licences are yours, which are resold through the provider, and which third-party tools (anti-virus, backup, DNS filtering) are under whose billing. You want to know what moves with you and what you have to repurchase.
Support contracts and known issues. Outstanding projects, recurring gremlins, kit that is on its last legs, the line-of-business app that only the old finance director understood. This is the institutional knowledge that makes the difference between a smooth onboarding and a month of surprises.
The access an outgoing provider sometimes quietly holds
There are four or five pieces of access that, in our experience, providers hold onto — sometimes innocently, sometimes less so. None of them are difficult to take back, provided you do it before you give notice rather than after.
The domain, registered in their name. The most common and the most awkward. A registrar transfer takes a few days and requires the current provider to unlock the domain and provide an auth code. Ask for both, in writing, while the relationship is still friendly.
The tenant global admin. If the only global admin is an MSP mailbox, add your own first, then request the MSP account be converted to a standard delegated admin after the switch. Never leave a single external account as your only admin.
Billing-owned licences. Microsoft 365 licences billed through a partner can be moved to direct billing, but it is a partner-initiated process. Request the move early; it can take a billing cycle to land cleanly.
The firewall's cloud organisation. A Zyxel under the provider's Nebula org, or a Sophos under their Central, cannot be managed by a new provider until it is released. Request the release, or have the new provider re-onboard it, before the old contract ends.
How we run an onboarding
Our handover is deliberately boring, because boring is safe. We inherit the handover pack, audit the environment against it in the first week, and fix the gaps quietly before anything is visible to your users. We agree response targets with you in writing, migrate monitoring and security tooling across, and — wherever possible — parallel-run for a short period so there is no gap in cover between the old contract ending and ours beginning.
The first thing we secure is always the backup, because it is the one thing you cannot recover from during a transition. After that, the order is: confirm admin access to everything, verify monitoring is reporting, and only then change the helpdesk number your team calls. By the time your users notice anything, the engineering underneath is already done.
The honest caveat
A genuinely obstructive outgoing provider is rare, but it happens. In that case there are legal routes — the domain is yours by right if you can evidence it, and Microsoft has a process for recovering a tenant you own. We have walked clients through both. But the overwhelming majority of switches are straightforward, because most providers would rather leave cleanly than argue.
We also hold ourselves to the same standard when we eventually hand over. A client should be able to leave us with a full pack, their own keys, and no bad feeling — because the reason they stay is the service, not a lock-in.