What I Wish Had Been Documented Before I Inherited a School IT Environment

When you inherit an IT environment, the hardest part is not always the technology itself.

Sometimes the hardest part is simply working out what exists, how it fits together, what is important, and what has been done in the past.

When I joined the environment, I was not walking into a completely broken setup. There were working systems, servers were running, users could log on, files were accessible, printing existed, and the school was functioning day to day.

The bigger issue was that very little had been properly documented.

A lot of the environment had to be discovered by investigation, testing, old assumptions, supplier conversations, system consoles, and gradually piecing things together. That made every project harder than it needed to be, because before changing anything I first had to understand what I was actually changing.

Looking back, there are several things I really wish had been documented before I inherited the environment.

The overall environment

The first thing I would have wanted is a clear environment overview.

Not a 100-page document. Just a practical summary of what the environment looked like and how it was supposed to work.

Something like:

Site overview
Number of users
Number of devices
Main server roles
Core systems
Main suppliers
Network layout
Backup platform
Internet/filtering setup
Cloud services
Device management approach
Known risks or weaknesses

This would have made it much easier to build a mental model of the environment.

Without that, you end up having to reverse-engineer everything. You work out one piece at a time: where the file servers are, how printing works, what controls filtering, where DHCP lives, what systems depend on what, which servers are still important, and which ones are legacy leftovers.

An environment overview does not need to be perfect. It just needs to give the next person somewhere to start.

The server and VM inventory

One of the most useful things would have been a proper server and VM inventory.

When I inherited the environment, there were core services running on virtual machines, including domain controllers, file servers, print services, filtering, firewalling, and MIS-related systems.

What would have helped enormously was a simple list showing:

Server name
Operating system
Server role
Whether it was physical or virtual
Host or cluster location
IP address
Criticality
Backup status
Main dependencies
Notes about any known issues

This became especially important when working on infrastructure projects like moving from vSphere to Hyper-V. Before migrating anything, I needed to understand what each VM did, how important it was, and what the impact would be if it did not come back cleanly.

Without a server inventory, every VM becomes a small investigation.

Is it still used?
What depends on it?
Can it be rebooted?
Who notices if it is offline?
Is it backed up?
Is it legacy?
Is it safe to rebuild?

Those questions are much easier to answer when someone has documented the basics.

Backup and restore information

Backups are one of those areas where “it exists” is not enough.

I would have wanted clear documentation showing:

What backup system is in use
What servers are backed up
How often backups run
Where backups are stored
How long backups are retained
What is excluded
When restores were last tested
Who receives alerts
What to do when a backup fails
How to perform a restore

This matters because backup confidence affects every major change.

Before migrating servers, rebuilding systems, changing storage, or removing legacy infrastructure, you need to know whether your backups actually work. Not just whether the job says “success”, but whether a restore has been tested and the process is understood.

A backup system that nobody understands is a risk.

Documentation does not need to include sensitive credentials or step-by-step details that expose the environment, but it should give enough information for someone responsible for the infrastructure to understand the backup position quickly.

Network layout

I also wish the network had been properly documented.

A useful network overview would have included:

Core switch information
Main cabinet locations
Key uplinks
VLANs, if used
IP ranges
DHCP scopes
DNS servers
Internet connection details
Firewall/router information
Wi-Fi controller or management platform
Important switch ports
Known weak points
Any unmanaged switches or temporary links

This is especially important in a school because the physical network often grows over time. Classrooms change, temporary fixes become permanent, switches get added, cabinets get messy, and old decisions remain in place long after everyone has forgotten why.

When the network is not documented, even simple questions take longer:

Where does this cabinet uplink to?
Which switch serves this room?
Is this port supposed to be live?
What is plugged into this unmanaged switch?
Where does this VLAN exist?
Which DHCP scope serves this area?
What happens if this switch fails?

Good network documentation saves time during faults and reduces the risk of accidental disruption during planned work.

Active Directory and Group Policy

Active Directory is another area where documentation would have made a huge difference.

I would have wanted to know:

OU structure
Key security groups
Naming conventions
Important GPOs
What each major GPO does
Which GPOs are legacy
Which GPOs are safe to remove
Which scripts still run
Where logon scripts are stored
How users are created
How leavers are handled
How staff and student accounts differ

Without this, AD and Group Policy can become intimidating to work with.

You see years of old policies, scripts, groups, and OUs, but you do not always know which ones matter. Some may be critical. Some may be obsolete. Some may have been created for a one-off issue years ago and never removed.

This makes cleanup work slower because you cannot just delete things confidently. You have to test, trace, disable carefully, and wait to see what breaks.

A simple “GPO purpose” document would have been incredibly useful.

Even a basic note saying “This policy maps staff printers” or “This policy is legacy and should no longer apply” can save a lot of time.

User and device management processes

I also wish the day-to-day account and device processes had been documented.

For example:

How new staff accounts are created
How student accounts are created
What groups users need
How permissions are assigned
How staff leavers are processed
How student leavers are processed
How devices are built
How devices are named
How devices are assigned
How devices are retired
How shared devices are handled

These are the processes that keep the environment consistent.

Without documentation, every new starter, leaver, rebuild, or device swap risks being handled slightly differently. Over time, that inconsistency creates technical debt.

A good new starter or leaver checklist does not need to be complicated. It just needs to make sure the same important steps are followed every time.

Asset information

Another major gap was asset information.

There was no existing asset register, no useful central record, and no consistent asset tagging. That meant building an asset register had to start almost from nothing.

In a school environment with around 600 devices and roughly 1,500 users, that becomes a significant job.

