The short answer: Start with the domain, email tenant, and backups—not the office computers. In the first few hours, secure company-owned administrator access to the domain, Microsoft 365 or Google Workspace, and the backup repository. Terminate the former administrator’s remote access, then begin the inventory. Within seven days, you should have your own administrator accounts, a dependency map, and a successful data restore test—not merely a list of passwords.
When a company’s IT administrator leaves, the consequences rarely appear as an immediate outage. They surface through an ordinary request: add a new employee to the email system, renew the domain, or change a phone number on the website. That is when you discover that the domain is registered to the administrator’s personal email address, Microsoft sends the second authentication factor to a phone the company no longer has, and a backup job on the NAS has been reporting errors for two months to an inbox nobody reads.
A managed handover in which the departing administrator cooperates is covered in Your IT Admin Left: How to Take Over and Hand Off Company IT Without Downtime. This article starts from a more difficult position: either no handover took place at all, or you cannot trust the one you received.
The goal of the first week is not to redesign the network or buy a new server. It is to accomplish five things:
- terminate the former administrator’s access before anyone can misuse it,
- preserve company data and configurations that could disappear with the administrator’s account,
- obtain administrator privileges owned by the company,
- identify what the business actually depends on,
- prove that the backups can be restored.
Documentation comes sixth—and it is the only deliverable that will remain useful when the next administrator eventually leaves.
The first two hours: who makes decisions and what to shut down
Appoint one member of management to approve the handover. They do not need to understand VLANs. They do need to decide who receives administrator access and which changes may be made while systems are live—because over the next few days, someone will ask both questions under time pressure.
If there is a risk of account misuse, begin by cutting off access. Changing the main password alone is not enough: in Microsoft 365, an issued access token typically remains valid until it expires, often for several hours. An authenticated session therefore continues until you explicitly revoke it using „Revoke sessions" in Entra ID or Revoke-MgUserSignInSession in PowerShell. The same principle applies to Google Workspace and most cloud services.
Review every access route that bypasses the password entirely:
- VPN accounts and client certificates (with OpenVPN, revoke the certificate as well as deleting the account),
- remote management tools such as AnyDesk, TeamViewer, RustDesk, or an RMM agent with persistent access to workstations,
- SSH keys in
~/.ssh/authorized_keyson servers and in DSM or QTS on the NAS, - the administrator’s personal accounts added as administrators in Microsoft 365, Google Workspace, Cloudflare, the hosting platform, or the domain registrar,
- API tokens, app passwords—which bypass MFA—and access to the password manager,
- automatic email forwarding and delegated mailbox access.
Do not delete the account immediately, however. First preserve its email, OneDrive or Drive files, documentation, and communication history with suppliers—this may contain the only clue to where the domain is registered. Check what the specific platform does when a licence is removed. Mailbox content does not disappear immediately, but retention periods vary by service and configuration, so export the data before relying on any grace period.
Do not perform a blanket password reset either. Backup jobs, scan-to-email functions on multifunction printers, NAS synchronisation, and scheduled scripts may all run under the administrator’s account. An uncontrolled password change can stop a service you do not yet know exists—and nobody may connect the failure to that change because it only becomes apparent a week later during the monthly close.
Seven-day plan for taking over company IT management
| Deadline | What must be completed | Outcome |
|---|---|---|
| Day 1 | Secure the domain, email tenant, administrator accounts, and remote access | The company has its own administrator access |
| Day 2 | Inventory devices, servers, cloud services, licences, and suppliers | It is clear what exists and who pays for it |
| Day 3 | Map the network and dependencies between services | Changes can be planned without unnecessary downtime |
| Day 4 | Check backups, encryption keys, and error history | It is clear what can be restored |
| Day 5 | Perform a practical restore test on selected data | The backup is verified, not merely „green" |
| Day 6 | List risks by severity | Management knows what requires immediate action and what can wait |
| Day 7 | Complete documentation, a remediation plan, and management rules | Operations no longer depend on one person |
The order may change depending on the situation. A failed accounting backup takes priority over a printer inventory. An unknown guest Wi-Fi password, on the other hand, is not a reason to take the network offline.
Checklist of accounts the company must control
A spreadsheet of passwords does not constitute a handover. The company must own the account, recovery address, second authentication factor, and supplier contract—these are four separate things, and any one of them may be missing.
| Area | What to take over and verify |
|---|---|
| Domain | Registrar account, registered holder, billing contact, recovery email, multi-factor authentication, transfer lock |
| DNS | Authoritative name servers, zone export, access to Cloudflare or the DNS hosting provider, DNSSEC |
| Microsoft 365 Global Administrator or Google Workspace Super Admin, licences, billing, MX, SPF, DKIM, DMARC | |
| Identity | Microsoft Entra ID, groups, administrator roles, Conditional Access, connected applications, and granted OAuth permissions |
| Internet and network | ISP account, router, firewall, switches, Wi-Fi controller, VLANs, DHCP, VPN, public IP addresses |
| Servers | Windows Server, Linux, Hyper-V, VMware or Proxmox, service accounts, consoles, encryption keys |
| NAS and backups | Synology DSM, QNAP QTS, Veeam, Hyper Backup, Active Backup for Business or HBS 3, destination repositories, and encrypted-backup keys |
| Computers | Local administrator, BitLocker recovery keys, Intune or another MDM platform, antivirus, RMM |
| Web and cloud | Hosting, SSL certificates, GitHub or GitLab, Azure, AWS, accounting and CRM systems |
| Other operations | VoIP system, CCTV system, attendance system, UniFi or Omada controller, printers, and scan-to-email |
For each item, record the service owner, administrators, access-recovery method, next payment date, and dependencies. Passwords belong in a company password manager—such as Bitwarden, 1Password, or Keeper—not in a shared spreadsheet on a drive, and certainly not in email.
BitLocker recovery keys deserve particular attention. If the workstations were joined to a domain or Entra ID, the keys were probably backed up there automatically and can be retrieved from the management console. If they ran as standalone computers under local accounts, the keys may exist in the technician’s Microsoft account or on paper—and nowhere else. This is covered in detail in What to Do When BitLocker Suddenly Requests a Recovery Key After a Windows Update.
The correct order for changing access credentials
Work from the accounts that can be used to recover all the others down to the endpoint accounts:
- The company domain and registrar account.
- The primary email tenant and identity system (Entra ID, Google Workspace).
- The password manager and backup accounts.
- Cloud platforms, hosting, servers, firewall, and remote access.
- Operational applications and ordinary endpoint devices.
The logic is simple: whoever controls the domain can redirect the company’s email; whoever controls the email can reset almost everything else. If you start by reconfiguring laptops, you are fixing the leaves while the root remains in someone else’s hands.
Create at least two company-owned administrator accounts in both Microsoft 365 and Google Workspace. They must not use a technician’s personal address or serve as everyday mailboxes. In Microsoft 365, also verify whether there is an emergency access account exempt from Conditional Access. Without one, a misconfigured policy can lock everyone out of the tenant.
Before changing a service account’s password, determine everywhere it is stored. A single account often supports a backup job, printer, web application, and scheduled script. Changing it without a dependency map creates a series of seemingly unrelated failures that are much harder to troubleshoot than one planned outage.
The domain and DNS take priority over office computers
Anyone who controls the domain and DNS can redirect the website, change mail delivery, prove domain ownership to a cloud service, and create access there. Despite this, domains are often still registered to the person who originally „set everything up."
Verify directly with the registrar that the company is the registered holder and that its contact details are current. For Czech domains, the holder can be found in the public CZ.NIC registry, but the registration can only be changed through the registrar account or by proving identity. The ability to edit DNS records is not enough—it is a permission, not ownership.
Export the zone before making any changes. Record the mail MX entries, service-verification TXT records, SPF, DKIM—whose selectors are commonly selector1 and selector2 in Microsoft 365 and google in Workspace—DMARC, subdomains, and any records used by a VPN or remote-access service. Do not rebuild the zone based only on what is visible on the website. A verification TXT record or autodiscover CNAME has no obvious public purpose, and the consequences of deleting it may not appear for weeks.
A backup has not been handed over until you restore data from it
A green icon in Synology DSM, QNAP QTS, or the Veeam console proves only one thing: the job completed. It says nothing about whether the right data was backed up, whether you have the encryption key, or whether a restore is technically possible.
During the first week, verify:
- exactly what is backed up and what the job excludes—exclusions are often years old and have never been reviewed,
- where the copies are stored and whether at least one copy exists off-site,
- whether the backup repository is permanently connected using the same account as production—if so, ransomware can encrypt both,
- how long older versions are retained and whether they would survive an unnoticed month-long failure,
- who controls the backup password and encryption key,
- whether errors are actually reported to an address someone reads.
Then perform an isolated restore of several files and at least one important system or a representative part of it. Open the restored file. For a database, producing a file of the expected size is not enough—the application that uses it must be able to load it.
RAID is not a backup, and neither is a second disk in the same NAS. Both protect against disk failure, not deletion, ransomware, or silent data corruption. The wider context is explained in A Practical Guide to RAID Levels and Using an External Drive for Backup Under the 3-2-1 Rule. During a handover, what matters most is proof that an independent, usable copy exists.
If the restore test fails—the volume is degraded, nobody knows the key, or the job has not completed for months—do not use trial and error on the only copy of the data. Send us a data recovery enquiry, and we will first assess what can be recovered and under what conditions. Starting a rebuild of a degraded array „to get it running" can permanently destroy what remains of the data.
Where undocumented dependencies hide
A technical inventory alone will not reveal that the accountant exports data through a network folder on an old server, that the warehouse prints labels from the only computer with the required driver, or that a backup is launched by a script running under the former administrator’s personal account. Ask employees what stops working when the internet, server, or a specific workstation goes down. Their answers will produce a map that no network scan can draw.
Also check:
- automatic SSL certificate renewal—a Let’s Encrypt certificate is valid for 90 days, so a failed cron job may not become apparent for three months,
- scheduled tasks and scripts on both servers and workstations,
- SMTP accounts used by printers, websites, and cameras—these are often app passwords that remain valid even after the main password changes,
- shared mailboxes and email forwarding,
- local databases used by accounting software—Pohoda and similar products commonly use file-based databases on a shared drive,
- licences tied to the former administrator’s email address, hardware, or payment card,
- the UPS and the process used to shut down the server or NAS safely during a power outage.
Document the dependency first, then migrate it to a new service account. Reversing that order is the most common cause of handover-related outages.
What the company should receive after the handover
The deliverable should not be a statement that „we can access everything now." Require a specific package:
- an inventory of devices, services, and licences,
- a list of administrator and service accounts with a named owner,
- a simple network diagram,
- exports of important configurations such as the firewall, DNS zone, and backup jobs,
- an overview of domains, DNS, and certificates with expiry dates,
- backup documentation including the result of the restore test,
- a list of suppliers, contracts, and payment dates,
- risks classified as critical, high, or deferrable,
- a remediation plan with an owner and deadline for every task.
The documentation must be stored in a company-controlled location and accessible to at least two authorised people. Otherwise, you have merely replaced one dependency with another.
How much an IT handover costs and what the proposal should include
An IT handover cannot be priced fairly based on the number of computers. Its scope depends on the number of branches, servers, and cloud services, the state of the documentation, the former administrator’s willingness to cooperate, and whether you will need to prove account ownership to suppliers.
Split the proposal into three parts:
- securing critical access,
- audit and documentation,
- remediation of identified issues.
The first two parts can have a fixed scope or an approved cap on billable hours. Remediation should only be priced after the current state is known. Anyone pricing it in advance is either guessing or adding enough contingency to cover the worst-case scenario. A proposal for a „complete handover" without a list of deliverables is an invitation to dispute what was actually ordered.
Do not combine the price of ongoing IT management with the handover in a single line item. The difference between a fixed monthly fee and hourly billing is explained in How Much IT Management Costs for a Small Business. Restoring control over a neglected environment is a one-off project; ongoing management is a separate service with a different cost structure.
How to recognise a well-executed handover
A good administrator spends the first day mapping dependencies and backing up configurations. They do not replace the firewall simply because they prefer a different brand.
Warning signs include:
- accounts remain registered to the technician’s personal email address,
- the company has no administrator access of its own, only a promise that it will receive it,
- nobody has performed a restore test,
- passwords are sent through ordinary email,
- there is no record of the changes made,
- everything runs under a single account, with no way to identify who did what,
- new equipment is recommended before the inventory is complete,
- there is no procedure for a future handover to another supplier.
The test is simple: if the new administrator were unavailable tomorrow, would the company still control its accounts, know where its data is stored, and have usable documentation? If so, the handover was successful. If not, you have merely changed the name attached to the only key.
If you want this resolved with deliverables you can defend both to management and to the next supplier, contact us. We provide IT handovers, access audits, and backup restore testing as a single engagement with an agreed list of deliverables.
What to do when the former administrator will not cooperate
Start with proof of ownership: contracts, invoices, the domain’s registered-holder details, and company contacts listed with suppliers. Registrars, hosting companies, and cloud providers generally have their own access-recovery procedures. These are usually based on proving the company’s identity, not knowing the password. Taking over a service registered to a private individual is more difficult and cannot be resolved with a simple password reset.
Do not attempt to bypass security by guessing. With an encrypted NAS volume, BitLocker, or an encrypted backup, you may obtain an administrator account and still have no access to the data. The encryption key is separate from administrator privileges, and the content remains unreadable without it.
Keep an ongoing record of which access credentials are missing, who was contacted, when they were contacted, and which documents you submitted. This record may become the only useful evidence for negotiations with suppliers or a potential contractual dispute.
Frequently asked questions
Should we block the former IT administrator’s account immediately?
If there is a security risk, yes—but in the correct order. First secure a second company-owned administrator account and export data from the former administrator’s mailbox and cloud storage. Only then should you block sign-in, revoke active sessions, and remove VPN access, SSH keys, API tokens, app passwords, and remote-management tools. Reversing the order can lock you out of your own tenant.
Do we need to know all the old passwords?
No. What matters is verified ownership of the service and the ability to create or recover an administrator account securely. Any password known to both you and the former administrator should be changed anyway. Service accounts are the exception: first determine which systems use them, then change their credentials.
How long does an IT management handover take?
With good cooperation, critical accounts can be secured on the first day. A complete inventory, backup review, and dependency map usually take several business days. An unavailable former administrator or services registered to a private individual will extend the process according to the supplier’s procedures, not your preferred schedule.
Can we take over a domain when nobody knows the login details?
Often yes, provided the company is listed as the registered holder and can prove its identity to the registrar. If the domain is registered to a former employee or contractor as a private individual, the registrar’s rules and the contractual documentation determine the procedure. That is why the registered holder is more important than who currently knows how to sign in to the administration interface.
How do we verify that the backups actually work?
Restore them to a separate location and open the data in practice: open a document and connect a database to its application. Also verify that older versions are available, that you have the encryption key, and that there is a documented process for restoring an entire critical system—not merely individual files. A restore procedure that nobody has tested for a year is no more reliable than having no test at all.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).