How to switch managed IT providers without losing everything

Short answer: Before you give notice, audit everything your current MSP owns or controls on your behalf – domain registrations, DNS, Microsoft 365 tenant, licenses, backup tooling, documentation, admin credentials, and any software subscriptions they pay and rebill. Confirm what belongs to you vs what belongs to them. Get documentation out in writing before the relationship gets awkward. Then run the incoming MSP and the outgoing MSP in parallel for 4 to 8 weeks so discovery and tooling deployment happen while support is still covered. The most common way a switch goes wrong is not the new MSP’s onboarding – it is the old MSP withholding documentation, revoking access, or stalling on license transfers.

If you are reading this, something is probably already wrong with your current MSP. Tickets take too long. The security work never seems to actually happen. The account manager is hard to reach. Costs are climbing without the value matching. Switching MSPs is a project, but it is a manageable one if you sequence it correctly and do the pre-notice work before the incumbent knows you are leaving.

This guide covers what to do before giving notice, how to run the transition, what to ask the incoming MSP about taking over from another provider, the red flags during the exit, and how to recover if the outgoing MSP is uncooperative.

Before giving notice: the pre-switch audit

The single biggest lever you have in an MSP switch is the leverage that disappears the moment you give notice. Once the outgoing MSP knows you are leaving, their incentive to be helpful drops sharply. Everything you can get into writing, into your own hands, and into documentation you control should happen before the notice conversation.

What to audit before you tell your MSP you are leaving

Domain registration. Log into your domain registrar directly. If you cannot, your MSP holds your domains. This is usually the single biggest exit risk – without control of your domain, you cannot move your DNS, your email, or your website. The MSP should transfer the domain to a registrar account in your name before any notice is given if possible, or at minimum confirm in writing that they will release it.

DNS records. Export a full DNS zone file or screenshot every record. You will need these if DNS has to be rebuilt under new management. If the MSP uses their own DNS provider (Cloudflare under their account, a self-hosted setup, etc.), this is a transition risk.

Microsoft 365 or Google Workspace tenant. The tenant should be registered to your organization, not to the MSP. Log in at admin.microsoft.com and check the tenant owner. If the MSP’s name is on it, the licenses and data technically sit under their account, and you need them to transfer ownership. This is fixable but not always quick.

License ownership. Microsoft 365 licenses, backup licenses (Veeam, Datto, Acronis), endpoint protection licenses (SentinelOne, CrowdStrike, Defender), firewall subscriptions, email security (Mimecast, Proofpoint), PSA/RMM licenses. Each one is either owned by you directly (your credit card, your vendor account) or owned by the MSP and rebilled to you. Licenses owned by the MSP revert to the MSP when you leave. You either re-purchase them under your name or migrate to a replacement.

Backup data ownership. If the MSP runs your backups through their tooling under their licenses, your backups live in their infrastructure. You own the data, but the ability to restore depends on their cooperation. Confirm in the contract: who owns the backup repository, can you get a full export, and what is the procedure if you switch providers.

Administrative access. Global admin to M365, domain admin to AD, firewall admin, switch admin, server admin, wireless controller admin, hypervisor admin. You should have direct admin credentials for every system – not the MSP’s shared admin account that will be disabled when they leave. If you do not have your own admin accounts, request them before giving notice, framed as a security best practice rather than an exit preparation.

Documentation. Network diagrams, asset inventory, account matrices, vendor contact lists, runbooks, password vault, compliance documentation, incident history. Every piece of documentation that describes your environment is either in a system you control or in the MSP’s documentation platform (IT Glue, Hudu). Exporting from the MSP’s platform after notice is given is historically slower and sometimes actively blocked.

Line-of-business application access. Vendor relationships for your EMR, legal practice management, CAD software, accounting suite, ERP. If the MSP is the named point of contact at these vendors, you may need to re-establish the relationships. Confirm you are on the vendor’s account as the customer, not the MSP as the customer.

Cyber insurance documentation. If your cyber insurance application references specific controls (MFA, EDR, backup, MDR) that your MSP manages, you will need to document that those controls are continuous through the transition. A gap during the switch could be a claim denial later.

