Get your keys back first. Then switch IT companies.

Start with the keys, not the quotes

Most owners who decide to switch IT companies start by calling around for quotes. That’s understandable, and it’s the wrong first move. The order that works is this: get administrator access back for every system that matters, let the new provider set up their own access, run both companies side by side for about 30 days, test a restore, and only then cancel the old contract. Done in that order, a switch is mostly paperwork. Done the other way round, you can spend weeks asking a vendor who no longer has any reason to hurry for the passwords to your own email.

If I could make one rule for every small business, it would be this: no single vendor, and that includes us, should ever be the only holder of your admin keys. If you can’t sign in to your own Microsoft 365 tenant today as a Global Administrator, that is the first thing to fix, whether or not you ever switch.

Before you say a word, try to log in

Before you tell anyone you’re leaving, check quietly. Sit down with a coffee and try to log in to each of these with an account that belongs to your company, not to a technician at your IT company.

1. The Microsoft 365 admin center (admin.microsoft.com) or the Google Admin console (admin.google.com).
2. Your domain registrar (GoDaddy, Network Solutions, Namecheap or whoever holds it). Note which email address receives the renewal notices.
3. Your DNS host. Often the same as the registrar, sometimes Cloudflare or the web host. This is where your email records live, so losing it is a pretty big deal.
4. The backup console. Can you see the date of the last successful backup, and could you start a restore?
5. The firewall and Wi-Fi management login, and whether that management portal is in your name or theirs.
6. Accounting, the phone system, your website hosting and any line-of-business software.

Write down what you got into and what you didn’t. The gaps are your real to-do list, and in my experience running JLB for more than 15 years, there are usually more of them than the owner expected.

Why access drifts away from the owner

The premise of a managed IT contract is sensible: you pay someone to look after your systems so you don’t have to think about them. The catch is that “not having to think about them” slowly turns into “not knowing where they are.” The domain was registered years ago by a technician, using his own email address. The firewall is managed from the IT company’s portal, under their license. The backups go to a cloud account billed to them. None of that needs to be sinister. It was convenient at the time, and convenience piles up.

A real one, with the names left out: a 22-person professional-services firm came to us after recurring support delays with its managed IT provider. The hard part wasn’t moving the laptops. It was establishing who actually controlled Microsoft 365, the domain registrar, DNS, the firewall and the backup console. The departing provider had been the only global administrator on the tenant, and the registrar account used an email address at the provider’s own domain. Before cutover we made an inventory of every administrative dependency, had the owner formally authorize the transfer, set up a customer-owned global admin and a break-glass account, and transferred the registrar through the proper ownership process. We exported the firewall settings and checked that we had restore access to the backups before anything was retired. For a short period both providers had defined responsibilities, and we removed the former provider’s delegated access only after the new credentials, MFA and recovery paths had been tested. Nobody’s email address changed and service wasn’t interrupted. If I had to boil it down to one piece of advice: ask for an access inventory and proof that you own your backups before you give the incumbent notice.

To be fair to IT companies, some tools really do belong to them. Their remote-management agent and much of their security software are licensed to the provider, and when the provider goes, those tools go too. That’s fine as long as you know in advance, because the new company has to install replacements before the old ones come off. The one that bites people is backup. If the old provider’s backup product leaves with them, your backup history may leave with it, so ask now what happens to the retained copies and for how long.

The steps I’d give a client who wants to switch

