Where the fear of switching comes from
Start with the sentence that comes up in almost every conversation like this. The old team holds every password, knows the whole network, and if they take offence we are left with infrastructure nobody understands.
That fear is not silly. It is simply pointed at the wrong thing. The problem is not technology, because the hardware and the systems stay exactly where they are. The problem is information. Who holds the list of accounts? Who knows why a particular firewall rule was created in the first place? Where does the newest copy of the data actually sit? Whoever holds that knowledge is in control.
The good news is that information can be moved, in order and under control. Changing an IT provider is a project with a checklist, not a leap of faith. What follows is that checklist, in the order worth working through.
Start with an inventory of access
Before anyone switches anything, write down every administrative account the company has. This is not about passwords yet. It is about the list of doors a password opens.
- the domain and DNS, together with access to the registrar panel,
- mail and the office suite, meaning the global administrator in Microsoft 365 or Google Workspace,
- servers and virtualisation, meaning domain administrator accounts, local accounts and the vSphere or Hyper-V console,
- the network, meaning switches, access points, the firewall, VPN and accounts on carrier portals,
- data, meaning the backup console, storage arrays, NAS devices and cloud subscriptions, together with whose name they are billed under,
- the things people forget, meaning monitoring, cameras, door access control, the phone system and vendor licence portals.
Then add a second question to every line, and it matters more than the first one. Who else still has this access? The answer very often includes a former employee, a subcontractor from 2019, and one account called admin whose password is known to half the company and to the whole previous team. Access like that cannot be revoked. It can only be changed.
One trap deserves a sentence of its own. If the second login factor for an administrative account arrives on the private phone of someone from the old provider, or on their e-mail address set as the recovery address, the password alone is worthless. Check this line by line.
The documentation that usually does not exist
The second step is taking over the network and server documentation. In practice one of three things happens: the documentation exists and is current, it exists but describes the network of four years ago, or there is none at all and everything lives inside one head.
What to ask for:
- the addressing plan and the VLAN layout, with a note on what belongs where,
- a description of the firewall rules together with the reason each one was created,
- VPN configurations and the list of people who use them,
- a server inventory with roles and dependencies, so it is clear what stops working once one machine goes down,
- a description of the backups, meaning what is copied, where it is kept and for how long,
- licence keys and support contracts together with their renewal dates.
If the documentation does not exist, that is not a reason to abandon the change. It simply becomes the first job of the new team, done on the devices themselves rather than from stories. It is only worth knowing that it takes time, and worth asking the new provider whether the inventory is part of the handover and what you receive in writing at the end of it.
Contracts with carriers and vendors
This part usually surfaces too late, because it is not visible in any console. It comes down to whose company name and whose tax number sit on the paperwork.
- internet and MPLS links, and with them the question of whether the contract was signed by the company or by the IT provider on its behalf,
- vendor hardware support, meaning who raises a case and whose name the contract is registered under,
- licences bought through a reseller, which may sit in the tenant of the provider rather than the tenant of the company,
- cloud subscriptions, and with them the question of who owns the subscription and the user directory,
- the domain and the certificates, meaning who renews them and from which card.
If anything on that list is registered to the outgoing provider, moving it is a separate task with its own deadline, sometimes counted in weeks. It will not fit into the last week of the contract. The worst case here is not a lost password. The worst case is an expiring firewall licence that the company finds out about the moment the device stops updating its signatures.
Backups and the date of the last restore test
If you could ask the outgoing provider only one question, ask about the backups. Not whether the backup runs, because it almost always runs. Ask when data was last restored from it, and what exactly was restored.
Five things are worth pinning down: what is copied, where the copies physically sit, who has access to the console, how long copies are kept, and the date and scope of the last successful restore.
The industry 3-2-1 rule calls for three copies of the data on two kinds of media, with one copy kept offsite. Its newer version, 3-2-1-1-0, adds one copy cut off from the network plus zero errors, where that zero means copies verified by regular restore testing. Testing stopped being an extra on top of backup. It is part of it.
One practical note to close this point. If the copies sit in the infrastructure or the cloud account of the outgoing provider, they have to be moved before the contract ends, not after. Once notice has been served, nobody is obliged to keep them any longer.
An overlap period, so no bridges get burned
The calmest handovers share one feature. For an agreed period both companies have access, both know about it, and it is written into the notice or an annex. The new team is already working, the old one is still reachable for the things that never made it into documentation.
The overlap does not have to be long. It has to cover one full working cycle of the company, meaning the month end close, payroll, stocktaking or a seasonal peak. Things that happen once a month show up once a month.
Settle one more thing that is easy to forget in the heat of the moment. The parting should be formal and polite. Someone who still holds the passwords and remembers why a thing was built the way it was is worth more right now than the satisfaction of a sharply worded e-mail.
The order in which old access is switched off
One rule here has no exceptions. Old access is not switched off until the new access has been proven in practice. Proven means that somebody logged in, made a real change and reverted it, not that somebody saw a welcome screen.
A sensible order looks like this:
- new administrative accounts are created and each one is tested separately,
- passwords on shared accounts are changed, because those cannot be revoked,
- the most sensitive access goes first, meaning domain administrator, firewall, backup console, cloud global administrator and carrier portals,
- second login factors and recovery addresses are corrected so that they point back to the company,
- VPN accounts and ordinary administrator accounts of the previous team are disabled,
- remote access tools and remote management agents come off the workstations and servers last.
That last point matters more than it looks. A remote management agent is a working channel into every machine in the company. If it stays behind after the contract ends, every earlier point loses its meaning.
What to get in writing, and what to ask the new provider
A handover ends with a document, not a phone call. The minimum worth having:
- a handover record listing the systems, the accounts and what was actually passed over,
- passwords in a password manager owned by the company, not by the provider,
- a list of carrier and vendor contracts together with their renewal dates,
- a description of the backups with retention and the date of the last restore,
- a list of disabled access with the dates it was switched off,
- a statement confirming that data was deleted or returned and that copies were removed.
That last item is not a whim. If the IT provider processed personal data for the company, it was bound by a processing agreement under article 28 of the GDPR. The same article says that once the service ends the processor deletes or returns the data and deletes all existing copies. The same agreement is needed with the new provider, from day one.
There are a few questions worth asking the new provider before you sign anything. How does the handover work and how long does it take? What do I receive in writing? Who runs it on your side? What do you check in the first week, before you change anything? What is the response time, and is round the clock cover written into the contract or only into the brochure?
Changing an IT provider is doable, and it is done in a set order. If you want to walk this list against your own infrastructure and see where the gaps are, call +48 662 036 615 or write to [email protected].