Ticket and incident history. Export ticket history if you can. It is useful during new-MSP onboarding for the incoming team to see what problems were common and how they were resolved.

What belongs to you vs what belongs to the MSP

This is the question that determines how painful the exit will be:

Category	Typically belongs to you	Typically belongs to the MSP
Domain registration	If registered in your name	If registered in MSP’s account
DNS	If hosted with your registrar or a provider you control	If hosted on the MSP’s DNS platform
M365/Google tenant	If you are the tenant owner	If the MSP set up the tenant under their partner relationship
Licenses (M365, security, backup)	If you pay the vendor directly	If the MSP resells and rebills under their account
Documentation content	Your environment data is yours	The MSP’s documentation platform itself is theirs
Backup data	The data is yours	The backup repository and tooling may be theirs
Custom runbooks	Your environment runbooks are yours to keep copies of	The MSP’s template runbooks are their IP
Tooling agents (RMM, EDR, MDM)	None	The agents are licensed to the MSP

A good MSP will have a documented exit policy covering all of the above. A bad MSP will discover these questions for the first time when you give notice.

Read the contract termination clauses

Before doing anything else, read your MSA. Specifically:

• Notice period. 30 days is standard. 60 or 90 is common. Some contracts have 120-day notice. Anything longer is a red flag that was in the original contract, usually missed at signing.
• Termination for convenience vs for cause. Most contracts allow either. Termination for cause may have shorter notice if specific SLA failures or material breaches can be documented.
• Auto-renewal windows. Many MSAs auto-renew for 12 or 24 months if notice is not given within a specific window (often 60 or 90 days before the renewal date). Miss the window and you are locked in another full term.
• Data return obligations. What the MSP is contractually required to return, in what format, and by when.
• Transition assistance terms. Whether the MSP is obligated to provide documentation, credentials, and cooperation during transition, or whether they can exit cleanly on the notice date.
• Early termination fees. Some contracts include them, especially if you signed up during a promotional period or received onboarding credits.

The contract is the floor, not the ceiling. A good MSP will cooperate beyond contract obligations because their reputation matters. A bad MSP will hide behind the contract as a way to punish the departure. Reading the contract tells you which world you are in. The MSA guide covers what each of these sections should say at signing – useful reading before your next contract as well.

Reasons you should actually switch (and reasons you should not)

Before putting 60 to 90 days of transition effort into a switch, make sure the reason is structural, not fixable. Some reasons are clear signals to go:

Structural reasons to switch:

• Repeated security incidents that should have been prevented (ransomware, credential theft, email compromise) with no root cause follow-through
• SLAs consistently missed with no accountability and no plan to fix
• Critical work never actually happening (backup tests, patch verification, security reviews)
• Tooling promised in the proposal that was never deployed
• The MSP cannot handle your growth, your compliance requirements, or your industry
• Account manager and technical leadership have both turned over multiple times
• The MSP has been acquired and the service quality degraded materially
• Pricing has escalated without corresponding value
• You have lost trust in the MSP’s honesty during incidents or QBRs

Reasons that might be fixable with the current MSP:

• One bad incident that was handled reasonably and has a credible corrective plan
• A specific engineer who is not working out (escalate to their manager, request reassignment)
• A specific service gap you have never formally raised
• Communication problems that have not been documented in writing
• Pricing concerns you have not had a structured conversation about

Before giving notice, have one direct conversation with the MSP’s account manager and, if possible, their operations leadership. Present the specific problems in writing. Give them 60 to 90 days to demonstrate change if the issues are fixable. A switch is a 90-day project. If the MSP can fix the issue in 60 days, the switch may not be necessary.

If the problems are structural – they lack capacity, capability, or integrity – no amount of corrective promises will change the trajectory. Go.

The parallel running period

The single biggest mistake in an MSP switch is trying to cut over on a single date. Instead, run both MSPs in parallel for 4 to 8 weeks. The outgoing MSP handles steady-state support while the incoming MSP does discovery, tooling deployment, and security baseline. Cutover happens only after the incoming MSP has full visibility and your users have been introduced to the new helpdesk.

Week-by-week transition flow

