Long read · 8 min

Inherited infrastructure: what you actually take on.

Almost every established business is running on infrastructure configured by somebody who no longer works there.

This is so normal that it barely registers as a fact. The website was built by an agency three agencies ago. The domain was registered by a founder who exited. The mail was migrated by a contractor. The certificate renews itself through a mechanism nobody currently employed has seen.

None of that is a problem while it works. It becomes a problem in one specific way: when something needs to change, and nobody knows where anything is.

The inventory nobody has

Ask a business to list what its domain depends on and most cannot. Not because they are careless, but because the information was never assembled in one place. It exists in fragments: an invoice from a registrar, a login in somebody's password manager, a DNS panel somebody set up, a server nobody has logged into since the migration.

The fragments are individually harmless and collectively unusable. There is no document to hand to a successor, because the document was never written, because at no point was writing it anybody's job.

Three ways this surfaces

Something breaks. The site is down and nobody knows whether the problem is the domain, the DNS or the hosting, because nobody knows which company holds which. Hours go into working out where to look before any fixing starts.

Something needs changing. A rebrand, a migration, a new mail provider. Each requires access to a system nobody can log into, and the recovery process takes weeks because the account is in a departed person's name.

Somebody asks. A buyer, an insurer, an auditor, a large customer. They want to know how long something has been the case, and the honest answer is that nobody can say.

For agencies this is the first week

If you take on client websites, you inherit this problem repeatedly and it becomes your problem contractually. When a client's domain lapses, they call you, regardless of who was holding it.

The rational response is to establish what you have accepted before promising anything about it. Not a discovery call, an actual inventory: who holds the domain, when it renews, what the certificate covers, whether mail authentication passes, what subdomains are still resolving and pointing where.

That takes minutes and it converts an unknown liability into a written list. Several agencies bill it as a discrete piece of work in month one, and clients pay for it willingly, because the output is something they have never had.

The part that cannot be recovered

An inventory tells you the current state, and the current state is recoverable at any time — it is public, and anyone can look it up.

What is not recoverable is everything before the moment you looked. When the host changed. What the mail records said last year. Whether the certificate has been renewing cleanly or has in fact been manual since 2022. Those answers existed once and now do not, because nobody was recording.

Which means the inventory you take on day one is worth more as a starting point than as a document. Its value is not that it describes today. Its value is that from today onwards, changes have something to be compared against.

What to do about inherited infrastructure

Start by establishing what exists, which is quick. Then decide that from this point the state is recorded rather than remembered, which is the part that requires a decision rather than an afternoon.

The alternative is passing the same problem to whoever comes after you, which is how it reached you in the first place.

Related

Check yours

See where your own domain stands.

The free check finds all of it at once, in about ten seconds, without an account.