Switching IT providers gets talked about like it’s a major operation. It isn’t. Once a new provider has the right administrative credentials, the rest is methodical work that any competent team can handle in about a week, with a few weeks of cleanup behind it. The reason it gets framed as risky and complicated is usually because the people doing the framing benefit from the complication.
By the time a business is seriously considering a switch, the relationship has usually been deteriorating for months. Tickets take longer to close, recommendations stop arriving, small issues get patched instead of solved. The first thing worth doing, before any conversations start, is checking the existing contract. A lot of MSPs include 90-day cancellation notice requirements, framed as time needed for “offboarding support” and a “smooth transition.” That timeline makes sense for a 500-employee company with complex infrastructure and regulated dependencies. For an average 50-person business, it’s well beyond what the actual work requires. Knowing what’s in the contract before starting the conversation changes how the conversation goes.
The outgoing provider isn’t going to be enthusiastic about helping either, which is fair enough. A relationship that ended with the client choosing someone else rarely produces a generous handover. That’s the reality the process has to be built around, and once that’s accepted, the rest is just sequencing.
Step One: Administrative Account Control
The first priority isn’t documentation transfer. It’s control of the administrative accounts that actually run the environment. Domain registrar, Microsoft 365 global admin, Azure subscription ownership, backup console, line-of-business application admin accounts. Whoever holds those credentials holds the environment, regardless of what any contract says.
A quick distinction worth making, because it comes up. Most MSPs hold administrative accounts for the cybersecurity and management tools they deploy across their client base. That isn’t a lock-in tactic, it’s how the economics of reselling those tools work. A single central management system across many clients reduces licensing costs and makes administration practical. When a switch happens, removing those tools and having a new provider install theirs is something every MSP automates. It takes a few hours, not days. The accounts to focus on are the ones tied to the client’s identity, data, and core business systems.
In a cooperative handover, control gets transferred through a structured credential exchange. In a less cooperative one, new global admin accounts get established independently for the cloud environments, access is verified, and the outgoing provider’s access is removed. Sometimes that means moving quickly before the previous provider has any reason to make things difficult. It isn’t hostile, it’s protective.
The on-premise side is where the credential handoff from the outgoing provider really matters. Switch passwords, firewall passwords, server local admin credentials, anything that doesn’t tie back to a cloud identity. It’s certainly easier to have those handed over cleanly, but in worst case scenarios they can be reset and the configurations rebuilt by hand. It’s not ideal and it adds time, but it’s been done before. Knowing that ahead of time matters, because a global admin change in the cloud doesn’t magically solve everything on the local network. The independent audit later in the process is where any gaps from this step get caught.
Step Two: Independent Audit
Once control is established, the real work begins, and it usually doesn’t involve trusting whatever documentation was handed over. Client documentation, in practice, ranges from binders of outdated information to text files with no context. The critical “why” is almost always missing, because it typically lives in the heads of the techs at the outgoing provider. They rarely write that stuff down. Why is this firewall rule in place? Who actually uses this shared mailbox? What does this scheduled task do, and what breaks if it stops running? Those answers walked out the door with whoever set things up, and the documentation that gets handed over is whatever was left behind. Everything that gets handed over ends up discarded after initial review anyway, because each provider’s documentation is a reflection of how they operate. Documentation gets rebuilt to match the new support delivery model, tailored to the client’s actual needs.
This is honestly the hardest part of the whole switch. Not because the systems themselves are difficult, but because no documentation ever contains the context that explains them. Reconstructing the “why” takes three parallel tracks. Conversations with the people who actually use the systems, asking what works, what doesn’t, and what workarounds have become part of daily routine. Digital discovery through network scans, cloud tenant audits, identity and access reviews, license inventories, and backup verification, which is where the actual environment reveals itself, often quite differently from what anyone documented. And tracing how cloud environments talk to each other, which app registrations have permissions to what, which automation accounts run which workflows, which third-party integrations are quietly authenticated against the tenant.
End users always know more about the real state of an environment than any documentation captures. The technical environment itself is rarely the puzzle. The puzzle is understanding why it was set up the way it was, and that answer almost always lives with the people who’ve been using it, not in any file that gets handed over.
Step Three: Vendor Relationship Rebuild
The genuinely time-consuming part of switching IT providers isn’t technical at all. Most setups are straightforward, requiring some tuning and occasional cleanup but rarely anything dramatic. The hard part is the third-party vendor relationships.
The accounting software support contract. The ERP vendor’s technical contact. The engineering systems provider who needs to know who’s authorized to call. The line-of-business applications that have their own support agreements, account numbers, escalation paths, and authorized contact lists. Every vendor needs to be contacted, account access verified, contact records updated, support procedures documented. Some vendors are responsive. Others require multiple calls.
This is what stretches a one-week transition into a one-month one. None of it is technically difficult, but it’s methodical and can’t be rushed. The previous documentation almost never helps, because vendor relationships are personal. They live in someone’s email, someone’s phone contacts, someone’s memory of who was helpful the last time something broke. This is the part of a switch that takes real time, and it’s worth setting expectations around it early.
Step Four: Look at the Business Side Honestly
This one is uncomfortable but worth saying. There are always three sides to every story. The client’s side, the previous provider’s side, and what actually happened. Once a relationship starts breaking down, the gap between reality and whatever’s being said about it gets wide in a hurry.
Time and again, we see environments with strange recommendations baked in. Configurations that don’t match the business, tools that were never going to fit how the team actually works, architectural choices that made sense for the provider but not for the client. Once that kind of divergence starts, a future IT support vendor change is almost a foregone conclusion. The mismatch builds quietly until something forces the issue. Part of the audit work is figuring out where things went sideways, so the same thing doesn’t start happening again under new management.
This isn’t about assigning blame. It’s about getting a sober view of how technology decisions were being made, and making sure they get made differently going forward. The goal is alignment between what the business actually needs and what it’s being told it needs, with enough context that real decisions are possible. Controlling the administrative accounts is important, but understanding the decision-making process is what actually makes the new relationship work from day one.
Step Five: Build for Portability From Day One
The real measure of a clean switch isn’t how well this transition goes. It’s whether the next one can be done without having to rely on the outgoing provider to explain who controls what. The right framing is direct control. What does the client need to be in direct control of, and what’s reasonable to leave with the provider?
Some things should sit under the client’s name without exception. Microsoft 365 tenants, domains, core business application licenses, anything tied to identity, data, or revenue-generating systems. Other things will reasonably stay with the provider. Website hosting under the provider’s account, cybersecurity tooling licensed centrally, monitoring platforms running on shared infrastructure. None of that is inherently wrong, but it does require documentation. A clear internal record of what the client owns directly, what the provider holds on their behalf, and what would need to happen to move each piece if the relationship ever changed.
That documentation is the roadmap. It turns the ownership question from a vague concern into something concrete that anyone can pick up and act on. The conversation about what should be owned where should be driven by one question. How portable is this, and what would it take to move it?
And the punchline is this. That documentation shouldn’t live with the IT provider. It should live with the client. A provider who maintains the only copy of the ownership map is a provider you have to ask permission to leave. The roadmap belongs to whoever needs it most when things change, and that’s never going to be the provider.
The Realistic Timeline
A switch handled properly, with reasonable cooperation from the outgoing provider, takes about a week for the core transition and another two to four weeks for vendor relationship reconstruction and audit work. A switch handled in adversarial conditions takes about the same total time but spends more of it on the front end establishing control. Either way, no heroics required.
Secure the administrative accounts, run a proper audit instead of trusting the documentation, rebuild vendor relationships methodically, and set up the new environment so the client genuinely owns it. None of this is hard. The only thing that makes it look hard is when someone tells you it is.