It is nine in the morning, a switch has failed and half the office is offline. The technician opens the rack and sees hundreds of identical, unlabeled cables. Which port goes to reception? Which one serves the accounting printer? Nobody knows — the person who built the network moved on to another project long ago. The next hour goes on searching, not repairing.
As-built documentation is a record of what was actually built. Design drawings show intent; as-built shows reality, including every change made during installation. It is the only deliverable whose value grows after the project ends.
What a complete as-built package contains
- Floor plans with the location and ID of every outlet, camera, access point and reader
- Rack elevations — which device sits in which rack unit
- A cable schedule: outlet → patch panel port → switch port
- Cable test reports for every link
- A logical network diagram: VLANs, IP address ranges, routing, provider connections
- An equipment register: model, serial number, firmware version, location, warranty expiry
- Configuration backups for network devices
- A CCTV camera list with fields of view, and an access control door schedule
- Manufacturer manuals and warranty documents
Administrator passwords and access credentials are part of the documentation, but they must be handed over separately and securely — not in a shared PDF circulated by email.
Labeling: the bridge between paper and reality
Documentation only works when the physical labels match it. Choose one consistent, logical scheme — for example floor–room–rack–panel–port, such as '2-R1-PP3-24' — and use it everywhere: at both ends of each cable, on the outlet, on the patch panel and in the cable schedule. If a technician can take the number on the wall plate and find the right port in the rack, the labeling is doing its job.
Where it pays back
- Troubleshooting: faults are located in minutes, not hours
- Moves, adds and changes: connecting a new workstation no longer involves guesswork
- Audits and insurance: evidence of equipment and configuration is at hand
- Changing service provider: a new team gets up to speed quickly
- Office relocation: the inventory and connection map already exist
- Expansion planning: you can see where free ports, rack space and PoE capacity remain
Why it is so often missing
The reasons are usually the same. Documentation is prepared at the end of the project, when budget and time are already spent. The contract mentions it in one line — 'documentation' — without defining content or format. Often the client receives a PDF of the design drawings that was never updated with changes made during installation. And after handover, nobody is responsible for keeping it current.
How to require it in the contract
- List the contents of the package — the list above is a good starting point
- Ask for editable formats (drawings, spreadsheets), not only PDF, so you can update them later
- Define the labeling scheme in advance, or require it to be agreed before installation starts
- Tie the final payment to receipt of the documentation and a spot check
- Agree a procedure for secure handover of credentials
- Name a person on the client side who receives the documentation and then owns it
How to keep it current
As-built documentation is complete on handover day and starts aging with the very next change. So the rule must be simple: whoever makes the change updates the documents. Every change — a new outlet, a re-patched port, a replaced device — should be reflected the same day. This is one of the least visible but most valuable parts of managed IT services.
Store documentation in a central location with version history, accessible to those who need it. Keep a copy outside the network as well — documentation that lives only on the server that has just failed will be unavailable exactly when you need it most. Regularly, for example once a year, compare the documents against reality, especially in the server room and communication racks.
Planning a new project, or want your existing infrastructure fully documented? Get in touch — we can help you define the scope and format of the documentation.