How to switch managed IT provider without breaking anything

Most businesses change MSP once every 5–7 years, and most of them only do it because something has gone properly wrong with the current arrangement. So they're nervous, they're a bit annoyed, and they've usually been told by their outgoing provider that switching is "very disruptive." It doesn't need to be.

Here's the 90-day plan we use, with the bits that genuinely matter and the bits that don't.

Days 1–7: get clear on what you actually have

Before you give notice, before you sign anything new, get an honest picture of your current state. Ask your incumbent MSP — politely, on the record — for:

• An asset register: every device, every server, every cloud service
• The list of admin accounts they hold and what each one is for
• The list of third-party software licences and where they're registered
• Last quarter's monthly reports
• The current backup configuration and last test-restore date
• A copy of your current contract

If they push back or stall, that tells you something important. A confident MSP keeps clean documentation and shares it without drama.

Days 8–14: confirm you own the critical assets

This is the single most important step in the whole process, and most businesses skip it.

Asset	Should be owned by	How to verify
Microsoft 365 tenant	Your business	Sign-up email and primary admin should be a named person at your company, not the MSP
Your domain (e.g. yourcompany.co.uk)	Your business	Check WHOIS — registrant should be your business, not the MSP
DNS hosting	Either, but you must have access	You should be able to log in and see records
Backup repositories	Your business	Veeam Cloud Connect or M365 backup should be in your name with admin credentials available
Microsoft Partner relationships	Held by MSP, but transferable	You can revoke a Microsoft CSP relationship at any time

If any of these are wrong — particularly the M365 tenant or the domain — you have a problem to sort before the switch, not during it. That's the hostage situation we want to avoid.

Days 15–30: choose your new MSP properly

I won't repeat the whole "five questions to ask before signing any MSP quote" piece here, but the short version: get at least three quotes, normalise the inclusions, ask for the exclusions list, ask to speak to a recent client. Don't just rebound to whoever responded fastest after a bad week.

When you've picked your new MSP, give your current MSP written notice. Most contracts require 30–90 days; assume the longer end. Be professional — they may still be fixing things for you for the next two months.

Days 31–60: the actual handover

Your new MSP runs the discovery and handover process. A competent one will:

• Audit your environment. Map every device, every cloud service, every account, every quirky configuration. This is what you should get a copy of, in plain English.
• Identify gaps. What's missing from current provision? What's misconfigured? What's a fire risk? You want this in writing — it's your baseline for the new relationship.
• Plan the cutover. Which weekend, which order, who's the contact for what. The cutover plan should fit on one page and be reviewed by you.
• Take over the tooling. RMM agents installed alongside the existing ones (or replacing them on cutover weekend). EDR deployed. Backup repositories repointed. M365 admin transferred. Documentation imported into their system.
• Brief the team. Users need to know — new helpdesk number, new portal, what's changing and what isn't. Two emails and a 15-minute Teams session is usually enough.

A good handover feels boring. There are no fireworks. Things just quietly transfer.

Cutover weekend

The actual cutover is usually a single weekend, often a Saturday morning. The new MSP:

• Removes the outgoing MSP's RMM agents
• Confirms their own RMM, EDR and backup are running cleanly across the fleet
• Updates the M365 tenant's CSP partner relationship
• Updates DNS records that need to change (rare — usually nothing user-facing changes)
• Confirms support contact details are in place
• Runs a smoke test: a sample user logs in, opens email, accesses a file, prints something

By Monday morning, users come in to a working system. The only difference they should notice is the new IT support number on the staff intranet.

Days 61–90: stabilisation

The first 30 days post-cutover are when you find the things nobody documented. The CRM that integrates with email via a service account nobody knew about. The shared printer that authenticated against an old AD account. The automation script that runs on the receptionist's PC every Monday morning.

None of these are catastrophic — but they need to be found and fixed proactively. A good MSP will spend the first 30 days actively looking for these rather than waiting for them to surface as user complaints.

You should also have a 30-day review with the new MSP — what's gone well, what hasn't, what they've discovered, what you want to change. This sets the tone for the relationship for the next several years.

What can go wrong (and how to prevent it)

The outgoing MSP drags their feet on documentation

Common. Build into your notice letter a request for full documentation handover within 14 days, with a list of specifics. Most MSPs will comply — the alternative is professional reputation damage.

"We've discovered something the previous MSP didn't tell you about"

Almost guaranteed. Old shadow IT, lapsed certificates, undocumented servers. Treat this as expected, not as a crisis. The new MSP should triage and prioritise.

Users complain because "the old way was better"

Usually because the old way is what they were used to, not because it was actually better. Give it 30 days before changing anything optional. Then make changes deliberately with clear comms.

Something breaks at month-end

Don't switch MSP across month-end if you can avoid it. Don't switch during tax season if you're an accountancy. Don't switch the week before audit if you're regulated. Pick the quietest fortnight in your year and do it then.

The honest disclaimer

We've moved a lot of clients onto our service from other MSPs. Some moves were textbook. A few were bumpy in the first week. None of them resulted in data loss or significant downtime — because the planning is what prevents that, not the heroics.

If you're seriously considering a switch and you'd like a confidential conversation about whether it's worth doing — drop us a note. We'll happily tell you if your current arrangement is salvageable, even if it means we don't win your business.