Infrastructure Handover: What to Verify Before the Old Team Leaves

Most infrastructure handovers arrive as a credentials export and a document. Sometimes there is a call where somebody shares a screen and talks quickly.

That is a transfer of access. It is not a handover, and the difference tends to surface three months later, on a weekend, when something breaks and the only person who understood it left in the spring.

A handover has actually happened when a different team can operate and recover the system without the previous one. Everything below is in service of that one test.

#What a handover is actually transferring

The deliverable is operability, not credentials. Can the new team keep the system running, notice when it is not, and put it back when it breaks?

Access is the first item on that list, and it is the one everybody remembers. The items that get missed are the ones that only matter on a day that has not happened yet: the renewal, the restore, the alert that goes to a mailbox nobody reads any more. A handover that covers only the things needed on Tuesday is a handover that fails on the first day that is not a Tuesday.

#Start with the inventory, including everything that renews

You cannot operate what nobody has listed. The inventory is the first deliverable, and it has two halves that get very different levels of attention.

The half that gets attention is what runs: servers and instances, the services on them, databases, storage, load balancers, the environments beyond production that people forget exist until one of them is compromised.

The half that gets missed is what renews:

• Domains, and the registrar account they live in
• TLS certificates, including any renewed by a script on a machine that is itself not in the inventory
• Paid third-party services, and which card or account pays for them
• Licences and subscriptions attached to a person rather than the business
• Scheduled jobs, including the ones that run monthly or annually and will not be observed during the handover period

Renewals are where handovers fail quietly. Everything works for four months, and then a certificate nobody owned expires on a Saturday, or a domain lapses because the renewal notice went to an address at the previous supplier.

#Access, including the accounts nobody thinks to mention

Access needs to be named, not shared. An account per person, revocable individually, is the difference between offboarding somebody and changing a password everybody knew.

The accounts that get overlooked are usually the ones above the infrastructure rather than inside it:

• The domain registrar, which is frequently in someone's personal account
• The DNS provider, which is often not the same company as the registrar
• The billing owner of the cloud account, which is a different thing from technical access to it, and the one that becomes urgent when a card expires
• The mailbox or channel that receives alerts, certificate warnings, and provider notices
• The account that owns the monitoring itself

For each one, the useful question is not "do we have the password". It is "if the previous supplier stopped cooperating tomorrow, could we still get into this". Where the answer is no, that is a dependency, not a detail.

#Backups: ask to watch a restore, not to read a policy

At the moment of handover, the useful artefact is not a backup policy. It is a restore that somebody performed in front of you, with a date against it.

"Backups are configured" describes an intention. A completed restore is evidence, and the gap between the two is where most unpleasant surprises live: the backup that has been running successfully for a year against a database that stopped being the live one in March, or the one that captures the application and not the uploads.

Ask for one restore, into a non-production environment, watched by whoever will own it afterwards. What it should produce is a working system and a note of how long it took, because how long it takes is what you will need to know on the day you do it for real. The deeper question of how often to test, and what a restore plan needs to cover, is a bigger topic than a handover; here, one demonstrated restore is the bar.

#Monitoring is not handed over until an alert reaches you

Monitoring usually keeps alerting the people who set it up. That is the default, and it survives the handover unless somebody deliberately changes it.

So the check is not "is monitoring in place". It is: has one real alert arrived at our side, and did somebody acknowledge it? Trigger a genuine one during the handover window. Take a service down in a non-production environment, or let a test threshold breach, and follow where the notification lands.

Two things usually surface when you do. The alert goes somewhere unexpected, like a shared mailbox at the old supplier or an individual's address. And the volume is wrong: either everything is quiet because thresholds were tuned into silence, or there is enough routine noise that a real alert would not stand out. Both are better found during a handover than during an incident.

#Write down who is responsible, for what, and when

This is the part most often left as an understanding rather than a document, and it is the part that matters at two in the morning.

"They handle the servers" is not a boundary. A boundary names the hours inside which someone responds, the kinds of problem they respond to, how they are reached outside working hours, how long the acknowledgement should take, and what is explicitly not covered. The exclusions carry as much weight as the inclusions, because an exclusion stated plainly is a decision, while an exclusion nobody mentioned is an assumption held by two parties in different directions.

If the answer to "who is responsible for this" is a company name rather than a role, the boundary is not finished. Somebody has to be reachable, and somebody has to be accountable for the fact that they were reachable.

#The test that settles whether the handover happened

Before the outgoing team stops answering, have the incoming team perform a routine operation while the outgoing team watches without touching anything.

A deploy. A restore of a single file. A certificate rotation. A server restarted in the correct order, with whatever depends on it coming back.

This is the only part of a handover that cannot be faked with documentation, and it converts the whole exercise from a list into a demonstrated fact. Every question the incoming team has to ask during that exercise is a gap in the documentation, written down for free.

The brief version of that test, and a reasonable thing to ask any outgoing supplier: could another team run this tomorrow?

#What usually goes wrong months later

Handovers rarely fail on day one. They fail on the first day that requires something nobody rehearsed.

The recurring causes are consistent. Something renewed on a schedule and nobody owned the renewal. A job ran on a machine that was never inventoried. A single person's personal account turned out to be load bearing. An alert had been arriving somewhere unread since the week of the transition.

None of those are exotic failures. They are all the same failure: an item that was never listed, so it was never assigned to anybody.

If you have inherited infrastructure and are not certain what you actually hold, that is worth establishing before something forces the question. Review who owns what across your infrastructure now, while it is a documentation exercise rather than an incident.