Your Documentation Is Older Than You Think

When an MSP owner sits through a documentation platform evaluation, the question that comes up most often is some version of "what keeps any of this current." It is the right question, and the honest answer at most MSPs is that nothing does. The platform stores what a technician typed on the day they typed it, and from that moment forward the record is only as accurate as someone's memory to come back and change it.

The mechanism behind stale documentation is an assumption made at the moment of creation: that a future person will notice when the environment changes and return to update the page. Everything else about decay follows from that assumption failing. The first article in this series called this property freshness. This one covers how decay actually happens, the three dates that tell you how fresh a tenant is, and how to move the job of staying current off the technician and onto the platform.

Why decay happens

Nearly every change to a client environment is made in a console that is not the documentation platform. A technician retires a server in the hypervisor, swaps a firewall in the vendor portal, rotates a credential in the vault, and closes the ticket in the PSA. Each of those tools records the change on its own. The document that describes the environment sits downstream of all of them and only changes if the same technician, on the same day, remembers that it exists.

The records created during onboarding are the most exposed, because onboarding is often the last time anyone looks at a client's documentation as a whole. A site summary, a network record, and a backup record get written in the first two weeks, and then the account settles into ticket-driven work where technicians touch individual assets and never the surrounding documents.

The result shows up in a specific way when you finally look. A workstation gets pulled off the network and marked inactive in the RMM, and the sync carries that status into the documentation platform. Nothing carries it into the 14 documents that still reference the machine by name as a print server, a scan destination, or a jump box. Each of those documents is now wrong, none of them was edited, and the last-updated date on every one still reads as if they were fine.

Measuring document freshness

Freshness is measurable, and the measurement comes down to three dates that every record either carries or should carry.

A tenant can do well on the first date and badly on the third, because a record can be edited last week and still list a certificate that expired in the spring. Looking at all three together is what gives you an honest picture.

A ten minute exercise

Most documentation platforms will let you sort or export records by their last-updated date. Pull that list for your internal runbooks, find the median date, and compare it to something the team will remember. A common result is an onboarding procedure or an incident runbook that was last touched before ChatGPT launched, which means it predates most of the tooling the team now uses every day.

Then run the same exercise for two or three clients. The internal set tends to be the oldest, since nothing external ever forces a review of it, and among clients the ones onboarded longest ago usually come out oldest. Neither result is a surprise once you see it, and both are useful, because they turn a vague feeling that a lot of it is pretty old into a date you can put in front of the team.

Why quarterly audits don’t work

The standard response to decay is a periodic review, usually quarterly, sometimes annual, and usually skipped when the quarter gets busy. Even when it happens on schedule, a quarterly audit means the documentation is permitted to be up to three months wrong before anyone checks. Between reviews, every technician who opens a record is trusting that the last review caught everything.

That trust is the real casualty. A technician who follows a runbook to a server that was decommissioned last month does not conclude that one document was stale. They conclude that the documentation cannot be relied on, and from then on they verify everything against the live environment before acting, which makes the documentation a formality rather than a tool. Once a team stops trusting the records, adoption falls, updates fall further behind, and the decay accelerates. Documentation only works when the team believes it, and belief does not survive many wrong answers.

Automating documentation updates

The fix is to stop relying on a person remembering and start relying on the record itself carrying a date that the system watches.

Every document and asset should have a review date set at the moment it is created, with the interval matched to how fast that kind of record changes. A QBR prep document is stale by the next quarter, so it expires in three months. A BCDR runbook might carry six. A hardening standard or a naming convention might carry a year. The point is that the date lives where the platform can watch it, and the platform, not the technician, is responsible for raising it when it comes due.

Once that is in place, the quarterly audit is replaced by a rolling one. Instead of reviewing everything every ninety days, the team reviews whatever is expiring in the next seven or thirty days. That is a short list on any given week, and it never allows a record to sit wrong for a full quarter. The same mechanism covers the third date, because certificates, warranties, and licenses surface on the same list as the documents.

How Lexful gets you there

Lexful treats every date as something the platform is responsible for, which takes memory out of the equation.

Where this series goes next

A tenant can be complete and fresh and still be difficult to work in, because records that are individually correct can still be duplicated, orphaned, and disconnected from one another. The next article covers hygiene and linkage, starting with the specific ways a tenant accumulates clutter and working through to what it takes to make every record reachable from the records around it.

The freshness question every MSP should be able to answer is how old the typical record is and what expires in the next 30 days. If the answer to either one is a guess, the documentation is older than anyone thinks.