Switching IT vendors is the kind of project everyone agrees should be straightforward — and which, in practice, takes 60 to 90 days, breaks in unexpected places, and leaves about a third of the affected companies wishing they’d handled it differently. We’ve migrated dozens of customers off their previous MSPs and we’ve watched companies migrate to other vendors. The patterns of what works and what doesn’t have stabilized.
This piece is the playbook we wish more companies had before they started.
The three places it usually breaks
Before tactics, the failure modes worth understanding so you can design against them.
Contract overlap. The outgoing MSP’s contract has a notice period, typically 30 to 90 days. The incoming vendor needs runway to onboard, typically 14 to 45 days. If you do not plan the overlap, you either pay for two vendors at once (sometimes for months) or you operate without coverage during the gap (sometimes catastrophically).
Knowledge transfer that doesn’t happen. Your outgoing MSP has institutional knowledge — which scripts run on which schedules, which user has which exception, why the printer in the conference room never works. Most contracts do not require knowledge transfer; many MSPs are not motivated to provide it. If you do not actively extract this knowledge before the relationship ends, you and your new vendor rediscover it through pain.
The 72-hour cutover gap. The exact moment the old vendor’s responsibility ends and the new vendor’s begins is when something will go wrong. If nobody owns those 72 hours explicitly — if the contracts simply hand off and assume continuity — you will spend a weekend fielding tickets neither vendor wants.
Plan for all three. They are predictable and they are preventable.
The 90-day timeline
A clean migration runs roughly 90 days end to end, broken into three phases.
Phase 1: Discovery + selection (Days 1-30)
This is the part most companies under-invest in. The mistake: treating it as a sales conversation when it should be an audit of your current state.
What to produce in Phase 1:
- An inventory of what you actually have. Endpoints, identities, SaaS tools, network gear, backups, integrations, custom scripts. Most companies discover that 20 to 40 percent of their stack is undocumented when they look.
- A list of in-flight projects and tickets. Anything your outgoing MSP is mid-stream on. These need explicit transition plans.
- A documented current state of every external integration. Your phone system, your security camera vendor, your printer maintenance contract — every thread that touches your IT environment.
- Your outgoing MSP’s contract terms in plain language. Notice period, fees, what they own (data, configurations, scripts) versus what you own.
- A target operating model. What do you want IT to look like 90 days after migration completes? “The same as before but cheaper” is rarely the right answer; an honest answer involves changes you’ve been wanting to make.
We strongly recommend running the selection process AFTER Phase 1, not before. A vendor pitch lands very differently when you can hand them a documented current state and a target operating model.
Phase 2: Onboarding + parallel run (Days 30-75)
The new vendor onboards. The old vendor still operates. They run in parallel.
Key milestones:
- Day 30-35. Notice given to outgoing MSP per contract. New vendor begins discovery (formally — they should have already done a high-level scoping during selection).
- Day 35-50. New vendor builds parallel monitoring and operational tooling. Critical: this should not require the outgoing MSP’s cooperation. Most modern RMM and EDR platforms can be deployed alongside another platform, and the cost of running both for two weeks is dramatically smaller than the cost of a botched cutover.
- Day 50-65. Knowledge transfer sessions. We typically run two to four working sessions with the outgoing MSP — usually with the principal in the room — to extract operational knowledge. Some MSPs cooperate generously; others don’t. Plan for the worst case (nothing useful) and be pleasantly surprised.
- Day 65-75. Test the cutover scenarios in advance. What happens if a ticket arrives Monday morning? Who responds? What happens if a critical alert fires Saturday at 3am? Walk through the runbooks before they’re needed.
The contractual point most companies miss. Your outgoing MSP’s contract probably says they own the configurations, scripts, and documentation they built. Get this clarified in writing before the parallel-run phase. We’ve seen too many migrations where the outgoing MSP withholds operational documentation because they were never required to share it.
Phase 3: Cutover + first 30 days (Days 75-90+)
The actual cutover and the first 30 days under sole new-vendor management.
Day 75 — cutover day. The outgoing MSP’s responsibility ends; the new vendor’s begins. The 72-hour window we mentioned. Critical things to have planned:
- A direct number to a senior engineer at the new vendor for the first 72 hours, not a ticket queue.
- A “do nothing on Friday” rule — no production changes, no major deployments, no risky maintenance windows in the 48 hours pre- or post-cutover.
- An explicit on-call rotation for the new vendor that covers the cutover weekend.
- A pre-agreed escalation path if something genuinely goes wrong (called recovery clause in some contracts).
First 30 days post-cutover. New vendor finds the things the discovery phase didn’t surface. Tickets that nobody filed before because the outgoing MSP just handled them. Configurations that were undocumented but critical. Plan for 50% more first-month tickets than steady-state, and budget the new vendor’s onboarding time accordingly.
What to ask of the incoming vendor
Beyond the obvious (cost, services, references), three questions distinguish good migrations from bad ones.
1. Can I see your migration runbook? Vendors who have done this often have a standardized runbook. Vendors who haven’t will improvise — sometimes successfully, often not. Ask to see the document. If they don’t have one, you’re funding their learning curve.
2. What’s your knowledge-transfer approach when the outgoing MSP doesn’t cooperate? Every experienced vendor has war stories. Ask for them. The honest answer is “we extract knowledge from the environment itself — endpoint configurations, identity provider settings, alerting history, ticket archives — and we treat the outgoing MSP’s input as a bonus, not a requirement.” If your candidate vendor relies entirely on the outgoing MSP’s cooperation, that’s a yellow flag.
3. What does the first 30 days post-cutover look like in your service-level commitments? Many vendors quietly assume the customer is “in onboarding” for the first 30-60 days and do not commit to their normal SLAs during that window. This is reasonable up to a point and abusable past it. Get specifics in writing.
What to ask of the outgoing MSP
Most companies are awkward about leaving an MSP and skip these conversations. They shouldn’t.
1. Configuration and documentation handoff. What configurations, scripts, runbooks, and documentation will you provide upon termination? In what format? Get this in writing as part of the termination notice.
2. Final billing. When does invoicing stop? What happens to prepaid balances? Are there any termination fees you’ve forgotten? (Read the contract carefully. Termination fees are common.)
3. Continued support during transition. Will you respond to tickets during the parallel-run phase, or is your operational coverage already winding down? If they say “we’ll provide best-effort support during your transition,” translate that as “we’ll respond to easy tickets and ignore hard ones.”
4. Data return or destruction. Any backup data, log archives, or documentation they hold. State explicitly whether you want it returned, destroyed, or held in escrow. Most contracts default to ambiguous, which is bad for everyone.
The contractual gotchas
A short list, in rough order of frequency:
- Auto-renewal clauses. Many MSP contracts auto-renew with shorter notice windows. Miss the window, you’re locked in another year.
- Data-portability fees. Some MSPs charge for “exit assistance” — extracting your data, transferring configurations, providing documentation. These can run into five figures and are sometimes not disclosed until termination.
- License entanglement. Some MSPs purchase licenses (M365, security software) on your behalf at their volume rate. When you leave, those licenses don’t transfer cleanly; you’ll need to repurchase or migrate. Add 14-30 days of buffer for license re-procurement.
- Documentation gaps that ARE the deliverable. Every MSP says they document everything. Many don’t. Find out before you need to.
- The “we own the runbooks” clause. Some contracts assert that the operational documentation built during the engagement is the MSP’s intellectual property. This is a red flag — you should own (or at minimum jointly own) the documentation of how YOUR systems work.
The two anti-patterns to avoid
The “rip and replace” overnight. Some companies, frustrated with their MSP, want to switch vendors in two weeks. Don’t. The discovery + parallel-run + cutover phases each have minimum viable durations. Compressing them produces measurably worse outcomes.
The “two MSPs in parallel forever” hedge. Some companies, nervous about switching, run both vendors for 90+ days. This is expensive and produces accountability ambiguity (when something breaks, both vendors blame the other). Pick a hard cutover date and stick to it.
What we do when migrating a customer to us
We’ve codified the migration process into a 90-day program. The first 30 days are discovery. The middle 30 are parallel-run with weekly checkpoints. The final 30 are cutover plus stabilization. Most of our customers describe the transition as “calm” or “boring” — and that’s the highest praise an IT migration can get.
If you’re considering a switch, a 25-minute conversation gives you a sense of whether we’d be a good fit and what the migration would look like for your specific environment. We don’t push the conversion; the alternative — a botched migration — is bad for everyone, including us.