Switching IT providers is one of those projects most businesses put off for a year longer than they should. The current MSP isn’t great, but the prospect of moving feels worse — passwords scattered across systems no one fully maps, applications nobody documented, vendor contacts only your old MSP knows. So you stay.
When you finally do switch, the typical pattern is six weeks of confusion: tickets dropped, security gaps as access transitions, surprise costs the new MSP didn’t quote, employees frustrated when something they used to be able to do “just works” suddenly doesn’t.
It doesn’t have to go like that. This is the 60-day playbook we use when ACS onboards a client moving from another provider — what to do before signing, what to do in the first 30 days, and what the second 30 days look like.
When to switch (and when not to)
Most businesses we onboard had clear signals their old MSP was failing 6–18 months before they actually moved. The signals that matter:
- Response times measurably slipping. Tickets that used to be solved in a day are taking three.
- Strategic conversations stopped. Your account manager hasn’t asked you about your business plans in six months.
- You’re being upsold instead of advised. Every conversation ends with a quote for a new tool.
- A security incident exposed gaps. Your current MSP’s response was reactive, not professional.
- Your business outgrew them. You went from 25 to 60 staff and your MSP is still running the same playbook.
Reasons that look like good reasons but usually aren’t:
- One bad ticket that got resolved poorly. Every MSP has those weeks.
- A cheaper quote. The next quote is almost always a feature mismatch, not actual savings.
- A new junior tech you don’t like. Personality fit matters less than process.
Test: Would your current MSP recover well if their senior engineer left tomorrow? If yes, give them another 6 months. If no, start looking.
Days -30 to 0: Pre-decision diligence
Before you sign with a new MSP, do this work. Skipping it is the single biggest reason switches go badly.
1. Read your current contract end-to-end
You’re looking for:
- Notice period (typically 30, 60, or 90 days)
- Auto-renewal clauses (some auto-renew for 12 months if you don’t notify)
- Data return obligations (what they have to give you, in what format, on what timeline)
- Equipment ownership (firewalls, switches, monitoring agents — who owns them?)
- Software licensing (M365, AV, EDR, backup — bought through them or through you?)
- Off-boarding fees
2. Inventory what you have
Make a list, even if rough:
- Number of users, seats, mailboxes
- Servers (physical + cloud)
- Critical SaaS apps and who admins each
- Network gear (firewall, switches, WAPs)
- Domain names, SSL certs, DNS hosting
- Backup destinations and retention windows
3. Ask candidates the right questions
Not “are you good?” Ask:
- What does your discovery process look like in week 1?
- How do you handle the security risk window during transition?
- What happens if our current MSP refuses to cooperate?
- Show me a sample 90-day onboarding timeline from a similar client.
- What’s your average time-to-resolution by ticket priority?
A real MSP will have direct answers. A weak one will hand-wave.
Days 1–14: The transition starts
Once the contract is signed and notice is given to the outgoing MSP, the clock starts.
Week 1 — Documentation & discovery
The new MSP should pull a full inventory of endpoints, servers, network devices, M365 tenant, and every SaaS app; run a vulnerability scan; audit identity and access (privileged accounts, dormant accounts, MFA coverage); document the current backup configuration and verify it’s actually running; and map your business-critical applications and their dependencies.
You should connect them with the outgoing MSP’s primary tech contact, hand over admin credentials in a structured way (1Password, Bitwarden, Dashlane Business), and identify your champion inside the company — the internal person who knows where the bodies are buried.
Week 2 — Tooling deployment
The new MSP installs RMM agent on every endpoint, EDR / antivirus, patch management, backup agent if not already present, and monitoring on servers and network equipment.
The biggest single security risk in a switch is the overlap window. Both MSPs have access. Tickets fall through gaps. Closing this window fast is more important than perfect documentation.
Days 15–30: Stabilization & first wins
By week 3, the new MSP should be the primary point of contact for new tickets. The outgoing MSP is still on the hook for any work in flight, but no new tickets go to them.
What you should see in this window
- First 30-day report delivered to leadership. Should include: what was found in discovery, what was fixed, what remains, what they’re worried about
- Top 3 security findings identified and either fixed or scheduled for remediation
- Help desk SLA in effect with measurable response times
- First leadership meeting scheduled — strategic check-in, not just operational
Days 31–60: Optimization
The first month is about getting stable. The second month is about getting better. The new MSP should schedule a Quarterly Business Review (QBR), draft an IT roadmap of what’s broken / stale / a priority for the next 12 months, deliver a budget recommendation for the next fiscal cycle, deliver a risk register of the 5–15 things that could hurt your business and what each costs to fix, and complete documentation handoff in a runbook the next engineer could pick up cold.
If you’re not seeing these by day 60, something’s wrong.
The 11 things most IT switches get wrong
- ❌ Underestimating the contract notice period — losing a month before you can even start
- ❌ Letting the outgoing MSP control the timeline of credential handover
- ❌ Assuming the documentation will exist (it usually doesn’t)
- ❌ Not running a security audit during the switch — you’ll never have a better moment
- ❌ Choosing on price instead of on process maturity
- ❌ Failing to identify an internal champion who knows where things live
- ❌ Not budgeting for the discovery / cleanup phase (typical 5–15% of year-1 spend)
- ❌ Skipping the first-30-day strategic review with leadership
- ❌ Letting “small” things from the outgoing MSP linger
- ❌ Not putting the new MSP on a measurable SLA with reporting from day 1
- ❌ Switching during your busy season — give yourself the 60 days when it’s quiet
Costs to expect
| Line item | Cost |
|---|---|
| Discovery & onboarding (one-time) | $4,000 – $10,000 |
| Tooling deployment & licensing setup | $2,000 – $5,000 |
| Documentation & runbook creation | $2,000 – $4,000 |
| Security findings remediation (varies wildly) | $0 – $25,000 |
| Typical 60-day total | $8,000 – $25,000+ |
Where to start
ACS handles roughly 8–12 MSP transitions per year for businesses moving from a provider that’s no longer serving them. We give a fixed-fee transition quote up front — no surprise discovery invoices.
Schedule a free 30-minute scoping call →
Or call 1-650-300-7557.
Frequently asked questions
Will my current MSP fight the transition?
Most don’t actively resist, but many slow-walk credential handover. Build 30 extra days into your timeline.
What’s the right notice period to give?
Whatever your contract requires, plus 30 days of internal preparation.
Can we switch while keeping our same M365 / Google Workspace?
Yes — those tenants are yours, not your MSP’s.
What if our current MSP holds our data hostage?
Read your contract. If it specifies data return obligations and they refuse, that’s a contract violation and an attorney letter handles it.
