Eight signs you need to switch
None of these alone is decisive. Two or three together, and the conversation should start.
1. Tickets sit for days
A modern managed IT shop answers calls or returns them in the hour, emails inside two business hours, and resolves the routine stuff the same day. If your tickets disappear into a queue and come back a week later, that's a staffing or process problem the current MSP isn't going to fix without a contract renegotiation.
2. The same problem keeps coming back
The printer that goes offline every Monday. The VPN that drops the third Tuesday of the month. The user whose Outlook profile gets corrupted on a cycle. Recurring tickets without root-cause resolution are a sign the MSP is operating at break-fix throughput inside a managed contract.
3. The bill never matches the quote
The proposal said one number; the monthly invoice creeps up with line items that weren't in the conversation. Sometimes those are legitimate (you added users, the M365 SKU changed). Often they're not. A reputable MSP can reconcile every line on the invoice to your written agreement on five minutes' notice.
4. No current asset list or network diagram
Ask the current MSP for a current inventory of your endpoints, users, applications, and a network diagram. Give them a week. If they can't produce it, they're not managing your environment — they're reacting to it.
5. Security advice that's a sales pitch
Recommendations that always conveniently lead to upgrades on the MSP's preferred SKUs, with no risk analysis behind them. A real recommendation comes with evidence — the risk it mitigates, the controls it replaces, the carrier-required control it satisfies.
6. The response to a real incident was slow or ad hoc
Most MSPs look fine until an incident. The phishing-compromised mailbox, the ransomware staging that almost-succeeded, the wire-fraud near-miss — how the MSP handled those tells you everything. Slow response and improvised playbooks are red flags.
7. The bus factor is one
You only ever talk to one person at the MSP. That person knows everything about your environment. If they leave, take a long vacation, or quit, you have a continuity problem.
8. The MSP won't put anything in writing
Response-time SLAs, the offboarding terms, the security stack vendor list, the BAA — a professional MSP writes all of these into the contract or signs them when you ask. Verbal commitments that never become documents are a posture problem.
Step zero: read the current contract
Before any conversations with a new provider, find the current MSP contract and find three things:
- Term and renewal. When does the term end? Is it auto-renewing? What notice is required to end it — 30, 60, 90 days? Missing the notice window can lock you in for another full year.
- Early-termination fees. What does it cost to leave before the term ends? Sometimes the math says the ETF is worth paying; usually it says waiting for the notice window is.
- Offboarding terms. What does the current MSP have to hand back — credentials, configurations, recovery keys, documentation — and at what cost? If those aren't specified, ask the new MSP to plan for working without them.
A reputable new MSP will read the current contract with you and plan the cutover around the notice window.
The 90-day parallel-run cutover
Done well, switching MSPs has zero end-user-visible downtime. The trick is parallel run.
Days 1–15: Discovery
The new MSP performs an environment discovery — every endpoint, every mailbox, every application, every vendor relationship, every recovery key, every domain registration. They document the current state in writing. This is the first product the new MSP delivers, and it tells you how serious they are about the rest.
Days 15–45: Parallel deployment
The new MSP deploys their managed stack — EDR, RMM, backup, monitoring — alongside the current MSP's tooling. Two things are running on each endpoint for a few weeks. This is the parallel-run phase, and it's the difference between a clean cutover and a risky one.
During parallel run, the new MSP validates every system: backups complete and restore-test, EDR triggers and SOC responds, RMM patches deploy, monitoring catches outages. Anything that doesn't work in shadow mode gets fixed before cutover.
Days 45–60: Sequential cutover
Components transfer ownership one at a time, in the right order:
- Endpoints — old RMM and antivirus are uninstalled, new EDR is primary.
- Identity — admin access on Microsoft 365 transfers (the old MSP's admin accounts go to read-only, then off).
- Network — firewall, switches, wireless ownership transfers.
- Backup — old backup jobs decommission after the new backup has full retention.
- Vendor relationships — the MSP-of-record changes with Microsoft, Datto, the ISP, every third-party vendor.
Days 60–90: Stabilize
The new MSP is fully managing. The old MSP's contract notice has been served. End users have a new help-desk number and a documented escalation path. Anything that surfaces in week one of full management gets resolved.
The handoff conversation with the current MSP
Most current-MSP relationships end professionally. The notice goes in writing per the contract, the offboarding meeting gets scheduled, credentials and configurations are returned, the final invoice gets paid. The new MSP can run the offboarding meeting on your behalf if you want it that way; you don't have to be in the middle of any of it.
If the current MSP refuses to cooperate or demands fees beyond what the contract specifies, the new MSP should be able to take over without them. Domain registrations, M365 tenants, vendor accounts, and physical hardware are all owned by you, not by the MSP. The new MSP rebuilds documentation from the production environment.
What to ask any prospective new MSP
- What does the discovery deliverable look like — can I see a sample?
- Walk me through your parallel-run cutover. What's running on each endpoint during the overlap?
- What happens if my current MSP doesn't cooperate?
- What's your response time during cutover — is it different from steady state?
- Who's my account contact, and who's their backup?
- What's in the offboarding terms when I eventually leave you?
The last question is the test. A new MSP that can't tell you how to leave them is the same risk you're trying to walk away from.
How a Micro-IT switch works
Every Micro-IT onboarding starts with the four-phase approach — discover, stabilize, optimize, operate — that's designed around parallel run. For a switching client, the discovery deliverable is the bridge: it gives both us and you a written current-state picture before any cutover decisions get made. We've done the awkward call to the previous IT on behalf of clients before; we'll do it again. See the four-phase approach for the operational detail, or get a switch-cost estimate based on your current environment.