Changing IT Providers Without Breaking Anything

The order matters more than anything else here. Everything is easier to obtain while the relationship is normal and everybody is still being helpful, and much harder the day after you have told somebody you are leaving. So the audit comes first, quietly, framed as ordinary housekeeping, because that is what it is.

Written down, the audit answers one question for every part of your setup: are you the account holder, and can you get in today without asking anybody. Not whether you could probably get access if you asked. Whether you can log in this afternoon.

This article is written so it would be useful to somebody leaving us. That is deliberate. A provider who cannot describe a clean handover is a provider who is relying on the handover being messy, and we would rather publish ours than have you find out about it at the end.

The domain name is first and it is the one most often held by somebody else. Find out which registrar it sits with, whether your business is the registrant, and critically which email address the registrar contacts about renewals and transfers. If that address belongs to your provider, they control your domain in practice regardless of what the registration record says.

Then the ones underneath it. Control of your DNS records, which may be somewhere else entirely. The root account of any hosting or cloud platform. An administrator account in your identity or email tenant that is in your own business's name, held by you, with its recovery details pointing at somebody who works for you. The backup system's own console. Wherever any custom code or website is stored. The certificate provider. The phone system's administration portal. And the card the renewals charge to.

For each one, log in. Actually log in, today, and change nothing. Discovering that a password does not work is a small problem this month and a serious one during a handover. Where you cannot get in, that is the list you need to work through first.

Make sure at least two people at your business can reach each of these, and that the second factor is not tied exclusively to one person's phone. That is good practice regardless of whether you ever change provider, which is a reasonable way to raise it if you would rather not signal anything yet.

This is the one that catches people, and it does its damage silently. The tools that manage your machines, the monitoring, the patching and the security software are frequently licensed to the provider rather than to you. On the day the contract ends, the agents stop reporting. The machines carry on working perfectly, and stop being patched, and nobody notices for months.

Subscriptions are the other version. Many providers hold your subscriptions as the reseller of record, which is a normal arrangement and not a trap in itself. It does mean the billing relationship is theirs, and moving it to you or to somebody else is a process with its own steps and its own timing. Find out now what that process is rather than during the last week.

So ask for a plain list. Every product in use, who holds the contract, what it costs, when it renews, and whether it transfers. Ask during a renewal conversation, where it is an entirely normal question. Then read it for the things that stop working rather than the things that cost money, because those are different lists and the first one is the dangerous one.

Whatever you find, make sure something covers the gap on day one of the new arrangement. A fortnight of unmanaged, unmonitored machines between two providers is the most avoidable risk in the whole exercise.

Ask for the documentation before you give notice, framed as wanting a copy for your own records. Most contracts entitle you to it. What arrives after notice is often thinner and later than what arrives before.

Read what you get with one question in mind: could a competent engineer who has never seen your business work from this. Look for the supplier contacts, the account numbers, the reasons behind unusual configurations, and the awkward corners. A folder of network diagrams is not documentation, it is a picture of a network.

The bigger risk is the part that was never written. Every provider carries knowledge in its engineers' heads, and that is the material you lose completely the day the contract ends. While things are still cordial, get time with the engineer who knows your setup best and take notes yourself. Ask what they worry about, what they would tell a replacement, and what they have been meaning to fix. People answer that question generously, and it is worth more than the documentation.

Read the exit terms and the notice period properly first, including whether handover assistance is included or charged, and whether there is a fee for anything. Know that before you start the conversation rather than discovering it in a final invoice.

Then propose the handover as a document. A named person on each side. The list of accounts and credentials that transfer, and by when. The licences and subscriptions that move, and how. The documentation that comes across. An overlap period where both parties are still engaged, and who pays for what during it. How the final invoice works, and what happens to anything paid in advance. Get that agreed, in writing, and only then serve notice.

Doing it in that order changes the tone of the whole thing. You are asking a supplier to agree a normal commercial process, not asking somebody you have just sacked for a favour. Most providers behave well. The ones that do not are much easier to handle when there is an agreed document to point at.

Involve the incoming provider in writing that document. They have done this before, they know which items get forgotten, and their questions will be more specific than yours.

Nothing needs to move on the first day, and moving everything at once is how businesses end up down for a morning during a change that had no technical reason to break anything.

Start by transferring access and finishing the inventory, which changes nothing operationally. Next move backup and monitoring, so the new team can see what is happening and you are protected before anything else is touched. Then the tools that manage the machines, which usually means removing one agent and installing another, done in small groups rather than everywhere at once.

Identity and email come after that, because everything else depends on them and you want the new team fully able to see the estate before they touch the thing that logs everybody in. The perimeter and the DNS come last. Lower the DNS time to live values well in advance so that changes take effect quickly, and put them back afterwards.

Every step should be reversible on its own, and each should be followed by a pause long enough for problems to surface. A migration where the second step happens before anybody has noticed the first step broke something is a migration that ends with a long night.

System alerts still arriving at the old provider's inbox, so nobody at your business sees them and everybody assumes somebody does. That one can run for months.

A second factor on a former engineer's phone. Recovery codes stored in a vault you no longer have. A scheduled job or an integration running under an account that gets disabled during tidying up, which fails silently at the weekend. A certificate that renews automatically through their account and now does not. An auto renewing subscription that charges you next month for something you have already stopped using.

The backups deserve their own attention. When a contract ends, the historical backups often live in the outgoing provider's platform, and retention can end with the relationship. Agree in writing how long they keep them and how you would get data back during that window. Where the history genuinely matters, take your own copy before the last day rather than trusting the arrangement.

Go looking for these deliberately in the weeks after the switch rather than waiting for them to announce themselves. Most of them announce themselves badly and late.

Before any of this, be sure the provider is the problem. A fair share of unhappy relationships are a scope that was bought too thin, a price tier that was never going to cover what you expected, or one difficult person in a business full of reasonable ones. If that is the case, you will pay the full cost of switching and arrive at the same service under a new name.

So have one direct conversation with whoever owns the business rather than with your account contact. Describe what is wrong in specifics. Plenty of these conversations end with a rewritten scope and a different engineer, at a fraction of the cost and disruption of a change.

If you do decide to move, move politely. Pay the final invoice. Give the notice you agreed. Thank the engineers, who are usually not the reason you are going. Three months later you will hit something nobody documented, and whether somebody takes your call depends entirely on how the last week went.

And if you are leaving us, this is what happens. You own the code and the accounts, so they come to you. The documentation comes with them. Administrator access transfers to whoever you name, and we will sit down with the incoming team to hand over what was never written down. We would rather you left well and came back than left badly and told people why.