[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-infrastructure-handover-what-to-verify":3,"blog-post-adjacent-infrastructure-handover-what-to-verify":68},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":13,"datePublished":14,"dateModified":14,"category":15,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":38,"faqs":39,"sources":58,"relatedServices":59,"seo":63},"ox1bas3dj3druaycvjixyycq","Infrastructure Handover: What to Verify Before the Old Team Leaves","infrastructure-handover-what-to-verify","A password manager export is access, not a handover. What you need before the outgoing team stops answering: the inventory, the renewals, a proven restore, and a written responsibility boundary.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fblog_feature_infrastructure_handover_f8a8e8e662.jpg",3840,2160,null,"Dark cover reading \"Could another team run this tomorrow?\" over a knotted purple rope, for a post on what to verify at an infrastructure handover.","2026-09-18",{"name":16,"slug":17,"description":18,"seo":12},"Infrastructure and Operations","infrastructure-and-operations","DevOps, hosting, reliability and the operational work that keeps a system running once it is live.",{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":12,"photo":12,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"risk-management",{"name":30,"slug":30},"observability","An infrastructure handover transfers the ability to operate and recover the systems, not just access to them. Before the outgoing team stops answering, you need an inventory of everything that exists and everything that renews, named accounts rather than shared logins, a restore somebody has actually demonstrated, alerts that now reach you, and a written statement of who is responsible for what.",[33,34,35,36,37],"A handover transfers the ability to operate and recover a system. Access is the first item on the list, not the thing being delivered.","The inventory has to include everything that renews, not just everything that runs. Domains, certificates, and paid third-party accounts fail on a date nobody has written down, months after the handover looked successful.","\"Backups are configured\" is a claim. A restore performed in front of you, with a date against it, is evidence. Ask for the second one.","Monitoring usually keeps alerting whoever set it up. Until one real alert has arrived at your side and somebody has acknowledged it, the monitoring has not been handed over.","The responsibility boundary needs naming in writing: who responds, within what hours, to what, and what is explicitly not covered. \"They handle the servers\" is not a boundary.","Most infrastructure handovers arrive as a credentials export and a document.\nSometimes there is a call where somebody shares a screen and talks quickly.\n\nThat is a transfer of access. It is not a handover, and the difference tends\nto surface three months later, on a weekend, when something breaks and the\nonly person who understood it left in the spring.\n\nA handover has actually happened when a different team can operate and recover\nthe system without the previous one. Everything below is in service of that\none test.\n\n## What a handover is actually transferring\n\nThe deliverable is operability, not credentials. Can the new team keep the\nsystem running, notice when it is not, and put it back when it breaks?\n\nAccess is the first item on that list, and it is the one everybody remembers.\nThe items that get missed are the ones that only matter on a day that has not\nhappened yet: the renewal, the restore, the alert that goes to a mailbox\nnobody reads any more. A handover that covers only the things needed on\nTuesday is a handover that fails on the first day that is not a Tuesday.\n\n## Start with the inventory, including everything that renews\n\nYou cannot operate what nobody has listed. The inventory is the first\ndeliverable, and it has two halves that get very different levels of\nattention.\n\nThe half that gets attention is what runs: servers and instances, the\nservices on them, databases, storage, load balancers, the environments beyond\nproduction that people forget exist until one of them is compromised.\n\nThe half that gets missed is what renews:\n\n- Domains, and the registrar account they live in\n- TLS certificates, including any renewed by a script on a machine that is\n  itself not in the inventory\n- Paid third-party services, and which card or account pays for them\n- Licences and subscriptions attached to a person rather than the business\n- Scheduled jobs, including the ones that run monthly or annually and will not\n  be observed during the handover period\n\nRenewals are where handovers fail quietly. Everything works for four months,\nand then a certificate nobody owned expires on a Saturday, or a domain lapses\nbecause the renewal notice went to an address at the previous supplier.\n\n## Access, including the accounts nobody thinks to mention\n\nAccess needs to be named, not shared. An account per person, revocable\nindividually, is the difference between offboarding somebody and changing a\npassword everybody knew.\n\nThe accounts that get overlooked are usually the ones above the infrastructure\nrather than inside it:\n\n- The domain registrar, which is frequently in someone's personal account\n- The DNS provider, which is often not the same company as the registrar\n- The billing owner of the cloud account, which is a different thing from\n  technical access to it, and the one that becomes urgent when a card expires\n- The mailbox or channel that receives alerts, certificate warnings, and\n  provider notices\n- The account that owns the monitoring itself\n\nFor each one, the useful question is not \"do we have the password\". It is\n\"if the previous supplier stopped cooperating tomorrow, could we still get\ninto this\". Where the answer is no, that is a dependency, not a detail.\n\n## Backups: ask to watch a restore, not to read a policy\n\nAt the moment of handover, the useful artefact is not a backup policy. It is a\nrestore that somebody performed in front of you, with a date against it.\n\n\"Backups are configured\" describes an intention. A completed restore is\nevidence, and the gap between the two is where most unpleasant surprises live:\nthe backup that has been running successfully for a year against a database\nthat stopped being the live one in March, or the one that captures the\napplication and not the uploads.\n\nAsk for one restore, into a non-production environment, watched by whoever\nwill own it afterwards. What it should produce is a working system and a note\nof how long it took, because how long it takes is what you will need to know\non the day you do it for real. The deeper question of how often to test, and\nwhat a restore plan needs to cover, is a bigger topic than a handover; here,\none demonstrated restore is the bar.\n\n## Monitoring is not handed over until an alert reaches you\n\nMonitoring usually keeps alerting the people who set it up. That is the\ndefault, and it survives the handover unless somebody deliberately changes it.\n\nSo the check is not \"is monitoring in place\". It is: has one real alert\narrived at our side, and did somebody acknowledge it? Trigger a genuine one\nduring the handover window. Take a service down in a non-production\nenvironment, or let a test threshold breach, and follow where the notification\nlands.\n\nTwo things usually surface when you do. The alert goes somewhere unexpected,\nlike a shared mailbox at the old supplier or an individual's address. And the\nvolume is wrong: either everything is quiet because thresholds were tuned into\nsilence, or there is enough routine noise that a real alert would not stand\nout. Both are better found during a handover than during an incident.\n\n## Write down who is responsible, for what, and when\n\nThis is the part most often left as an understanding rather than a document,\nand it is the part that matters at two in the morning.\n\n\"They handle the servers\" is not a boundary. A boundary names the hours inside\nwhich someone responds, the kinds of problem they respond to, how they are\nreached outside working hours, how long the acknowledgement should take, and\nwhat is explicitly not covered. The exclusions carry as much weight as the\ninclusions, because an exclusion stated plainly is a decision, while an\nexclusion nobody mentioned is an assumption held by two parties in different\ndirections.\n\nIf the answer to \"who is responsible for this\" is a company name rather than a\nrole, the boundary is not finished. Somebody has to be reachable, and\nsomebody has to be accountable for the fact that they were reachable.\n\n## The test that settles whether the handover happened\n\nBefore the outgoing team stops answering, have the incoming team perform a\nroutine operation while the outgoing team watches without touching anything.\n\nA deploy. A restore of a single file. A certificate rotation. A server\nrestarted in the correct order, with whatever depends on it coming back.\n\nThis is the only part of a handover that cannot be faked with documentation,\nand it converts the whole exercise from a list into a demonstrated fact. Every\nquestion the incoming team has to ask during that exercise is a gap in the\ndocumentation, written down for free.\n\nThe brief version of that test, and a reasonable thing to ask any outgoing\nsupplier: could another team run this tomorrow?\n\n## What usually goes wrong months later\n\nHandovers rarely fail on day one. They fail on the first day that requires\nsomething nobody rehearsed.\n\nThe recurring causes are consistent. Something renewed on a schedule and\nnobody owned the renewal. A job ran on a machine that was never inventoried. A\nsingle person's personal account turned out to be load bearing. An alert had\nbeen arriving somewhere unread since the week of the transition.\n\nNone of those are exotic failures. They are all the same failure: an item that\nwas never listed, so it was never assigned to anybody.\n\nIf you have inherited infrastructure and are not certain what you actually\nhold, that is worth establishing before something forces the question. Review\nwho owns what across your infrastructure now, while it is a documentation\nexercise rather than an incident.",[40,43,46,49,52,55],{"question":41,"answer":42},"What should be included in an infrastructure handover?","An inventory of everything that runs and everything that renews, named individual accounts for every system including the registrar and DNS, a restore that has been demonstrated with a date against it, monitoring re-pointed so alerts reach the new team, and a written boundary stating who responds to what and within what hours. Access alone is not a handover.",{"question":44,"answer":45},"How do you know whether a handover was actually completed?","Have the incoming team perform a routine operation while the outgoing team watches without touching anything: a deploy, a single file restore, or a certificate rotation. Documentation can look complete and still be unusable. Every question the incoming team has to ask during that exercise is a gap you have found while somebody is still available to answer it.",{"question":47,"answer":48},"Why do infrastructure handovers fail months after they look successful?","Because they fail on the first day that requires something nobody rehearsed. The usual causes are a renewal nobody owned, a scheduled job on a machine that was never inventoried, a personal account that turned out to be load bearing, and alerts arriving somewhere unread since the transition. Each is the same failure: an unlisted item nobody was assigned.",{"question":50,"answer":51},"Is a list of credentials enough to take over hosting?","No. Credentials give you access, which is the first item on a handover list rather than the deliverable. Without an inventory, a proven restore, working alert routing, and a stated responsibility boundary, you have the ability to log in to a system you cannot yet operate or recover. Those are different things.",{"question":53,"answer":54},"What is the most commonly missed item in a hosting handover?","Anything that renews. Domains, TLS certificates, paid third-party services, and licences attached to a person rather than the business all keep working after the handover and then fail on a date nobody recorded. Certificates renewed by a script on an uninventoried machine are a particularly common version of this.",{"question":56,"answer":57},"Who should be responsible for infrastructure after a handover?","A named role, not a company. The boundary should state who responds, the hours they respond in, how they are reached out of hours, the expected acknowledgement time, and what is explicitly excluded. Exclusions matter as much as inclusions, because one stated plainly is a decision while one left unmentioned is an assumption two parties hold differently.",[],[60,61,62],"managed-hosting","devops-infrastructure","it-consulting",{"metaTitle":64,"metaDescription":65,"ogImage":66,"canonicalPath":12,"noindex":67},"Infrastructure Handover Checklist: What to Verify","A server login is not a handover. What to verify before the outgoing team leaves: inventory, renewals, named accounts, a proven restore, alerts, and ownership.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":69,"next":12},{"id":70,"title":71,"slug":72,"excerpt":73,"cover":74,"coverAlt":78,"datePublished":79,"dateModified":79,"category":80,"author":81,"tags":82},"x241areyikdk5hz1bp7r0a10","What an Incident Runbook Should Actually Contain","what-an-incident-runbook-should-actually-contain","Most incident runbooks are either too vague to use under pressure or too detailed to keep current. Here is what actually earns a place in one.",{"url":75,"width":76,"height":77,"alt":78},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fwhat_an_incident_runbook_should_actually_contain_cover_0b0a204432.png",1200,630,"What an Incident Runbook Should Actually Contain - cover image (seed-blog-content-cover)","2026-09-05",{"name":16,"slug":17},{"name":20,"slug":21},[83,84,86],{"name":30,"slug":30},{"name":85,"slug":85},"process-design",{"name":28,"slug":28}]