Switching MSPs without downtime: a 90-day transition playbook.

The reason most businesses stay too long with a bad MSP is not loyalty, contract length, or sunk cost. It's fear of the switch. Specifically: fear that the outgoing provider will turn off the agents, lock the documentation in their PSA, and leave a smoking crater for the new provider to walk into on day one.

That fear is rational. We've inherited environments that looked exactly like that — credentials we couldn't recover, RMM agents we couldn't uninstall without local admin we didn't have, backup tenants in a previous MSP's name. Every one of those problems was preventable with a different sequencing of the transition. This is the playbook for doing it the way that doesn't break.

The structure: nine sequenced phases over roughly 90 days. The order matters more than the dates — some clients run the full plan in six weeks; complex enterprises take six months. What does not change is the sequence, because each step depends on the one before it.

1Decide before you tell anyone.

The single biggest mistake we see clients make is telling the outgoing MSP about the change before the new MSP is contracted and the transition plan is locked. The moment your incumbent finds out, three things happen: the senior engineers stop returning calls, documentation requests get "queued," and any quoted projects suddenly require deposits. None of this is malicious in every case — it's economic gravity. They've reallocated their attention.

Do this instead: sign the new MSP, agree on a start date, and have the transition runbook in writing before you say a word to the incumbent. From the moment you give notice to the moment you cut over, the outgoing MSP is on a known finite engagement. Make it as short as possible.

2Inventory what you actually own — before you ask for it.

Before the new MSP starts and before you give notice, do a walkthrough of every system, account, and license your business depends on, and answer one question for each: who is the legal owner of record? Not who manages it. Who owns it.

The honest list usually surfaces some surprises:

• Microsoft 365 / Google Workspace tenant. Look at the billing relationship — is the tenant under a CSP partnership where the MSP is the partner of record? If so, you can transition the partner relationship, but you need a written plan for it.
• Domain registrar. A surprising number of small businesses don't know which registrar holds their primary domain. Find it. Make sure your name and email are on the account.
• DNS hosting. Often different from the registrar. Cloudflare, Route 53, registrar default — knowing which one you're on dictates the cutover plan for email and web.
• SSL/TLS certs. Auto-renewing through the MSP's account? You need that account or a parallel cert before they leave.
• Backups. Are backups stored in your cloud account, or in the MSP's tenant? If the latter, those backups end when the contract does. Plan for at minimum a 30-day overlap or a forklift to your own storage.
• EDR / RMM / PSA tooling. The agents on your endpoints belong to the MSP's tenant — at the end of the contract, those licenses go away.
• Documentation. IT Glue, Hudu, Confluence — wherever your runbooks, network diagrams, and credentials live. Often the MSP's tenant. (We have a stronger position on this — see question 10 of our MSP evaluation guide.)

The rule of thumb: anything billed to the MSP is leaving with the MSP unless you've explicitly moved it. Don't assume.

3Run both MSPs in parallel for 30 days.

The cleanest transitions overlap. You pay both providers for one month. The incoming MSP is doing discovery, deploying their own monitoring, and writing the playbook. The outgoing MSP is still on the hook for tickets and incidents because their contract hasn't ended.

This is the inverse of how most MSP transitions actually run, which is: contract ends Friday, new contract starts Monday, and nobody owns the gap. That gap is where production downtime lives. Spend the extra month of overlap fees — it's the cheapest insurance in the entire engagement.

What the incoming MSP should be doing during the overlap: documenting every server, every network device, every SaaS tenant; identifying gaps and risks; preparing migration scripts; deploying their RMM agents alongside (not replacing) the outgoing ones; setting up their own monitoring stack so they have baseline data before they're responsible.

4Take back identity before anything else.

This is the single most important step and the one most transitions skip. Identity — your Microsoft 365 / Google Workspace tenant, your global admin accounts, your conditional access policies, your privileged identity management — is the keys to the kingdom. Until you control identity, you don't control the environment.

Concretely:

• Add at least two new global admin accounts owned by your business — a real human (executive or designated IT lead) and a break-glass account with a randomly generated long password stored in a sealed envelope or vault.
• If a CSP partner-of-record relationship exists, transition it to the new MSP or remove it. Microsoft requires explicit customer consent for partner relationships — your incumbent can't block this if you exercise it.
• Audit existing admin accounts. Anyone from the outgoing MSP who has admin should be tagged for removal at cutover. Document them now; remove them later.
• Verify MFA on every admin account, both old and new. This is when you'll find the legacy account that the outgoing MSP exempted "because the script breaks otherwise."

Once you have your own admin accounts with MFA and you've verified the break-glass account works, you've crossed the threshold where the incumbent can no longer hold the environment hostage. Everything after this gets easier.

5Swap the agents quietly.

RMM agents, EDR agents, patch management agents, monitoring agents — every endpoint has a layer of MSP-controlled software. Replacing it is a careful sequence.

Run new and old in parallel for at least two weeks. Yes, two EDRs will compete for hooks. With modern EDRs (CrowdStrike, SentinelOne, Defender for Business), you can configure exclusions so they coexist. The new MSP should know how to set this up — it's standard practice for transitions.

Validate the new agents are reporting clean telemetry, then schedule the uninstall of the old ones. Critical: get the uninstall keys / passwords for the outgoing tooling before the contract ends. Many EDR and RMM platforms require an admin password to uninstall — without it, you're either calling the outgoing MSP back for favors (good luck) or wiping the endpoint and rebuilding it.

