How to take over IT from a previous administrator
A safe takeover starts with verifying who owns the accounts, obtaining access and mapping dependencies - changes that can be rolled back come only after that.
Rather talk it through?
Describe the situation and I will suggest a first step and an estimate of the scope.
Let’s talkIf you can work with the previous administrator
Agree on one formal handover, a specific list of deliverables and a deadline by which the new administrator can still ask follow-up questions. The aim is not to judge past work but to keep things running and transfer the knowledge.
- a list of devices, servers, virtual machines and important applications
- administrator accounts, second factors and a secure way of handing over secrets
- the domain registrar, DNS, email, cloud, licences and billing accounts
- the network diagram, public addresses, VPN, Wi‑Fi and remote access
- backup jobs, where the copies are stored, encryption keys and the last restore test
- supplier contacts, contracts, warranties and open incidents
The domain, cloud services, licences and admin consoles must not stay registered only to the former administrator’s personal email address. Technical access can be delegated; ownership should stay with the company.
What to verify in the first days
A fresh list of information is not yet proof that it is complete. Access needs to be tested, the inventory compared with reality, and you need to establish which services are genuinely critical to day-to-day operations.
Checking ownership
Who can reset the password, change the billing or transfer the domain? The contact email and phone number must be ones the company has access to.
Inventory and dependencies
Which service runs on which device, who uses it, and what stops working when an address, password or certificate changes?
Backups and monitoring
Checking the last run is not enough. Check that error notifications work and schedule a restore test.
Risks and priorities
Deal first with lost control over accounts, missing backups and publicly reachable systems that are not kept up to date. Cosmetic changes can wait.
In what order to change access
- Secure the recovery channels.Verify the company email, phone number and second factor before you change the main password.
- Create named accounts.Every administrator should have their own account. Keep a shared account only where the device offers no other option.
- Store emergency access.Recovery codes or a break-glass account belong in the company password vault, with restricted access.
- Change one service at a time.After each change, check that automations, backups and integrations that may use the old password still work.
- Remove old access.Only once the new accounts are confirmed, shut off remote access, VPN, API keys and access for people who have left.
If the administrator leaves on bad terms, proceed just as systematically, but faster and together with the company’s management. If some access is missing, do not jump straight to resetting the device; first go through the recovery options and the impact of an outage using the guide to a missing router or server password. A dispute over who owns the access or the data is a legal matter - this guide covers the technical side of a takeover, not how to resolve such a dispute.
How to tell the takeover is complete
The company has working administrator and emergency access, knows who owns the key accounts, knows its critical services and their dependencies, and has the risks recorded along with a plan for the next steps. The documentation does not have to be perfect on day one, but it must be usable without any one particular person being present. The checklist of minimum IT documentation will help. You will find more practical topics in the IT guides.
Let’s start with an inventory and an access review.
A takeover can be split into a safe minimum, verification of day-to-day operations and further improvements prioritised by risk.