Account Contact Build your IT department

Learn / practitioner

Migrating from your MSP without breaking everything

Most MSP migrations break in one of three places: contract overlap that costs you double, knowledge transfer that fails to happen, and the moment of cutover when nobody owns the next 72 hours. Here is how to avoid all three.

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 had handled it differently. We have migrated dozens of customers off their previous MSPs and we have watched companies migrate to other vendors. The patterns of what works and what fails 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. Plan the overlap deliberately; otherwise you either pay for two vendors at once (sometimes for months) or you operate without coverage during the gap (sometimes catastrophically).

Knowledge transfer that fails to 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 always misbehaves. Most contracts leave knowledge transfer optional; many MSPs lack motivation to provide it. Actively extract this knowledge before the relationship ends, or you and your new vendor will 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. Assign explicit ownership of those 72 hours — otherwise the contracts simply hand off and assume continuity, and 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:

  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.
  2. A list of in-flight projects and tickets. Anything your outgoing MSP is mid-stream on. These need explicit transition plans.
  3. 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.
  4. Your outgoing MSP’s contract terms in plain language. Notice period, fees, what they own (data, configurations, scripts) versus what you own.
  5. 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 have been wanting to make.

We strongly recommend running the selection process AFTER Phase 1, rather than 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 stand on its own, independent of 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 withhold. 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 are 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 have seen too many migrations where the outgoing MSP withholds operational documentation because the contract left sharing optional.

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, rather than a ticket queue.
  • A “quiet 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 failed to surface. Tickets that went unfiled 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 lacking one will improvise — sometimes successfully, often poorly. Ask to see the document. If they lack one, you are funding their learning curve.

2. What is your knowledge-transfer approach when the outgoing MSP withholds cooperation? 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 rather than a requirement.” If your candidate vendor relies entirely on the outgoing MSP’s cooperation, that is 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 commit to reduced 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. Have them anyway.

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 have overlooked? (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 will provide best-effort support during your transition,” translate that as “we will respond to easy tickets and skip 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 are 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 sometimes stay undisclosed until termination.
  • License entanglement. Some MSPs purchase licenses (M365, security software) on your behalf at their volume rate. When you leave, those licenses fail to transfer cleanly; you will 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 fall short. 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. Resist that impulse. 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 have 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 is the highest praise an IT migration can get.

If you are considering a switch, a 15-minute conversation gives you a sense of whether we would be a good fit and what the migration would look like for your specific environment. We let the timeline breathe; the alternative — a botched migration — is bad for everyone, including us.

Technically reviewed by Tobias Wexler.

Want this turned into a real plan?

The build flow uses the same logic this article describes — three minutes to a configured IT department.

Build your IT department Talk to us