Why Your IT Documentation Is Already Outdated — and How to Keep It Current
Every undocumented change is a loan against your own future. Here is how to stop borrowing.
Picture a Friday, 5:40 pm. The email server is down. Your IT manager opens the shared drive, finds a PDF labelled “Server Configuration — Final Version”, and discovers it was last touched more than a year ago. Since then, the mail gateway has been replaced, the firewall updated, and backups migrated to the cloud. None of that is in the document. The one person who remembered the full chain of changes left the company two months ago.
Nobody in this story was careless. Documentation does not decay because people are careless. It decays because the system around it is designed to let it happen.
Why Documentation Becomes Obsolete Before You Notice
The standard advice sounds reasonable: review your documentation at least once a year, or after every significant change. But how many changes occur in a mid-sized company’s IT environment over twelve months? Dozens. Security patches, firmware updates, service migrations, hardware swaps. Who tracks every single one?
The root cause is architectural, not behavioural. Documentation lives in one system. Changes happen in another. No connection exists between them. A technician configures a new VLAN, verifies the traffic flows, and closes the ticket. Updating the wiki page? That’s “later”. Later never arrives.
The cost of not finding the right information is well documented. McKinsey Global Institute found that knowledge workers spend about 1.8 hours a day, or 9.3 hours a week, searching for and gathering information. Outdated documentation feeds that number: a page that describes a reality that no longer exists is worse than no page at all.
Think of it as technical debt. Every undocumented change is a loan a business takes against its own future, and the interest is paid in the middle of an incident.
The principle is straightforward. If a change is not documented, it is not complete.
The Hidden Cost of Switching IT Providers
The real expense of moving to a new IT provider is rarely data migration or server reconfiguration. It is the knowledge that was never written down.
A new team arrives, requests documentation, and receives a file describing a configuration from eighteen months ago. Everything has changed since. Why was this particular network route chosen? What is the purpose of that non-standard firewall rule? Nobody knows. Reverse engineering begins: testing dependencies, reconstructing the logic behind someone else’s decisions. It is slow, it is billable, and it is avoidable.
Losing a key specialist is more expensive still. Gallup’s widely cited estimate puts the cost of replacing an employee at anywhere from half to twice their annual salary, depending largely on seniority. And the salary is only part of the loss: whatever that person never wrote down leaves with them.
We recommend a handover overlap of at least 30 days between outgoing and incoming teams, with documentation as the main deliverable of that period. How many SMEs actually plan for this?
Every IT provider contract should include documentation as a mandatory quarterly deliverable. Not a bonus. Not an option. A contractual obligation.
Hardware and Software Obsolescence: The Silent Threat
Suppose your documentation is flawless. Every cable, every routing rule, all recorded. But the firewall it describes has been declared end-of-life by the vendor. The software version no longer receives security patches. Your documentation is accurate and simultaneously useless.
Vendors publish end-of-life schedules in advance, yet SMEs rarely track them systematically. If nobody owns that check, the first time you learn a component is out of support is the day you need a patch for it, usually in the middle of an incident.
Get SESINF SRL SOLUZIONE E SERVIZI INFORMATICI’s stories in your inbox
Join Medium for free to get updates from this writer.
Documentation also degrades in environments with far more engineering discipline than a typical SME. Researchers who analysed the 1,000 most popular projects on GitHub found that more than a quarter contained at least one outdated reference to code in their documentation. If well-maintained software projects drift, an IT environment maintained by a small team between tickets will too.
Build an obsolescence calendar. Every quarter, check your hardware and software inventory against vendor end-of-life schedules. This will not stop obsolescence, but it will make it predictable.
How Living Documentation Changes the Game
The solution is not “document better”. The solution is to change the fundamental nature of documentation itself.
Living documentation is synchronised with the actual state of your infrastructure. Infrastructure as Code (IaC) is the clearest example: the code defining a server’s configuration is the documentation, and it also enforces the desired state. The gap between “how it should be” and “how it is” narrows sharply, provided every change goes through the code rather than around it.
GitLab shows the principle at scale. Its public handbook, which the company describes as running to more than 2,000 pages if printed, is the single source of truth for how the all-remote company operates, and changes are made in the handbook first.
SMEs do not have GitLab’s resources. The principle scales down, though. Start with a single component, such as your firewall configuration or backup policy, and implement IaC. Prove the value on one project. Then expand. Self-generating network inventories and change logs integrated with your ticketing system follow the same logic: the record is produced by the work, not written after it.
Three Actions You Can Take on Monday Morning
Upkeep of IT documentation tracks company size. In Eurostat’s 2024 survey, only 18% of small EU enterprises (10–49 employees) had defined or reviewed their ICT security documentation in the previous 12 months, compared with 58% of large enterprises. Solutions for smaller businesses must work with minimal resources.
- A mandatory change log. Every infrastructure change gets an entry: date, person responsible, description. A Google Doc or shared spreadsheet is sufficient. You do not need a dedicated platform. You need a habit.
- A quarterly documentation sprint. One day every three months when your team, or your provider, compares documentation against the actual state of your infrastructure. One day per quarter is cheap insurance.
- Documentation as a contract clause. Include a requirement in your IT provider agreement: current documentation is a quarterly deliverable. Consider tying part of the payment to it, for example 10%. Documentation stops being “nice to have” and becomes an obligation.
Inaction is not savings. It is a deferred invoice.
Back to that Friday evening. The server is down. The documentation is useless. The specialist is gone. If this scene feels familiar, do not wait for the crisis to arrive.
The question is not whether you can afford to document. The question is whether you can afford not to.
If your IT documentation has not been reviewed in the last two quarters, or if you are not certain it exists at all, it is time to act. SESINF conducts infrastructure audits and implements systematic documentation as part of long-term IT partnerships. Get in touch for a complimentary assessment of your documentation’s current state.
Sources
- McKinsey Global Institute, The Social Economy: Unlocking Value and Productivity Through Social Technologies (2012)
- Tan, W. S., Wagner, M., Treude, C. “Detecting outdated code element references in software repository documentation”, Empirical Software Engineering 29 (2024)
- Eurostat, “ICT security in enterprises”, Statistics Explained (2024 data)
- GitLab Handbook, about.gitlab.com/handbook
