Switching MSPs without downtime: a no-drama transition playbook.
The right way to switch managed IT providers when the current one isn't working. Done well, it's a two-week project with zero disruption. Done badly, it's a three-month nightmare.
Rishi · Founder · Tech & Strategy, Terranotics Tech Solutions
Published April 15, 2026 · Reviewed quarterly
Most businesses don't fire their MSP. They drift away from one slowly, then one day make the call to switch. The switch itself doesn't have to be dramatic — but a lot of businesses make it harder than it needs to be by treating it like a normal procurement. It isn't.
Why MSP transitions go badly.
1. The outgoing MSP is also the gatekeeper to the systems. They have the admin passwords, the documentation (or lack of it), and the institutional knowledge.
2. There's no contractual offboarding obligation in most MSP agreements. The outgoing provider can stretch out the handover or quietly skip steps.
3. The incoming MSP can't fully assess the environment until they're in — at which point they often find issues the outgoing MSP didn't disclose.
4. Nobody has owned the documentation, so the new team has to rebuild it from scratch.
The two-week playbook.
*Week minus-two:* Notify the outgoing provider in writing, with a cutover date. Ask for an offboarding checklist (most contracts require one). Confirm what data and credentials they'll hand over and in what format. Quiet check: do they own any domains, certificates, or DNS records that need transferring? Often yes, often forgotten.
*Week minus-one:* Incoming MSP does a discovery audit. Inventory of every device, account, subscription, license, and integration. The outgoing MSP's documentation rarely matches reality — assume nothing.
*Cutover week:* On the Monday, the incoming MSP gets admin access to everything (M365, RMM agents, firewalls, DNS, monitoring tools). They run their own onboarding scripts — agents redeployed, monitoring re-pointed, backup credentials rotated. By Wednesday, both MSPs have access. By Friday, the outgoing MSP's access is revoked.
*Week plus-one:* New monitoring stabilises, alerts get tuned, helpdesk transition for staff. Issues found in discovery get resolved.
*Week plus-two:* First weekly review. By now the new MSP has a clear picture of the environment and can give the business owner a real assessment.
The handover checklist (steal this).
- M365 / Google Workspace global admin credentials (transferred via password manager, not email) - Domain registrar logins (with auth codes if needed) - DNS provider access (Cloudflare, Route53, registrar's own) - Firewall + network device admin credentials - Backup system access + restore documentation - All RMM / monitoring tool logins - License inventory (M365 SKUs, anti-virus seats, specialty software) - Documentation of any custom scripts, automations, or scheduled tasks - Asset inventory (devices, serial numbers, warranties) - Network diagram and IP plan - Any vendor contracts the outgoing MSP was managing on the business's behalf
What we tell businesses before they call the outgoing MSP.
Don't burn the bridge. Even an MSP you're firing has institutional knowledge you need for two weeks. Pay the final invoice cleanly. Sign whatever termination paperwork they ask for. The goodwill costs nothing and the handover quality matters more than the principle.
And if the outgoing MSP becomes obstructive — refusing to hand over passwords, dragging out the offboarding, claiming they own data they don't — escalate quickly. Most contracts have offboarding clauses. Most of those clauses are stronger than the outgoing MSP thinks. We've taken over engagements where the outgoing party was fully cooperative and engagements where they weren't. The latter cost more but they're not insurmountable.
The right MSP transition takes two weeks and zero downtime. If it's stretching to three months and lighting fires, something is wrong on one side or both.