A useful asset register would have shown:

Asset number
Device name
Serial number
Device type
Manufacturer and model
Location
Assigned user or department
Status
Notes
Warranty information
Replacement priority

Asset information matters because it supports almost everything else: support, budgeting, repairs, replacements, audits, and lifecycle planning.

Without it, replacement planning becomes guesswork. You know some rooms feel old, some devices are unreliable, and some kit probably needs replacing, but you cannot easily prove the scale or priority.

A basic, maintained asset register would have saved a lot of time.

Supplier and support contacts

Supplier information is another area that sounds simple but becomes very important during an incident.

I would have wanted one place showing:

Internet provider
Filtering provider
MIS support
Finance system support
Print supplier
Telephony supplier
Hardware warranty contacts
Backup support
Broadband/router/firewall contacts
Any external MSP or support partner
Account numbers or support references
Support portal links
Escalation contacts

When something breaks, you do not want to be searching through old emails to work out who supports it.

This is especially important in schools because there are often several specialist systems: MIS, safeguarding, catering, payment systems, print management, filtering, telephony, door access, CCTV, and more.

A supplier list does not need to include sensitive passwords. It just needs to make support routes clear.

Critical systems and “do not touch” areas

One thing I think every environment should document is which systems are critical and which systems should not be changed casually.

For example:

Domain controllers
DNS and DHCP
File servers
MIS
Safeguarding systems
Filtering/firewalling
Backup infrastructure
Print services
Core switching
Wi-Fi
Finance/payment systems
Exam-related systems

In a school, some systems may be more sensitive at certain times of year. Exam periods, reporting windows, census returns, timetable changes, and start-of-term preparation can all affect when work should or should not happen.

It would have been useful to have notes like:

Do not reboot this during the school day.
Only change this during holidays.
This affects all staff logons.
This system is used for safeguarding.
This supplier must be contacted before changes.
This service has no easy workaround.
This server is legacy but still required.

That kind of context is rarely obvious from a server name or admin console.

Known issues and historical decisions

Known issues are often kept in people’s heads.

That is a problem.

I would have wanted a simple known issues log showing:

What the issue is
Which systems or rooms it affects
What has already been tried
Whether there is a workaround
Whether a supplier has been involved
Whether it is accepted risk or still needs fixing

Historical decisions are just as important.

Sometimes you find something odd in an environment and assume it is wrong. Then later you discover it was done deliberately because of a specific limitation, supplier requirement, old system, or previous incident.

A note explaining “why” can be just as useful as a note explaining “what”.

For example:

Why a certain server still exists
Why a GPO is still applied
Why a printer is deployed differently
Why a VLAN was created
Why a system has not been upgraded
Why a workaround is in place

Without that context, future IT staff may waste time undoing something that was there for a reason.

Licensing and renewals

Licensing and renewals should also be documented.

I would have wanted to know:

What licences are in use
Renewal dates
Support expiry dates
Contract owners
Approximate costs
What happens if something is not renewed
Which licences are critical
Which licences are legacy
Which licences may be replaced

This became relevant during the move from vSphere to Hyper-V. Licensing was one of the main reasons Hyper-V made sense for the environment, because the school was already heavily Microsoft-based and already paying for the Windows Server Datacenter licensing required.

If licensing is not documented, decisions become harder. You may not know what you are already entitled to use, what is costing money unnecessarily, or what is due to expire soon.

Good licensing documentation helps avoid surprises.

Project history

I would also have liked some form of project history.

Not every detail, but enough to understand what had changed over time.

For example:

When servers were last replaced
When the SAN was installed
When the last major network change happened
When key systems were upgraded
What projects were attempted but not completed
What suppliers had done previously
What problems were encountered
What decisions had already been made

This helps because inherited environments often contain clues from previous projects.

You might find half-completed changes, unused systems, old migration leftovers, abandoned scripts, or legacy servers that were supposed to be replaced but never were.

A basic project history helps explain why the environment looks the way it does.

What I documented first

When starting from a poorly documented environment, it is tempting to try to document everything at once.

That usually does not work.

The best approach is to start with the areas that reduce the most risk or unlock future work.

For me, the priority areas were:

Core server inventory
Virtualisation platform
Backup position
Network basics
Asset register
Key suppliers
Critical systems
Common support processes

Those areas gave me a clearer picture of what I was managing and made future projects easier to plan.

Documentation does not need to be perfect immediately. The important thing is to create something useful, then keep improving it.

The biggest lesson

The biggest lesson is that documentation is not separate from technical work.

It is part of the work.

If a server is rebuilt, the documentation should change. If a switch is replaced, the documentation should change. If a device is moved, the asset register should change. If a supplier changes, the support notes should change. If a new system is introduced, the environment overview should change.

Otherwise, documentation becomes stale almost immediately.

That is the trap: documentation gets created during a project, but nobody owns it afterwards. Six months later, it no longer reflects reality. A year later, people stop trusting it. Eventually, the next person inherits the same problem again.

Final thoughts

What I wish I had inherited was not a perfect environment.

I would just have liked a clearer map.

A basic server list, a network overview, an asset register, backup notes, supplier contacts, key processes, and a known issues log would have made a huge difference.

None of those documents need to be complicated. They just need to be accurate enough to help the next person understand the environment and make safer decisions.

In a school IT environment, where small teams support a large number of users, documentation is not just admin. It is resilience.

It reduces dependency on memory, makes support easier, helps with planning, and makes future projects safer.

The most useful documentation is not always the most polished. It is the documentation that someone can open during a problem and immediately use.