How to fire your MSP without breaking everything: the 30-day switch playbook

The 5-minute answer

Yes, you can switch MSPs without losing data, breaking your stack, or making your team's life miserable for a month — but only if you treat it as a 30-day project with named owners, a credentials inventory, and a parallel-run period. The firms that get burned are almost always the ones that fired their MSP in a panic, on a Friday, with no transition plan and no idea where their backups, domain registration, or Microsoft 365 admin credentials actually lived. The firms that switch cleanly do it deliberately, with a 30-day overlap, and end up better off than they were before.

This article is the playbook. We will cover the three reasons people stall on switching (and the rebuttal to each), the seven questions to vet your next MSP, the week-by-week switch plan, the asset and credentials handover checklist, and what to do if your current MSP goes silent or hostile when you give notice. About 90% of MSP buyers cite response time as their #1 selection criterion — so we will spend most of our time on the operational reality of how a clean switch actually works, not on selling you on the abstract idea.

Score your current MSP → (5-min, no form gate)

Three reasons people stall — and the rebuttal to each

Most firms know they should switch six to twelve months before they actually do. Three reasons account for almost all of the delay.

Reason 1: "Switching feels like it'll break everything." The fear is rational. Your current MSP probably owns or controls some combination of your domain registrar, your Microsoft 365 tenant, your email DNS records, your firewall configuration, your backup vendor relationship, your antivirus or EDR licenses, and possibly your VPN. Switching seems to require touching all of those simultaneously while keeping the business running.

The rebuttal: a clean switch doesn't move everything at once. It runs the new MSP in parallel with the old one for 14 to 21 days, transfers ownership of credentials and accounts before any production cutover, and tests every critical service in a staging context before flipping it. The pattern is well-known and the new MSP should run it without you babysitting. Switches break when they're rushed; they don't break when they're planned.

Reason 2: "We just don't have time to evaluate alternatives." This is usually code for "we don't know what to evaluate." If you don't have a framework, every MSP sales call sounds the same and you can't tell which provider is competent.

The rebuttal: a 5-minute Cyber Scorecard plus a focused 30-minute discovery call replaces three or four hours of sales-call evaluation. The seven questions later in this article cut through the marketing surface and tell you which providers are actually capable.

Reason 3: "Our current MSP isn't great, but they know our stack." The implication is that institutional knowledge is irreplaceable. It usually isn't — most MSPs document very little of what they "know" about a client, and the documentation that does exist is in their PSA tool, not in your hands. The institutional knowledge story sometimes covers a more uncomfortable truth: nobody on your team actually knows where things live, and the current MSP is the only thread holding the stack together.

The rebuttal: this is the strongest reason to switch, not the strongest reason to stay. A vendor who is the only person who can run your stack is a vendor who can hold you hostage. A clean switch produces, as a side-effect, your first complete inventory of what you actually have — credentials, vendors, contracts, configurations. That inventory is independently valuable.

The 7-question evaluation framework

Use these in your first call with any candidate MSP. Treat vague answers as red flags. Effective MSPs answer all seven concretely; ineffective MSPs hedge.

1. What is your average ticket response time over the last 90 days, by priority? The right answer is a specific number per priority tier, with documented evidence. "We respond fast" is the wrong answer. 90% of MSP buyers cite response time as the #1 selection criterion — every competent MSP measures it. If they don't, they don't.

2. Who is the named human who would own our security? Not "our team." Not "our SOC." A name. A title. A scope. If the answer is a generic role rather than a specific person, you are buying a ticket queue, not a managed practice.

3. What compliance frameworks have you delivered in the last 12 months, and over what timeline? For Evolv's market, the relevant frameworks are HIPAA, NAIC Model Law MDL-668 (insurance WISP), IRS Pub 4557 (CPA firms), CMMC Levels 1 and 2 (DoD contractors), and SOC 2 readiness. The right MSP can name their delivery cadence per framework. The wrong one says "we cover compliance" and changes the subject.

4. What's your monthly reporting cadence and what's in it? The right answer is a specific deliverable on a specific date — for example, "a board-ready security posture report on the 5th business day of each month, covering open findings, controls status, incidents, and quarterly tabletop results." Vague monthly reports are not reports.

5. How do you handle a P1 incident at 2 AM on a holiday? The right answer names the on-call rotation, the named incident commander role, the stand-up time SLA, and the escalation path to your firm's leadership. "We're 24/7" is not an answer; it is a marketing claim.

6. What's your client tenure rate over the last three years? Long tenure is a signal. Short tenure with a story ("we cleaned up our book") may also be a signal in the right direction. High churn with no story is a red flag.

7. What does the offboarding process look like if we leave? Ask this BEFORE you sign. The answer reveals more than any other question. A confident MSP describes a documented offboarding process — credentials handover, asset inventory, transition support hours, written runbooks. An MSP that hesitates or makes the offboarding sound punitive is signaling how the relationship will end.

The 30-day switch playbook

Day-by-day for the firms who like calendars; week-by-week for the firms who don't. Either way, the milestones are the same.

Week 1: Inventory and parallel-run setup. The new MSP runs a full inventory of your environment. They produce a written list of: domain registrar and DNS provider; Microsoft 365 / Google Workspace tenant ownership; email security, EDR, antivirus, backup, and firewall vendors with license counts and renewal dates; VPN and remote-access infrastructure; admin credentials currently held by the outgoing MSP; production-critical software vendors and contracts. You are not changing anything in week 1. You are documenting reality. By the end of the week, you have an asset inventory that didn't exist before, regardless of whether you switch. The new MSP also stands up parallel monitoring — read-only access to your environment, no production changes — so they can baseline your stack before they own it.

