Most companies that are unhappy with their IT provider stay anyway, often for years. Not because the service improved. Because switching feels dangerous, and nobody wants to own the decision if the cutover goes badly.
The fear is understandable and mostly avoidable. I have watched dozens of transitions from both sides, as the provider being replaced and as the one coming in. The ones that go smoothly follow the same sequence. The ones that go badly skip steps in a predictable order, and almost every horror story traces back to something that should have happened before anyone gave notice.
Here is the full sequence, in the order it should happen.
What is an MSP transition?
An MSP transition is the process of moving your IT environment, documentation, credentials, and support operations from one managed services provider to another, or from an internal team to a provider. A well-run transition has three phases: preparation before you give notice, an overlap period where both providers hold defined responsibilities, and a cutover with a verified rollback point.
The whole thing typically takes 60 to 90 days. Rushing it below 30 is where downtime stories come from.
Before you give notice: secure what is yours
The single most important rule of switching: confirm you hold your own keys before the incumbent knows you are leaving. Most providers behave professionally on the way out. You should not need to bet your uptime on it.
Work through this list quietly, before any termination conversation:
- Global admin credentials. Confirm your organization holds at least one global administrator account for Microsoft 365, Azure, and every other core platform, in your name, with MFA enrolled to your devices, not the provider’s.
- Domain registrar and DNS. Check who owns the registrar account for your domains. Providers registering client domains under their own accounts is still common, and it is the ugliest thing to untangle after a relationship sours.
- Licensing ownership. If your Microsoft licenses run through the provider’s CSP agreement, they control the subscription. Ask for your tenant ID and inventory what transfers and what needs to be repurchased. A new provider can move CSP billing without disrupting the tenant, but only if you know what is there.
- Backups. Verify you can restore from backups without the provider’s involvement, and confirm where backup data physically lives. If the answer is “in their datacenter, under their contract,” plan for an export.
- The contract itself. Read the termination clause before you act on it. Notice periods of 60 or 90 days are standard. Look for auto-renewal dates, early termination fees, and any language about offboarding assistance, because you will want to hold them to it.
If you cannot answer one of these, that gap is your first project, and it is worth doing even if you end up staying.
What should the incumbent hand over?
Documentation is where good transitions are won. Your offboarding request to the incumbent should name specific artifacts, not “all documentation.” Ask for:
- Network diagrams and IP schemas, current as of handover
- An asset inventory: servers, endpoints, network gear, with warranty and age
- All administrative credentials, delivered through a password vault transfer, not a spreadsheet
- Vendor and ISP account lists with account numbers and support contacts
- Ticket history, or at minimum the last 12 months of it
- Any runbooks or standard procedures written for your environment
Ticket history matters more than people expect. Twelve months of tickets tells the incoming provider which systems generate problems, which users need the most support, and where the recurring failures are. Losing it means the new service desk starts blind and relearns your environment one incident at a time.
Expect some friction here. Documentation quality is usually the reason companies leave in the first place, so the handover package is often thin. That is fine to discover in week one. It is expensive to discover during cutover.
How does the overlap period work?
The overlap is the 2 to 6 weeks where the outgoing and incoming providers are both engaged. It costs money, since you are paying two contracts at once, and it is worth every dollar. Skipping overlap to save a month of fees is the most common cause of transition downtime I have seen.
During overlap, the split should be explicit and written down. The incumbent keeps responsibility for incident response and day-to-day support. The incoming provider does discovery: deploying their monitoring and management agents, validating the credential handover, testing backup restores, and shadowing the ticket queue. Users keep calling the number they already know.
Two things should be true before overlap ends. The incoming provider has resolved real tickets in your environment under supervision, and they have restored at least one system from backup as a test. If either has not happened, extend the overlap. A week of extension is cheap insurance.
The cutover weekend, and what “no downtime” actually means
The cutover itself is mostly administrative if the preparation happened: support contacts change, monitoring alerts reroute, the incumbent’s agents come off, and admin access gets revoked in the right order. Revocation goes last, after the new provider confirms they hold everything, never before.
Honest expectation-setting: users should notice a new name when they call support, and nothing else. Systems do not go down during a well-run MSP transition because nothing about the systems themselves is changing, only who watches them. When downtime happens, it is almost always a self-inflicted access problem, like removing the old provider’s accounts before verifying the new ones, which is why the sequence above exists.
Set a rollback point anyway. Keep the incumbent’s contract technically alive through the first week of cutover if the notice period allows it.
When switching is the wrong move
Sometimes the provider is not the problem. If your dissatisfaction is really about underinvestment, unclear priorities, or an internal team stretched too thin, a new logo on the same contract will disappoint you in the same ways within a year.
Two alternatives worth ruling out first. If you have a capable internal team that is drowning, a co-managed arrangement may fix the actual constraint without a disruptive switch. And if you cannot articulate specifically what the current provider fails to deliver, run an IT maturity assessment first. It turns “we are frustrated” into a concrete gap list, which either becomes your improvement plan with the incumbent or the sharpest RFP you have ever written.
Frequently asked questions
How long does it take to switch MSPs? Plan on 60 to 90 days from signed agreement to full cutover: roughly 30 days of preparation and discovery, 2 to 6 weeks of overlap, then cutover. Contract notice periods often set the floor, so start the internal preparation before the notice clock starts.
Will we have downtime during the transition? You should not. The systems themselves do not change during a provider switch, only who manages them. Downtime during transitions comes from access mistakes, usually revoking the old provider before the new one is verified, and the checklist sequence exists to prevent exactly that.
What if our current provider becomes uncooperative after we give notice? This is why credential and domain ownership get verified before notice. If you hold global admin, DNS, and your backups, an uncooperative incumbent can slow you down but cannot hold you hostage. Most contracts also include offboarding obligations, and a written request naming specific artifacts creates the paper trail to enforce them.
Do we have to move our Microsoft licenses? If licensing runs through the incumbent’s CSP agreement, the new provider transfers the billing relationship. Your tenant, data, and users stay exactly where they are. The transfer is routine, but it must be planned, so put licensing on the discovery list in week one.
Switching providers is a project, not a leap of faith. If you are weighing it, we are happy to walk through the checklist against your environment, including the honest conversation about whether fully managed IT services are what you actually need.
