To switch managed IT providers cleanly, sign with your new MSP first, transfer knowledge and tenant ownership before you give notice, then give your outgoing provider a structured offboarding window – usually 30 to 60 days. The single most common mistake is sequencing the conversation backwards: telling your current MSP you’re leaving before your new one is ready to catch you. The second most common mistake is assuming you own your Microsoft 365 tenant. You often don’t, until you fix it deliberately.
We’ve sat on both sides of this process – taking new clients away from MSPs that weren’t serving them, and (very rarely) seeing one of our own clients move on. Here’s the order of operations that actually works.
Why does sequencing matter so much when switching MSPs?
Because the period between “I’m leaving” and “the new MSP is fully operational” is when things break. Documentation goes missing. Admin credentials get rotated and not shared. The outgoing provider’s incentive to do good work drops to zero the moment you give notice. If you announce your departure before your replacement is signed and prepared, you’re handing leverage to a vendor who has no reason to use it kindly.
The right order is:
- Decide internally and document the decision
- Pick a new MSP and sign the engagement
- Pull your documentation, credentials, and tenant ownership while your old provider still wants to be helpful
- Verify your new MSP can deliver service on day one
- Then give written notice to the outgoing provider
- Run a structured offboarding window in parallel with onboarding
Skip any of those steps and you’re either paying twice or going without coverage at the worst possible moment.
Who actually owns my Microsoft 365 tenant?
This is the question almost nobody asks before switching, and it’s the one that turns into a multi-week mess afterward.
In most managed services arrangements, your MSP holds delegated admin access to your Microsoft 365 environment through Microsoft’s Granular Delegated Admin Privileges (GDAP) model. GDAP replaced the older, more dangerous “DAP” model that gave MSPs global admin to every client by default. GDAP is better, but it has its own quirks: relationships expire, scopes vary by MSP, and if the relationship is set up wrong, you can find yourself locked out of your own tenant when you switch providers.
Before you give notice to your current MSP, you need to confirm three things:
- Your tenant is registered to your company, not the MSP’s partner account. Your billing relationship should be either direct with Microsoft or with a CSP (Cloud Solution Provider) that you can change without rebuilding the tenant.
- At least one global admin account is owned and controlled by your company, with MFA enforced, password stored in your password manager, not the MSP’s. This account should not depend on the outgoing provider for sign-in.
- You have an inventory of GDAP relationships so you can revoke the outgoing MSP’s access at the right moment – neither too early (breaking their ability to help with transition) nor too late (leaving stale admin access in place after they’re gone).
If any of those three are unclear, fix them before you announce your decision. A cooperative outgoing MSP will help. A non-cooperative one will at least still answer your emails while you’re a paying client.
The same principle applies to other tenant relationships you don’t think about until they break: your domain registrar, your DNS host, your backup tenant, your endpoint management platform, and any vendor MFA seeds. If the MSP set it up, ask now who owns it and how to take over.
What documentation should I get from my outgoing MSP?
A complete handover package should include, at minimum:
- Network diagram showing all sites, VLANs, internet circuits, and key infrastructure
- Asset inventory with serial numbers, license assignments, and warranty status
- Account inventory including service accounts, vendor portals, and shared mailbox configurations
- Admin credentials and recovery methods, transferred securely (not in plain-text email)
- Backup configurations and recovery procedures, including where backup data physically lives
- Vendor and license contracts including renewal dates and contact information
- Open project status and any work-in-progress with handoff notes
- Recurring tasks and runbooks – patching cycles, monthly maintenance, anything scheduled
Some MSPs hand all of this over without flinching because they’ve built a clean handover process. Some make you ask for each piece individually. Some lose track of half of it. The quality of the handoff is itself a quiet judgment on how the relationship was run all along – and it’s one of the things that should have come up earlier in your evaluation of the provider’s performance.
How long should the transition take?
For a typical small or mid-size business, plan on a 60 to 90 day transition window:
- Weeks 1–2 – New MSP signs, scoping and discovery begins, tenant ownership and credential audit happens behind the scenes
- Weeks 3–4 – Documentation pull, knowledge transfer meetings, tooling and RMM deployment from the new MSP
- Week 5 – Written notice to outgoing provider, formal offboarding window begins
- Weeks 6–8 – Parallel operations: new MSP takes over front-line support, outgoing MSP retains read access for questions
- Weeks 9–12 – Final access revocations, contract closure, retrospective with new MSP
That timeline assumes you’re already past the “should I switch” decision. If you’re still working through whether the move is warranted, our post on the red flags of a bad MSP is a better starting point.
For context, healthy MSP onboarding follows its own predictable rhythm – we cover that timeline in our MSP onboarding post.
What contract issues should I watch for?
A few common ones:
- Termination notice period. Standard is 30 to 60 days. If yours is longer than 90 days, factor it into your timeline.
- Early termination fees. Read these carefully. Some contracts include cooperative offboarding language; some include a final charge equal to a few months of fees.
- Data return obligations. A reasonable agreement specifies that documentation, configurations, and credentials are returned in a usable format on request. Without that clause, getting your data back can become a negotiation.
- Assignment clauses. If your MSP was recently acquired, confirm whether the contract was assigned to a new entity and what your termination rights look like under the assigned agreement.
- Auto-renewal triggers. Many MSP contracts auto-renew unless you give notice in a specific window. Miss the window, and you’re locked in for another year.
You don’t need a lawyer for most of this, but you do need to read the contract you actually signed, not the one you remember signing.
What if my current MSP gets uncooperative?
It happens. Not often, but enough that you should plan for it. The signs are usually obvious within the first week of notice: delayed responses, “missing” documentation, sudden invoice issues.
Your protections:
- You already have your own global admin account. (You did the GDAP step first, right?)
- You have your domain registrar credentials. Whoever controls DNS controls a surprising amount of your business.
- You have backups outside the outgoing MSP’s environment. If your backups live in their tenant, this is the moment to wish you’d asked sooner.
- Your new MSP has been deploying their own tools in parallel. They aren’t dependent on the outgoing provider for anything operationally critical.
If those four are in place, an uncooperative outgoing MSP becomes an inconvenience rather than a crisis.
If you’re thinking about switching managed IT providers and you want a calm, structured plan instead of a stressful jump, start a conversation with ROI Technology. Call (888) 707-3652. We’ll talk through your situation, tell you whether the move is worth making, and – if it is – handle the offboarding so you don’t have to.