Changing IT providers: what an MSP transition actually involves

Most organisations stay with an underperforming IT provider far longer than they should. Not because they are happy, but because the switch feels riskier than the status quo. Nobody wants to be the person who broke email.

That fear is mostly misplaced, but it is not irrational. A badly run transition genuinely can cause outages, lost licences and orphaned data. A well run one is uneventful. The difference is almost entirely in the preparation.

Here is what actually happens during a managed service provider handover, what gets audited, where the real risk sits, and roughly how long it takes.

Why organisations start looking

The trigger is rarely a single catastrophe. It is usually accumulated drift:

• Response times stretch. Tickets that used to be answered in an hour now sit overnight.
• Nobody is thinking ahead. You get break-fix support but no roadmap, no budget forecasting and no advice until something fails.
• Key person dependency. One engineer knows your environment. When they are on leave, nothing moves.
• Security has quietly fallen behind. Multi-factor authentication is partial, patching is inconsistent, backups have not been tested in a year.
• You cannot tell what you are paying for. Invoices arrive with line items nobody can explain.

If two or more of those are true, the cost of staying is already higher than the cost of moving.

What actually has to transfer

A transition is not just a change of phone number. Four distinct things have to move, and they carry different levels of risk.

Knowledge

How your environment is actually built. Network topology, server roles, application dependencies, integrations, the workaround somebody put in place three years ago that nobody documented. This is the piece most likely to be incomplete, because outgoing providers rarely have it written down either.

Assets and licences

Every device, its age, its warranty status and its replacement horizon. Every software subscription, its renewal date and, critically, whose tenant it sits in.

Credentials and access

Domain administrator accounts, firewall admin, switch management, hypervisor consoles, backup platform, DNS registrar, Microsoft 365 global admin. Everything the outgoing provider holds needs to be inventoried, transferred and then rotated.

Contracts

Hardware support agreements, maintenance contracts and warranty entitlements, with their actual coverage end dates. Lapsed coverage discovered after a failure is an expensive surprise.

The transition sequence

A structured handover runs roughly in this order.

1. Discovery and knowledge audit. Sessions with your team and, where the relationship allows, the outgoing provider. Automated discovery fills the gaps that memory misses.
2. Asset and licence inventory. A full picture of what exists, what it costs and when it expires.
3. Access mapping and credential rotation. Identify every privileged account, transfer control, then change the credentials. This step is non-negotiable.
4. Monitoring and tooling deployment. Agents, endpoint protection and backup verification go on before cutover, not after, so the incoming provider has visibility during the risky period.
5. Parallel running. Both providers have visibility for an agreed window. This is the safety net that makes transitions uneventful.
6. Cutover and documentation handover. Support channels switch, as-built documentation is issued, and the incoming provider owns the environment.

For a typical mid-sized organisation this runs to about 30 days end to end. Complex environments with heavy legacy dependency take longer, and it is better to know that upfront than to compress it.

Where the risk actually sits

In practice, transitions go wrong in a small number of predictable places.

• Credentials held only by the outgoing provider. If a firewall admin password exists nowhere else and the relationship has soured, you may be looking at a factory reset.
• Licences in the provider’s tenant rather than yours. This is the big one. If your Microsoft 365 subscriptions sit under the provider’s Cloud Solution Provider agreement, they own the commercial relationship, not you. Moving them is possible but it takes planning and timing.
• DNS and domain registrar control. Frequently registered by the provider years ago and forgotten. Losing control of your domain is significantly worse than losing an IT provider.
• Backups you do not actually own. Backup data sitting in a provider-owned platform may not come with you. Check retention and portability before notice is given, not after.
• Undocumented custom work. Scripts, scheduled tasks and integrations that only reveal themselves when they stop running.

Questions worth asking before you sign anything

• Whose name is on our Microsoft 365 tenant and our CSP agreement?
• Who is the registrant of our domain names?
• Can we get a full credential inventory, and will it be rotated at cutover?
• What is the parallel-running period, and who carries responsibility during it?
• What documentation do we receive at handover, and do we own it?
• What are the actual coverage end dates on our hardware support agreements?

A provider who answers these clearly is telling you something useful about how they operate. So is one who does not.

A reasonable expectation

A transition should be boring. Users should notice a new support address and very little else. If a provider is promising a same-week cutover, they are skipping the audit, and the shortcuts will surface later as incidents you pay for.

If you are weighing up a change and want a candid view of what your specific environment would involve, we are happy to talk it through without a sales process attached.