Weeks 1 to 2: discovery by incoming MSP. The new MSP runs their standard onboarding discovery – asset inventory, account map, network documentation. They need access to your environment, but they do not yet need to replace the outgoing MSP’s tooling. The outgoing MSP continues to run day-to-day support. (Here is what discovery actually involves and what deliverables to expect.) This phase overlaps heavily with a standalone network assessment – if you have one in hand from before the switch, share it with the incoming MSP rather than making them rebuild from scratch.

Weeks 2 to 4: tooling deployment alongside existing tooling. The incoming MSP deploys their RMM, EDR, MDM, and monitoring. Their agents sit alongside the outgoing MSP’s agents temporarily. This is noisy – both vendors get alerts, patch management may have conflicts – so the incoming MSP usually leads this phase with a coordinated deployment plan. At the end of week 4, the incoming MSP has visibility into your environment.

Weeks 3 to 5: security baseline assessment. The incoming MSP produces a written gap analysis. This almost always reveals things the outgoing MSP was not doing or was doing poorly. Fix the critical findings before cutover (MFA gaps, exposed services, missing backups). This is also the moment you learn whether the problems you were experiencing with the old MSP were structural or procedural.

Weeks 4 to 5: helpdesk introduction. The incoming MSP’s helpdesk is introduced to users. Users know the new portal and phone number and are told to start using them for new tickets. The outgoing MSP’s helpdesk handles legacy open tickets but does not take new ones. This is a soft cutover.

Week 5 or 6: tooling cutover. Outgoing MSP’s agents are removed. Incoming MSP’s agents become the primary. Backup systems are migrated or re-pointed. License transfers complete. This is the operational cutover date.

Week 6: outgoing MSP formal exit. The outgoing MSP’s admin access is revoked. Their API integrations are disconnected. Their offboarding checklist is verified. The MSA is formally terminated per contract terms.

Weeks 6 to 8: stabilization. The incoming MSP runs sole support. Any issues from the cutover are triaged. Documentation is finalized. The first post-cutover status report goes to leadership.

What the parallel period actually costs

You will pay both MSPs during the parallel period. Plan for it in the budget. Depending on the overlap length and whether the outgoing MSP charges full rate or a reduced transition rate, expect 1 to 2 months of double billing.

This is worth it. The alternative – a same-day cutover – almost always produces a 2 to 4 week gap where users have intermittent support, tooling is half-deployed, and security posture is weaker than either MSP’s steady state. The double-billing cost is cheaper than the operational gap.

If the outgoing MSP is cooperative, they may offer a transition rate for the overlap period. Ask.

What to ask the incoming MSP specifically about switching

Beyond the standard MSP evaluation questions, there are switch-specific questions the incoming MSP should be able to answer confidently:

Do you have a documented switch playbook for clients coming from another MSP? Switching is common enough that every mature MSP has a standard playbook for it. If the incoming MSP treats switching as novel, that is itself concerning. (See the full list of questions to ask any prospective MSP before signing.)

What do you do differently during onboarding when the client is switching from another MSP vs a first-time engagement? Good answers cover: coordinated tooling deployment so agents do not conflict, parallel running support, accelerated security baseline focused on closing gaps the outgoing MSP missed, structured documentation handoff from outgoing MSP with an escalation plan if they are uncooperative.

How do you handle an uncooperative outgoing MSP? Reality: some outgoing MSPs slow-roll or actively sabotage the exit. The incoming MSP should have a plan for this – rebuilding documentation from scratch, recovering admin access through vendor relationships (Microsoft support can reset tenant global admin in certain cases), engaging legal counsel for contractual obligations. If they do not have a plan, they have not done this often.

Can you provide two or three reference clients you onboarded from another MSP? Reference calls about a switch experience are more valuable than generic reference calls because they surface the specific failure modes.

What is your SLA for taking over emergency support during the parallel period? If something breaks badly in week 2 and the outgoing MSP is slow, can the incoming MSP step in even before full tooling is deployed? They should be able to.

What is your exit policy, for the day I eventually leave you? If they cannot answer this clearly, they are planning to make your next switch difficult. A good MSP is as transparent about exiting as about entering.

Red flags during the outgoing MSP’s exit