1. Read your agreement. Find the notice period, the termination clause, and whether there’s any promise of transition help. Our guide to the managed services agreement covers what those clauses usually look like.
2. Get your own admin access. For Microsoft 365, Microsoft recommends two or more emergency access (“break glass”) accounts: cloud-only, on your .onmicrosoft.com domain, not tied to any one person’s phone, protected with a passkey such as a FIDO2 security key, and tested at least every 90 days. Ask the current provider to set them up with you watching. In Google Workspace, make sure a super admin account belongs to the company and that an owner knows how to reach it.
3. Fix the domain. Move the registrar account’s contact email to a company address and get the login into the hands of an owner. If you plan to move the domain to a different registrar, ask before editing the registrant details, because under ICANN’s current transfer rules a change of registrant can trigger a 60-day transfer lock (some registrars let you opt out, so ask them first).
4. Collect the paperwork. A list of users, devices and licenses; the network layout; firewall and Wi-Fi settings; every vendor you depend on (internet, phones, printers, software) with renewal dates. A decent IT company has this already. If they don’t, that tells you something about why you’re leaving.
5. Sign with the new provider and let them onboard before the old one leaves. They install their tools, get their own named admin accounts (never a shared login), and take their own inventory. In Microsoft 365, a new partner usually asks for delegated access through a GDAP relationship, which you approve and can remove later.
6. Overlap for about 30 days. Both companies have access. The new one takes the tickets; the old one stays on call.
7. Test a restore with the new backup before the old backup is switched off. Restore an actual file and an actual mailbox, not a status screen that says “healthy”.
8. Sort out licenses. If your Microsoft 365 subscriptions are billed through the old provider, ask both companies exactly how and when they move. Licenses that lapse leave you with staff who can’t sign in on a Monday morning.
9. Cancel in writing, then remove access. In the Microsoft 365 admin center, go to Settings, then Partner relationships, and remove the old provider’s roles. Delete their admin accounts, change every password they knew (firewall, Wi-Fi admin, registrar, local administrator accounts), and uninstall their agents once the new ones are confirmed working.

The last step is the one people skip, which is a little like changing the locks on the front door and leaving the back door key under the mat. For the wider version of this list, the employee offboarding checklist works surprisingly well for an outgoing vendor too.

Worked example: the overlap month for a 40-person office

This is an illustration, not a client story. Picture a 40-person firm with Microsoft 365, laptops, a cloud-managed firewall, a hosted phone system and QuickBooks Online. Their contract has a 30-day notice period.

• Before notice, the owner confirms admin access to Microsoft 365, the registrar and DNS. Two emergency access accounts are created. Documentation is requested.
• Day 1: written notice goes to the old provider, so the contract ends on day 30. The new provider is signed the same week.
• Days 2 to 7: the new provider’s agent goes onto 40 laptops, GDAP is approved, their backup starts running alongside the old one.
• Days 8 to 25: tickets go to the new provider. This window takes in a month-end close, a payroll run and Microsoft’s monthly security updates (released on the second Tuesday of each month), which is exactly why 30 days is the right length.
• Days 26 to 30: restore test, license move, old access removed, old agents uninstalled.

The cost of doing it this way is roughly one month of paying two companies. I think that’s cheap. The alternative is a gap of a week or two in which nobody is responsible for your systems, and things have a way of breaking precisely then.

Should you tell the current provider early?

Yes. Some owners want to keep it secret until the new company is fully in place, but that rarely works: new software appears on every computer and new accounts appear in the tenant, and the old provider will notice. It’s also simply easier to ask for passwords and documentation while the relationship is still friendly. Most IT companies handle a departure professionally. The few that don’t are the reason you sorted out your admin access before saying a word.

Not sure what you’d find if you tried those logins? Our free Technology Health Assessment does it with you. It takes 30 minutes of data collection, and the next day you get a plain-language report that rates each area, including which systems you control and which are simply “unknown”, with a short list of next steps in order. The report is yours to keep whether or not you ever work with us. Pick a time for the assessment.

What a good handover looks like from the other side

When we take over managed IT for a company, the first thing I want to see is that the owner holds a working admin account of their own, not that we do. We can work alongside an existing IT person or a departing provider during the overlap, and we would rather inherit an untidy setup with clear access than a tidy one nobody can log in to. If you ever leave us, you shouldn’t need our permission to get into your own systems, and I’d hold any IT company to the same standard.

Related services

• Managed IT services
• Free Technology Health Assessment
• What's in a managed services agreement
• Backup and disaster recovery for small business