Week 2: Credentials handover and admin access. You give written notice to your current MSP. The notice is professional and specific: it states the effective date, requests a credentials handover by a specific date, and asks for a transition-support agreement (most MSPs honor a 14- to 30-day handover; some don't — see "what to do if your current MSP goes silent" below). Your new MSP receives admin access to the production environment in parallel with the old MSP. Two MSPs have admin access for the next 7 to 14 days. This is intentional. Production changes still flow through the old MSP; the new one watches.

Week 3: First production cutovers. The new MSP takes over the lowest-risk production responsibilities first: monitoring, ticketing, help desk. Your team starts opening tickets with the new MSP. The old MSP keeps emergency on-call for 7 more days as a safety net. By the middle of week 3, the new MSP runs a documented test of: a backup restore from the most recent backup, a phishing simulation, an MFA-coverage audit, and a firewall configuration review. Each test produces a written deliverable that goes into your firm's records.

Week 4: Ownership transfer and offboarding. The new MSP takes ownership of the remaining production services: domain DNS, email security, EDR, backup, firewall, VPN. Each transfer is scheduled, communicated to your team in advance, and verified by a smoke test. Old MSP credentials are rotated. The old MSP's admin access is revoked. The old MSP receives a written offboarding notice and a confirmation of the handover date.

By day 30, you have: a documented inventory, a new MSP running the practice, rotated credentials, no operational dependency on the old vendor, and a written record of every step. That last item is the unobvious win — it produces, for the first time at most firms, a defensible "we know our stack" record.

The asset and credentials handover checklist

Print this. Walk it down line by line. If the new MSP cannot fill in a column, that is a finding for week 1 to resolve.

Domains and DNS. Domain registrar account, registrar admin user(s), DNS provider, DNS admin user(s). Most-common silent failure: domain registrar email is the personal email of a former employee.

Microsoft 365 / Google Workspace. Tenant admin account, MFA configuration on the admin account, backup MFA recovery codes, license SKUs and counts, billing account. Most-common silent failure: the only Global Admin is the outgoing MSP and there is no backup admin in your firm.

Email security. SPF, DKIM, and DMARC records. Email security gateway provider (Proofpoint, Mimecast, Barracuda, Microsoft Defender, etc.). Quarantine review process. Most-common silent failure: SPF or DMARC misconfigured, allowing inbound spoofing.

Endpoint protection. EDR or antivirus vendor, license count, deployment coverage, console admin user. Most-common silent failure: EDR coverage at 60–80% rather than the 100% the vendor reports.

Backup. Backup vendor, scope (which servers, which workstations, which cloud apps), retention policy, last successful restore test date. Most-common silent failure: backups have been "running" for years but no one has tested a restore.

Firewall and network. Firewall vendor and model, admin user, configuration backup location, VPN configuration, VLAN map. Most-common silent failure: firmware months out of date.

Identity and access. SSO provider (Microsoft Entra, Okta, Google), conditional access policies, privileged-access review cadence. Most-common silent failure: shared admin accounts that no one wants to disclose.

Vendor list. Every third-party SaaS vendor your firm depends on, with admin user, contract owner, renewal date. Most-common silent failure: 30+ SaaS apps with no central inventory.

Run our 5-minute Cyber Scorecard → — it walks through this checklist as part of the assessment.

What to do if your current MSP goes silent or hostile

Most MSP transitions are professional. A small percentage are not. If your current MSP goes silent after notice, drags out credentials handover, or actively obstructs the transition, you have three levers.

Lever 1: written escalation. Send a dated, written request for the credentials list and a target handover date. Most providers respond when the paper trail starts.

Lever 2: contract review. Your MSP contract almost certainly has an offboarding clause and a data-portability clause. Read them. If the MSP is not honoring them, your counsel sends a written notice referencing the specific clause.

Lever 3: independent recovery. If the MSP refuses to hand over credentials they control, your new MSP can rebuild around them: domain registrar transfers go through the registrar's account-recovery process (you own the domain, not the MSP), Microsoft 365 / Google tenant ownership is recoverable through Microsoft / Google support, vendor relationships transfer through the vendor's own account-management process. This path is slower and more expensive, but it works. Document everything.

In our experience, fewer than 5% of switches require Lever 3. The majority of MSPs, even mediocre ones, handle offboarding professionally — they want the reference, even if they lost the account.

How Evolv handles a switch

We run the 30-day playbook above as a standard delivery, with two adjustments for clients who switch to us. First, the inventory and parallel-run period in week 1 is included — you don't pay extra for it. Second, the offboarding step in week 4 includes a written handover packet your firm keeps regardless of what happens after — credentials inventory, vendor list, configuration baseline, and the documented test results from week 3.

Two ways to start.

Option 1: Run the Cyber Scorecard. Five minutes. The Scorecard includes the seven questions in this article applied to your current MSP. Output is a plain-English report you can use either to negotiate with your current provider or to brief candidates.

Option 2: Book a 20-minute scoping call. A named member of our team responds within four business hours. We walk through your current pain, the seven questions, and what a 30-day switch would look like for your firm specifically.