3 September 2026LANTEK Computers
Most businesses that are unhappy with their IT provider stay put, and it is rarely because they think the provider will improve. It is because the switch looks like a week of chaos that nobody has a spare week for, and because there is a quiet worry that the outgoing provider holds something you cannot get back.
That second worry is the one worth taking seriously. The rest is logistics, and logistics can be sequenced.
The single question that determines how hard this will be
Do you own your own accounts?
Specifically: are the domain name, the Microsoft 365 tenant, the website hosting and the DNS registered to your business, with an administrator login that a director can reach without asking anybody’s permission?
If the answer is yes, changing provider is an ordinary handover and everything below is straightforward. If the answer is no, or is really we assume so, that is the first thing to establish, before you have any conversation about moving. Not because a provider will necessarily be difficult, but because discovering the answer during a migration is the worst possible time.
This is worth checking even if you have no intention of moving. A business that cannot reach its own domain registrar has a continuity problem that has nothing to do with how happy it is.
Before you give notice
Do this part while the relationship is still normal. None of it is provocative, and all of it is reasonable for a business to ask about its own systems.
Read your agreement for the exit terms
Notice period, minimum term, and whether there is anything described as an offboarding or handover fee. Also look for what happens to any licences bought through the provider, because those sometimes sit on the provider’s agreement rather than yours and cannot simply transfer.
Establish where the asset register is
Ask for a current list of what you own and what is under support: machines, ages, warranty status, servers, network equipment, licences and quantities. A provider running a real managed service produces this quickly, because they already maintain it. If it takes a fortnight to arrive, that tells you something about the service you have been buying, and it is also a reason to start earlier.
Confirm the backup position yourself
Not that backups are running. That somebody has restored from them. Ask when the last restore test was and what was restored. If the answer is vague, treat the backup as unproven until your new provider has verified it, and do not schedule any migration work until that is done.
Get the recovery contacts pointed at you
Password reset addresses and recovery phone numbers on your critical accounts should reach somebody who works for you. This is the quietest and most important item on the list.
The sequence that keeps the business working
The principle is simple: the new provider learns and prepares while the old one is still running things, and nothing user facing moves until it has been rehearsed. Overlap is not waste. Overlap is the whole plan.
One. Discovery, while the incumbent is still in place. The new provider documents what exists: systems, versions, who does what, which processes are unusual, what breaks regularly. Expect this to surface things nobody wrote down, because that is its purpose.
Two. Get monitoring on before anything changes. Putting monitoring and endpoint agents in place early is low risk and high value. It gives the incoming provider real information about how the estate actually behaves rather than how it is described, and it means the first day of responsibility is not also the first day of visibility.
Three. Take custody of the accounts. Administrative access, domain, DNS, tenant, hosting, and the licence agreements. This is the point at which control genuinely transfers, and it should happen deliberately rather than as a side effect of something else.
Four. Fix the backup before you touch anything else. A verified restore, done and recorded, before any migration work starts. If something goes wrong later, this is what you fall back on. Doing it in this order is not caution for its own sake.
Five. Rehearse the user facing move. Mail, files and identity are what staff notice. Whatever the plan is, it gets tested on a small group first, on a normal working day, with a way back.
Six. Cut over out of hours, in stages. Not everything on one night. Mail one weekend, files another, with a working week in between to catch what the rehearsal missed.
Seven. Hypercare, then handover. A couple of weeks where somebody expects to be interrupted, then a formal close with the documentation handed to you rather than kept.
Eight. Give notice and close the old agreement. Last, not first. Once you are running on the new arrangement and nothing is outstanding.
That order does put you paying two providers briefly. It is worth it. Reversing steps one and eight is the single most common way these projects go wrong.
What genuinely does interrupt people
Being straight about this is more useful than promising a seamless move.
Mail clients need reconfiguring. If mailboxes move, staff will spend some part of a morning putting a password in and waiting for a mailbox to download. Plan for it rather than pretending it away.
Multi-factor authentication gets re-enrolled. Everybody re-registers their phone. It is quick and it is universal, so do it as a scheduled exercise with somebody available.
Printers and scan to email. Reliably the thing that turns out to have been configured by somebody who has left. Test every device, especially anything that scans to a folder or an address.
Line of business software with a licence tied to a machine. Accounting packages and anything industry specific. These need checking with the vendor before the machine changes, not after.
Whatever runs on the one old server. Most businesses have something. Find it during discovery.
Signs the move is being done properly
You should see a written plan with dates and an order of operations. You should be told what the fallback is at each stage. You should be given the documentation at the end, not told it exists. And somebody should have restored from your backup and told you what they restored, before anything else happened.
If a provider tells you the whole thing can be done over one weekend with no user impact, ask them to describe the fallback. The answer will tell you whether they have done this before.
The part people do not expect
A migration is the best opportunity you will get to fix the things that have been annoying everybody for years, because the estate is being documented and touched anyway. Access that was never tidied up, the shared folder nobody understands, licences being paid for by a business that no longer needs them, the leaver accounts still active. It is much cheaper to deal with those during a move than to schedule a separate project afterwards.
If you want to know what a handover should include before you commit to anything, ask us and we will walk you through the plan we would put in place for your situation. What a managed service should cover once the move is done is set out on Managed IT Services.