Changing MSPs is one of the riskiest things an IT team does. For a few weeks, one provider is leaving and another is learning, and anything that isn't written down can fall through the gap.
Secure the keys first
Before notice is given, make sure your organisation holds the admin credentials for every critical system: Microsoft 365 and Azure global admin, domain registrar, DNS, firewalls, backup platforms, licensing portals and vendor support accounts. If the outgoing provider holds the only admin account for something, fix that first.
Get the documentation you are owed
Check your contract for what the outgoing provider must hand over. Ask for network diagrams, asset lists, configuration backups, runbooks, open tickets and known issues. Expect gaps, and plan for the incoming provider to rebuild documentation from discovery.
Plan the overlap
An overlap of a few weeks lets the incoming provider shadow the outgoing one, ask questions and take over services one at a time. Agree who handles incidents during the overlap, so nothing is dropped.
Rotate and remove
Once services have moved, rotate every credential the outgoing provider knew, remove their accounts and remote access tools, and review who has privileged access. Check for forgotten items: service accounts they created, scheduled tasks running as their accounts, API keys and delegated admin relationships.
Stabilise
In the first month, the incoming provider should confirm backups run and restores work, put monitoring on critical systems, check certificate and licence expiries, and patch the most exposed systems. Findings go on a risk register rather than being fixed all at once.
Decide what the new provider does
A provider change is a good moment to split responsibilities more sensibly. Many organisations keep a provider for the service desk and devices, and bring in an engineering partner for cloud, security and infrastructure. Write the split down in a responsibility matrix before go-live.
Changing IT provider? Provider transition
All resources