Switching MSPs Without the Downtime Drama

Most owners we meet who want to switch MSPs are afraid of one thing: that the day they fire their current provider, the email stops, the files get held hostage, and the phones go dark for a week. That fear keeps a lot of small businesses stuck with a vendor they outgrew or got rolled up into a PE portfolio they never signed up for.

The fear is reasonable. Bad handoffs do happen. But a clean one is not complicated. It is mostly checklist work, and the timeline is around 30 days from “we are switching” to “the old vendor is off our systems.”

Here is how we run it when a business hires us and we have to extract them from someone else.

Week one: inventory before announcement

Before anyone tells the old MSP they are being fired, we do a walkthrough and write down everything that depends on them. That list usually includes:

• Microsoft 365 or Google Workspace tenant ownership.
• Domain registrar login and DNS hosting.
• Firewall and switch admin credentials.
• Backup software console and the actual backup destination.
• RMM agent, antivirus console, password manager, MFA portal.
• Any SaaS where the MSP is listed as a billing or admin contact (Adobe, line-of-business apps, etc.).
• Documentation: network diagrams, password vaults, vendor contacts.
• The phone system, the alarm panel, the cameras.

The point of doing this before notice is so we know what we need to pull back and from where. If the relationship goes sour on day two of the transition, we want every key dependency identified.

Week two: notice and the 30-day overlap

Most MSP contracts have a 30-day or 60-day notice clause. When the owner gives notice, the clock starts and the old vendor is contractually obligated to cooperate during the transition window. Most of them do. Some do not. We assume cooperation and prepare for the version where it does not happen.

During this window we want three things to start moving:

Credential transfer. The new MSP (us) gets temporary admin access to every system listed in week one. We do not remove the old MSP’s access yet. Both teams have keys.

Documentation request. Network diagrams, password export, vendor contact list, runbooks. Some old vendors hand this over the day notice goes in. Some take three weeks. We start asking the day notice is sent.

Tenant ownership audit. This is the big one. If the M365 tenant or domain registrar is owned by the old MSP under their billing account, we have to migrate it before we can take over. That migration takes anywhere from one day (DNS NS change at registrar) to two weeks (M365 partner-of-record transfer through the Microsoft portal). Start it on day one of notice.

Week three: parallel operations

By week three we have our own monitoring agents on every endpoint, our own backup running alongside theirs, and our own ticketing system live. The customer keeps using both ticket systems if they want. We are watching every machine through our RMM and seeing what the existing tools see. If something breaks during this window, we can fix it without needing the old vendor.

Your team should not feel a thing. Their VPN still works. Their printers still print. Their email still flows. The only visible change is that when they call for help, they reach us now instead of the old desk.

Week four: cutover and old-vendor offboard

This is the only week where there is real risk, and we manage it on a Friday-evening or weekend window. The work:

1. Update DNS, MX, SPF, DKIM, DMARC to point at the new mail flow.
2. Remove the old MSP’s global admin accounts from M365.
3. Decommission the old backup agent (after confirming the new one has a full restore-tested snapshot).
4. Remove the old RMM, antivirus, and remote tools from every endpoint.
5. Rotate every shared credential the old vendor had access to. All of them. Domain admin, switch passwords, firewall, M365, line-of-business app admins. New passwords stored in our shared vault, accessible to your team.
6. Take a final snapshot of the network configuration and file it.

When Monday comes the staff sees no visible difference. Their accounts work. Their files open. Their meetings happen. The phone tree still routes. The only change is whose name is on the support number taped to the printer.

What can actually go wrong

The two failure modes we plan for:

Tenant lockout. The old MSP is the only global admin on M365 and refuses to add ours. This is a Microsoft partnership escalation, takes 5-10 business days, and is sometimes the entire reason the customer is leaving. We have a templated escalation we file the same day we discover it.

Backup hostage. The old MSP runs the backup on hardware they own. They will give it back, but only after final invoice clears. We assume this and start a new backup running concurrently from week one so we never depend on theirs.

Both are solvable. Neither requires the business to feel pain.

What to ask before you sign with the next one

If you are about to switch MSPs, three questions to ask the next vendor before you commit:

1. “Who owns the M365 tenant after we sign? Us or you?” The right answer is you. Always.
2. “Where does the backup live and who has the keys?” The right answer is in your name on a system you can audit.
3. “If we leave you in two years, what does that handoff look like?” If they cannot answer in a sentence, that is the problem.

The free way to start

If you are stuck behind an MSP that stopped picking up the phone or got bought out, we can walk you through what a clean transition would look like on your specific stack. The free IT Blueprint Assessment is the easiest entry point. We come walk your office, look at every system, and leave you with a one-page punch list. No follow-up sales calls unless you ask.