Switching IT providers without disruption

Switching IT providers runs without disrupting operations when three things are settled before you give notice: complete documentation is in hand, every access point is known and transferable, and the handover follows a planned sequence instead of happening all on one cutover date. Most problems during a switch aren't caused by the new provider – they come from knowledge and access sitting with the old one that was never documented anywhere.

What should you request from your current provider before you give notice?

The right time to ask is before giving notice, not after – while the contract is still running, the duty to cooperate is usually clearer and the relationship tends to still be constructive. What you should ask for is everything that describes and enables the operation of the infrastructure: a current network diagram, a list of all systems and licences in use, all administrative credentials, and an overview of any ongoing contracts with vendors or providers that were set up through the provider.

• A current network diagram covering all sites, devices and connections
• A complete list of hardware and software in use, including licence keys and terms
• All administrative credentials (router, firewall, servers, domain, email, backup)
• An overview of ongoing third-party contracts (internet connectivity, domain, certificates, cloud services) run through the provider
• Documentation of any custom configurations and known open issues

How much time should you allow for the switch?

A clean switch is rarely something you can wrap up in a few days once it involves more than simply handing over credentials. Between the initial stock-take, cross-checking it against the documentation, the staged takeover and finally disabling the old access, it usually takes several weeks – depending on the size of the infrastructure and how cooperative the previous provider is, sometimes longer. Setting a realistic timeline from the outset avoids the pressure to skip critical steps just to hit a self-imposed deadline.

Who actually owns the accounts and domains?

A common pitfall: the domain, SSL certificates, cloud accounts or even the firewall licence formally sit under the previous provider's account, not the company's own. This usually goes unnoticed during day-to-day operation, but becomes a problem during a switch when access suddenly isn't there or the previous provider stops responding. That's why it's worth taking stock before any switch: which accounts, domains and licences sit under whose name, and where does that need to be sorted out before the relationship ends?

How does a handover run without disrupting operations?

A single "big bang" handover – lock the old access, activate the new access, all in one day – is the highest-risk approach. A staged approach works better: first the new provider builds a complete picture of the existing infrastructure and cross-checks it against the handed-over documentation. Then non-critical systems get taken over first, with critical systems such as the firewall, servers and backup last, and with a clear fallback plan in case something doesn't work as expected.

1. 01Stock-take: the new provider cross-checks the documentation against the actual infrastructure
2. 02Access credentials for every system are rotated as soon as they're taken over
3. 03Non-critical systems get taken over first, to test the process
4. 04Critical systems (firewall, servers, backup) get taken over with a defined fallback plan
5. 05Old access only gets disabled once the new access has been shown to actually work

What are the most common pitfalls in practice?

Beyond missing documentation and unclear account ownership, a handful of problems keep coming up. Backups that ran regularly but were never actually tested for restorability – that often only comes to light once they're genuinely needed during the handover. Notice periods that turn out to be much longer than assumed, which pushes the whole timeline back. And systems that are still running, but where nobody quite remembers what they're actually for – a leftover from an earlier configuration that stays untouched, out of caution, rather than being questioned.

• Test backups for actual restorability before the switch, not just successful completion
• Check the notice period early and build it into the timeline
• Clarify unclear or unused systems as part of the handover instead of taking them over untouched
• Actively push for a handover meeting between the old and new provider, not just an exchange of documents

What if the current provider doesn't cooperate?

Not every switch runs cooperatively. If documents or access aren't handed over, it helps to check beforehand what the existing contract says about the duty to cooperate at the end of the relationship – a handover is often provided for, at least in outline. In parallel, the new provider can already start working with whatever's available within the company itself: anything under the company's own control (such as access to its own domain registration) should be secured in any case before notice is given. In stubborn cases, the only option left is often to reconstruct the missing information through an on-site technical assessment – more work than a proper handover, but doable.

What should be set up differently in the new contract from the start?

A switch is a good opportunity not to end up in the same situation again in a few years. That means anchoring the documentation obligation firmly in the contract from the start, rather than assuming it as a given – having it in writing gives you something to point to if there's ever a dispute. It's equally worth agreeing upfront that central accounts such as the domain, certificates and cloud services stay registered under the company itself rather than the provider, along with a clear rule for what documentation and access get handed over if the contract ends in future.

• Agree on a documentation obligation (current network diagram, credentials, system list) as a fixed part of the contract
• Register central accounts (domain, certificates, cloud services) under the company from the start, not the provider
• Define an exit clause: which documents and access get handed over on future termination, and within what timeframe