Once notice is given, the outgoing MSP’s behavior tells you whether the contract was a relationship or a trap. Watch for:

Slow or missing documentation. Repeated “we’ll get that to you” with no delivery. Exports from their documentation platform that are incomplete or formatted in ways that are hard to import. Missing vendor contact details. These are all stalling tactics.

Admin access revoked early. The contract specifies a termination date. The MSP should maintain agreed access until that date. Early revocation (disabled accounts, disconnected APIs, revoked privileges) is a breach and potentially grounds for contract escalation.

Tooling licenses “expired” at an inconvenient time. Conveniently-timed license expirations on backup, security, or RMM tooling during transition is sometimes real and sometimes manufactured. Get it in writing what licenses expire when and who owns them.

Sudden ticket backlog. Tickets that had been moving smoothly suddenly sit unanswered for days. Support quality drops noticeably post-notice. This is a way to create pressure to “reconsider” the switch.

Surprise final invoice. Charges that were not previously discussed – offboarding fees, documentation export fees, license reclaim fees, early termination penalties you did not realize were in the contract. Dispute anything not in the MSA. Get anything new in writing.

Legal threats or intimidation. Rare, but occasional. Usually about data return, license ownership, or contract interpretation. Involve your counsel immediately and document everything.

Key engineer unavailable. The engineer who knows your environment best is suddenly “on PTO” or “reassigned” for the full transition period. This is deliberate.

Communication through only one channel. The account manager refuses to put things in writing and insists on phone calls. Keep written records of every commitment. Follow up phone calls with email summaries.

How to recover from a bad exit

Sometimes the exit goes poorly and you are left without the documentation or access you expected. Options:

Rebuild documentation from scratch. The incoming MSP’s discovery phase effectively rebuilds the documentation. This takes longer (60 to 90 days instead of 30 to 45) but is recoverable. Expect a higher onboarding fee.

Recover admin access through vendors directly. Microsoft support can reset tenant global admin under specific procedures. Domain registrars can transfer domains if you have proof of ownership. Firewall vendors have password reset procedures. These are all slower than cooperative handoff, but they work.

Invoke contract provisions and involve legal counsel. If the outgoing MSP is violating MSA terms (delayed documentation return, held hostage licenses, refused cooperation), a cease-and-desist letter or formal demand from counsel often accelerates compliance. This is expensive, but the leverage is usually enough.

File a complaint with licensing vendors. Microsoft’s CSP program and similar partner programs have rules about client data ownership and transition. A formal complaint to the vendor can unlock tenant transfers the outgoing MSP is blocking.

Rebuild the M365 tenant if necessary. Worst case: if tenant ownership cannot be transferred and the outgoing MSP is truly hostile, a new tenant can be created under your organization’s name and data migrated into it. Painful, but done regularly. The incoming MSP should know how.

Document every obstacle for the next MSP. A bad exit from one MSP is useful context for evaluating the next one’s switching playbook.

What good exits look like

Not every switch is adversarial. Many outgoing MSPs behave professionally, especially if the relationship ended for reasons of fit rather than misconduct. A good exit looks like:

• Exit checklist provided within the first week of notice
• Written confirmation of what documentation will be delivered, in what format, by when
• A transition lead assigned at the outgoing MSP who coordinates with the incoming MSP directly
• Tooling deployment coordination so agents do not conflict
• Transparent handover of licenses, credentials, and vendor relationships
• Open communication during the parallel period
• A final closeout meeting with documentation of any remaining open items

If you are the kind of client a good MSP would welcome back, a professional exit preserves that option. Relationships change, companies change, and sometimes the right MSP in three years is the one you are leaving today.

Switching timeline, start to finish

For an SMB in the 25 to 150-user range, a switch typically looks like:

Stage	Timeline	Activity
Pre-notice audit and decision	Weeks -6 to 0	Audit ownership, read contract, evaluate incoming MSPs
Notice given	Week 0	Written termination notice per contract terms
Incoming MSP kickoff	Week 1	Kickoff, onboarding plan, discovery begins
Discovery and tooling deployment	Weeks 1 to 4	New MSP builds environment picture, deploys agents
Security baseline	Weeks 3 to 5	Gap analysis, critical findings closed
Helpdesk cutover	Weeks 4 to 5	Users transition to new helpdesk
Tooling cutover	Week 5 to 6	Old MSP agents removed, new MSP becomes primary
Outgoing MSP formal exit	Week 6	Access revoked, contracts terminated, data return complete
Stabilization	Weeks 6 to 8	Full steady-state under new MSP
First QBR under new MSP	Month 4	Strategic review of transition and forward plan