If the outgoing MSP refuses to provide uninstall credentials, document the refusal in writing. Then either escalate via their contractual obligations or budget for endpoint rebuilds. Don't let this be the surprise on day 91.

6Backups first, then DNS, then email — in that order.

The cutover sequence within the parallel-run period matters. Cut over services in order of risk: backups before everything else, then control-plane infrastructure (DNS, identity, certs), then user-facing services (email routing, file storage).

Backups first. If the outgoing MSP's backup tenant goes dark and something corrupts the next day, you've lost everything. The new MSP should establish independent, validated backups before any cutover. Validate by performing an actual restore — not by reading a green checkmark on a dashboard. The number of MSP relationships where backups appeared healthy but had silently failed for months is not small.

DNS and identity next. If your DNS or identity is held in the outgoing MSP's account, migrate them to accounts you own. DNS migrations have a window of risk equal to the TTL of the records, so lower TTLs to 300 seconds a week before the move.

Email and user-facing services last. By this point you've established control. Email routing changes are visible to every employee and customer; do them when everything else is stable.

7Tell users on your terms, not the outgoing MSP's.

Your employees should hear about the MSP change from you, with framing you control, before the outgoing MSP gets a chance to tell their version. They don't need details. They need to know: we're changing IT providers, the transition will be invisible to your daily work, here's the new helpdesk address and phone number, the change is effective this date, here's who to contact with questions.

A simple internal memo with the three-bullet version (who, when, how to ask for help) prevents the most common transition friction: employees getting two different answers from two different helpdesks for three weeks and losing confidence in IT entirely.

Schedule the cutover for a Friday afternoon if it's customer-facing, or a Tuesday morning if it's internal. Avoid Mondays (everyone's catching up on weekend tickets) and avoid the last week of the month (everyone's running close-out reports and any IT problem becomes an emergency).

8Run the formal handoff meeting — and document it.

On the last day of the outgoing contract, hold a structured handoff meeting with both MSPs in the same call. The agenda is mechanical:

• Confirm all credentials have been transferred and verified working in the new MSP's documentation system.
• Confirm all admin accounts owned by the outgoing MSP have been disabled or removed.
• Confirm all monitoring, RMM, and EDR agents from the outgoing MSP have been uninstalled or are queued for uninstall.
• Confirm any open tickets are either closed or formally transferred with full context.
• Confirm the outgoing MSP has no remaining VPN, jump-host, or remote-access pathways into the environment.
• Confirm the outgoing MSP has deleted (or returned and deleted) any client-data exports they hold.

Send a written summary of the handoff to both MSPs the same day. If something goes wrong in week 2, this document determines who's responsible. You'd be amazed how many handoffs happen on a vague "yeah, we're all good" call with no written record.

9The 90-day watch.

The transition isn't done at cutover. It's done at the 90-day mark, when the new MSP has produced their first business review with real data and you've run through one of every recurring IT event: monthly patching, a quarter-close support spike, at least one minor incident, the first invoice.

What to track during the 90 days:

• Surprise tickets. Anything the new MSP discovers that wasn't in the original documentation. Each one is a documentation gap that needs filling.
• Latent dependencies. Scheduled tasks, scripts, integrations, certificate renewals that depended on the outgoing MSP's tooling. These tend to surface 30–90 days after cutover.
• Account access drift. Old vendor accounts, service accounts, and integration accounts that the outgoing MSP set up. Audit these quarterly going forward.
• Performance against the new SLA. The new MSP is on probation. The 90-day business review is where they prove the change was worth it.

What to do if the outgoing MSP is being difficult.

Most outgoing providers are professional. They've lost the contract, they'd rather not, but they understand it's part of the business and they hand over cleanly. A minority are the opposite — they delay credential transfers, fabricate "security reviews" for routine handoffs, or quietly hold onto admin access "in case you need us again."

If you hit one of those:

• Put every request in writing. Email, not phone. You want a paper trail.
• Re-read your contract. Most MSP MSAs have transition-assistance language. Cite it.
• Use the leverage that's still in your control. Final invoice, glowing reference, referral pipeline — these are the only things left that the outgoing MSP cares about.
• Don't get into a fight you don't need to win. If something is irrecoverable (a credential they refuse to release, a system they have ongoing access to), pivot to making it irrelevant — reset, rotate, rebuild. Time spent in conflict with the old MSP is time the new MSP isn't spending on you.

And in the rare case where the outgoing MSP is actively obstructive — refusing handover, retaining access, threatening data deletion — that's a legal matter, not a technical one. Get counsel involved, document everything, preserve communications. The behavior is uncommon but it does happen, and the time to involve a lawyer is the moment you see it, not after the data is gone.

The boring middle.

Most transitions feel anticlimactic when they're done well. There's no drama, no outage, no all-hands incident. The new MSP just shows up Monday and the helpdesk number is different. That's the goal. The drama lives in the transitions that weren't planned — and almost all of that drama is avoidable.

If you're at a point where you've decided to switch, our offer is straightforward: a 20-minute call to walk through your specific environment and tell you whether your transition is going to be easy or hard, regardless of whether you end up hiring us for it. Book the call and we'll be honest about what we see.