Resource
How to switch IT providers without creating chaos.
Most businesses stay in underperforming IT relationships longer than they should because leaving feels more dangerous than staying. It usually isn't. Here's what the transition actually looks like.
Why switching feels harder than it is.
The fear makes sense. Your IT provider has administrative access to everything. They know the environment. The idea of removing that and handing it to someone new feels like significant operational risk.
The reality is simpler than most businesses expect. A new provider doesn't need your old provider's documentation, their diagrams, or their notes. They need credentials. Everything else gets rebuilt during onboarding. To the new provider's standard, not inherited from whoever came before.
The businesses that have the hardest transitions are usually the ones who stayed too long, tried to change too much at once, or chose a new provider who didn't have a clear onboarding process. None of those are problems with switching. They're problems with how it was done.
What you actually need to hand off.
The environment belongs to the business. The credentials belong to the business. The data belongs to the business. The outgoing provider has access. They don't have ownership.
The handoff list is shorter than most businesses expect.
Domain registrar access and DNS control. Your domain is the foundation of email, your website, and most cloud services. If you don't know where it's registered or who controls the login, that's the first thing to find out. Before you tell the outgoing provider you're switching.
Microsoft 365 global admin credentials. Not a delegated account the provider controls. Actual global admin access under accounts the business owns.
Firewall and network equipment credentials. If the provider owns the hardware rather than the business, that's a contract conversation before the transition begins.
All vendor and third-party account credentials. ISPs, line-of-business applications, cloud platforms, backup services.
That's the list. A competent incoming provider can work from those credentials and build the rest themselves. Documentation, network diagrams, asset inventories, configuration records. All of that gets produced during onboarding to the new provider's standard. You don't need it from the outgoing provider and you shouldn't rely on it if you get it. You don't know how current it is, how accurate it is, or what standard it was built to.
What to look for in a new provider before you switch.
The most important question to ask any provider you're evaluating is: walk me through your onboarding process.
A provider who has done this before has a documented, step-by-step plan. They can tell you what happens in week one, what gets verified in week two, what the environment looks like at day thirty and day sixty. They can tell you what documentation they produce, what standard they hold the environment to, and what you should expect to see at the end of onboarding.
A provider who is vague about onboarding is telling you they treat every transition as a new problem to figure out. That's not a process. That's improvisation.
The onboarding process should produce specific outputs. A documented inventory of every system and device in the environment. Verified backup status with a tested restore. Security settings reviewed and brought to the provider's standard. Access controls audited. Former employees removed, admin accounts reviewed, MFA verified. Vendor relationships documented under business-owned accounts.
At the end of onboarding you should know more about your environment than you did when you started. If the provider can't describe what that picture looks like before you sign anything, ask a different provider.
What to do about the outgoing provider.
Most outgoing providers cooperate. Their reputation depends on it and most understand that businesses change providers. The handoff is professional, credentials are transferred, and the transition proceeds.
Some create friction. A provider who knows they're being replaced may slow-walk credential transfers, be vague about account access, or make the process harder than it needs to be.
A few things worth knowing if that happens.
Secure your credentials before you announce the switch if you can. Once a provider knows they're being replaced, the dynamic changes. If you already have global admin access to your Microsoft 365 tenant and control of your domain registrar, the outgoing provider's cooperation becomes less critical.
You don't need their documentation. If they won't produce it or it takes months to arrive, it doesn't matter. The incoming provider will build their own.
State clearly and in writing that the credentials and access belong to the business and you expect them transferred on a specific date. Most providers comply when the request is direct and documented.
Don't cancel existing access before the new provider has verified everything. A brief overlap, typically a week or two, where the new provider has confirmed access to all systems before the old provider's access is fully revoked eliminates the risk of gaps.
What the transition actually looks like.
Before the switch
The new provider audits what's in place using the credentials you've provided. This happens while the current provider is still active. Nothing changes until the incoming provider has a clear picture of what exists and what needs to happen at cutover.
The cutover
Admin accounts get rotated so the outgoing provider's access ends cleanly. The new provider's monitoring gets stood up. Support coverage is established before the old provider's access is revoked. There's no window where nobody is watching the environment. Staff get a clear communication: who to call, how to reach them, what to expect.
The first thirty to sixty days
The new provider is in discovery and documentation mode. They're asking questions, mapping the environment, verifying every system, and building documentation to their standard. This is normal. The questions aren't a sign something is wrong. They're the work that produces an environment the provider actually knows rather than assumes.
For most businesses in the 25 to 250 employee range, the cutover itself takes a day. The onboarding period, where the environment gets fully documented and brought to standard, takes four to eight weeks depending on complexity.
The mistakes that actually cause chaos.
Announcing the switch before you have credentials secured. Once the outgoing provider knows they're being replaced, the dynamic changes. Have global admin access and domain control confirmed before the conversation happens.
Trying to change everything at once. The transition is not the time to migrate platforms, upgrade the network, or implement new tools. Stabilize first. Improve after. Doing both simultaneously makes it impossible to know what caused any problem that comes up.
Not communicating with staff. The biggest source of day-one friction isn't technical. It's employees who don't know who to call. One clear internal message before cutover eliminates most of it.
Relying on the outgoing provider's documentation. It may be incomplete, outdated, or built to a standard the new provider doesn't use. The incoming provider should build their own from scratch.
What changes after a well-run transition.
The first few weeks involve more questions than usual as the new provider learns the environment. That's the onboarding process working correctly.
After that period, the environment is documented to a known standard. Access reflects who actually works there. Backups have been tested. Security settings have been reviewed and brought to a current baseline. The provider knows the environment because they built the documentation themselves. Not because they inherited someone else's notes and hoped they were accurate.
If you're considering a switch and want a clear picture of what your environment actually looks like before you make any decisions, that's exactly what an IT Environment Review is for.
Common questions
Questions leadership usually asks first.
Continue reading
Related work and reading.
What Should Be in a Managed IT Contract
The exit and ownership language that matters most when you eventually switch again.
Read more: What Should Be in a Managed IT ContractIT Environment Review
Know what's actually in place before you commit to a new provider.
Read more: IT Environment ReviewManaged IT Services
What the environment should look like after a properly run transition.
Read more: Managed IT ServicesNext step
Get a clearer view of your IT environment.
Find out what is working, where the risks are, and what needs attention next.