For larger environments, regulated industries, or hostile exits, the timeline extends to 12 to 16 weeks. For small environments (under 20 users), it can compress to 4 to 6 weeks if the outgoing MSP cooperates.

Common mistakes to avoid

Giving notice before doing the audit. The leverage drops sharply the moment notice is given. Everything you can confirm or recover before that conversation is easier than after.

Cutover on a single date. Parallel running is worth the cost. Same-day cutovers produce coverage gaps almost every time.

Not reading the contract first. Auto-renewal windows, notice periods, termination clauses, and early termination fees are all in the MSA. Surprises from the contract during notice are avoidable.

Skipping the security baseline from the incoming MSP. The switch is the perfect time to fix the gaps the outgoing MSP left open. Skipping this just imports those gaps into the next relationship.

Not involving leadership and legal in the outgoing MSP conversations. If the exit goes poorly, you need documented communications and authority to escalate. Handling the entire exit through the office manager or IT coordinator alone leaves you under-leveraged.

Assuming the new MSP’s onboarding is a solved problem because you just went through one. A switch onboarding is different. Validate the incoming MSP’s specific switching playbook before signing.

Letting the outgoing MSP write the handover documentation. Review everything they send. Verify it is complete and accurate. An outgoing MSP who produces a 200-page handover document that is mostly boilerplate has not actually transferred anything.

Skipping the contract review with the new MSP. You are about to sign a new MSA. Apply everything you just learned about contracts. Use the MSA checklist to avoid signing yourself into the same trap you are leaving.

How switching relates to onboarding and pricing

Switch onboarding is a premium over first-time onboarding because of the parallel running period, tooling coordination, and documentation recovery work. Expect the incoming MSP to quote either a higher onboarding fee or a longer onboarding duration for switch scenarios. This is reasonable. The pricing model breakdown covers how onboarding fees fit into the overall MSP cost structure.

If the MSP you are leaving had a per-device pricing model and the new MSP is per-user, expect the headline rate to look different even if the total cost is similar. Apples-to-apples comparison requires normalizing to total monthly cost across your actual user and device counts. The cost benchmark article has typical ranges by pricing model.

Switch-era SLAs are sometimes negotiable. The incoming MSP knows you have been burned, and some will offer tighter SLAs or written commitments on the specific failure modes you experienced at the old MSP. Ask. How SLAs should actually be structured.

How Sequentur handles switching clients

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Clients switching to us from another MSP are common – roughly a third of new engagements.

Our switch playbook runs 60 to 90 days depending on environment complexity and the outgoing MSP’s cooperation. We run parallel to the outgoing provider for 4 to 6 weeks while discovery, tooling deployment, and security baseline work happens. The helpdesk is live from day 1 under our existing tooling; users transition to our portal and phone number in week 4 or 5, and the tooling cutover follows once we have full environment visibility.

We produce a written switch plan before onboarding starts, coordinate directly with the outgoing MSP where they are cooperative, and have a structured playbook for the cases where they are not – including vendor-level escalation for tenant transfers, admin recovery, and license ownership disputes. If we inherit an environment with material gaps from the prior MSP (missing backups, no MFA, open firewall rules, unpatched servers), those are closed during onboarding, not scheduled into year two.

When it is eventually time for you to leave us – whether that is for reasons of fit, acquisition, or any other reason – our exit policy is documented in the MSA. Documentation return, license transfer, admin handover, and parallel running are covered in writing, not discovered during notice.

If you are evaluating a switch and want to walk through the specifics of your environment, schedule a call. We will help you think through the pre-notice audit, the parallel running period, and the specific risks of your current setup – whether or not we end up being the next MSP. If the right move is staying with your current provider and fixing specific issues, we will tell you that too.