The message usually arrives on a Tuesday. Your DevOps engineer has found another job, they want to be fair about it, and they’re offering four weeks.
If that engineer was one of five on a platform team, this is a staffing problem. If they were the only one, it’s a different kind of problem. They hold the AWS root account, the only working copy of the deploy script, and a mental map of why the staging database has the name it has. None of it is written down because there was always something more urgent.
This post is a plan for the first 30 days. It assumes you have a notice period, a small engineering team, and nobody spare who can take over. We won’t tell you to hire fast. Hiring comes up in week four, after you know what you’re hiring for.
First 48 hours: get access and take inventory
Before anything else, find out what the company owns and who can get into it. Ask the departing engineer to walk you through the list below, and sit with them while they do it.
- Every cloud account, including the old ones nobody mentions. Check who holds the root credentials and where the MFA device is.
- The GitHub or GitLab organization, and which secrets are stored in the CI system.
- The domain registrar login, and whose inbox gets the renewal emails.
- Monitoring, error tracking, logging, the status page and the paging tool.
- Wherever passwords, API keys and certificates live. A password manager is fine. A text file on someone’s laptop is a finding.
Add a second admin to each of these now, while the person who can approve it is still around. It takes a day or two and it’s the most useful thing you’ll do all month.
Don’t remove the departing engineer’s access yet. Do that on their last day, from a checklist, so nothing breaks because a pipeline was quietly running under their personal token.
Week 1: get what’s in their head onto paper
Documentation written in the last two weeks of a notice period is usually thin. Nobody’s heart is in it. You’ll get more out of recorded walkthroughs than out of a wiki page.
Ask for screen recordings of the handful of things that would hurt most if nobody knew how to do them: deploying to production, rolling back a bad release, restoring the database from a backup, renewing certificates, rotating a leaked credential. Add whatever tends to break on weekends.
Each recording should show the real task, done live, with the engineer talking through it. Then have a developer follow the recording on their own. If they can finish the task, you’ve captured it. If they get stuck, the recording is missing a step, and it’s much better to find that out now.
Also ask the question people forget: what is running that isn’t in the repo? A cron job on a single VM. A script someone runs by hand on the first of the month. A Lambda function created through the console in 2022. These are the things that fail quietly three months after the handover.
Questions to ask the departing engineer
A handover goes better when you ask about judgment as well as facts. Documentation tells you what exists. These questions tell you where to look. Spend an hour on them in week 1, away from a keyboard if you can.
- What breaks most often, and what do you do when it does?
- What do you do by hand every week or every month?
- Which part of the system worries you most, and why?
- What would you fix first if you were staying?
- Which vendors, support contacts or account managers do we depend on, and who do you call at each?
- Which decisions would you make differently now?
- What are we paying for that nobody uses?
Write the answers down and keep them next to the runbooks. People tend to be candid in their last weeks, once the weight of being responsible for the system has eased. Take notes quickly and don’t argue with the answers.
Week 2: find the single points of failure
Now that you can see what exists, ask of each piece: what happens if this disappears, or if the one person who understands it is unreachable?
These questions tend to turn up real problems:
- Where does the infrastructure-as-code state live, and can anyone besides the departing engineer reach it?
- Have the backups ever been restored, or only taken?
- Which services have exactly one person who knows how they work?
- Whose phone do the alerts go to, and who gets them after the last day?
- What’s the monthly cloud bill, and would anyone notice if it doubled?
Put the answers in a plain table with three columns: the item, the risk, and who owns it after handover. It doesn’t need to look good. You end up with a short list of things that could ruin a weekend, and it gives you something concrete to hand to whoever you bring in next.
Here’s an illustrative version for a mid-sized SaaS company. Yours will differ, but the shape holds.
| Item | Risk | Owner after handover |
|---|---|---|
| Terraform state in one S3 bucket | Only the departing engineer can write to it, and state locking isn’t documented | Lead backend developer, plus a second admin |
| Nightly database backups | Never restored, and the steps aren’t written down | Rotating on-call developer, with a named runbook owner |
| TLS certificate renewals | Renewal emails go to the departing engineer’s inbox | Shared ops mailbox, with a calendar reminder |
| Production deploy script | Lives on one laptop, not in the repo | Moved to the repo, owned by the team that deploys |
| Cloud billing alerts | None set up | Engineering lead and finance, reviewed monthly |
Notice that the owners are roles or teams, not new individuals. A person can leave. A role with a runbook survives it.
Week 3: make the next incident survivable
Assume something breaks in week six. You want a developer who has never touched the infrastructure to be able to get through it.
Send alerts to a rotation that exists, even if it’s just a few developers sharing a channel. Write a one-page runbook for each of the top failure modes from your week 2 list: what to check, who to call, how to roll back. Then restore a backup into a scratch environment and time it. Teams are often surprised, either by how long it takes or by what turns out to be missing.
Freeze anything risky while you do this. No cluster upgrades, no moving the database to a new instance type, no “while we’re in there” refactors. The departing engineer’s last month is for handover, not new work.
If you want a reference for what a useful restore test looks like, we wrote up how to run a disaster recovery test that actually proves something.
Week 4: decide how you’ll staff this
By now you know what the job involves, so you can pick an option with real information. There are four realistic ones.
Hire a replacement. This is right if the work is steady and you have a way to find good people. Plan for the gap, though. A search takes time, and a new hire needs weeks to learn your setup, so you’ll want cover in between. We go into the details in our guide to hiring a DevOps engineer.
Promote a developer. This works when the person wants it and the scope is small. It goes badly when it lands on top of a full feature workload with nobody to ask.
Bring in a contractor. Good for a defined project. Weaker as your only safety net, because contractors leave too, and the knowledge leaves with them.
Use a managed DevOps service. A team runs the day-to-day work, covers on-call, and keeps the documentation current, so you don’t depend on any one person. The monthly cost is usually higher than a single salary line, but you’re buying coverage and process, not just a person. Our explainer on DevOps managed services covers what to expect.
Many companies end up with a mix: a managed service for the baseline and one in-house engineer who holds the context only your team has.
Mistakes to avoid
Rushing a hire just to fill the seat, then finding out the role was scoped wrong. A rushed hire is hard to undo.
Rewriting the infrastructure while it’s still running. The urge is strong in a crisis, and it’s almost always a bad month for it.
Making your best backend developer the DevOps person by default. They’ll be good at it, and you’ll lose your best backend developer.
Treating the exit interview as the handover. People say polite things in exit interviews and skip the awkward details. Schedule handover sessions separately and make them practical.
Waiting until the last day to ask for access. By then, the one person who can approve it is already halfway out the door.
How to stop key person risk from coming back
Key person risk is the exposure you carry when one person holds knowledge or access that nobody else has. It’s sometimes called the bus factor: how many people would have to disappear before the work stops. For a lot of small engineering teams, the honest answer for infrastructure is one.
Once the immediate handover is done, a few habits keep that number from sliding back.
Put every infrastructure change through code review, so a second person has seen it. Rotate who runs production deploys, so more than one person has done it under pressure. Keep runbooks in the repo next to the code they describe, and fix them when they turn out to be wrong instead of waiting for a documentation sprint. Hold a short access review every quarter: who has admin rights, who has left, which tokens belong to people rather than services. And when someone says “only I know how that works,” treat it as a ticket, not a boast.
Questions people ask
How long should a DevOps handover take?
Four weeks is workable if you start on day one and use it well. Two weeks is tight. In that case, do access, backups and the restore test first and leave the rest for later. If the engineer is leaving sooner than that, spend the time on access and recordings and bring in outside help for the rest.
What if the departing engineer isn’t cooperating?
Get admin access through the accounts you control, such as the cloud organization’s management account and the domain registrar, and don’t wait for goodwill. Record what you can and note what’s missing. If the relationship is decent, ask whether they’d consult for a few paid hours after they leave. Many people say yes, and it costs less than the alternatives.
Should we ask them to stay on as a consultant?
It’s worth asking, with a defined scope and an end date. A few hours a month for a quarter covers the questions nobody thought of. Treat it as a bridge, not a plan, and check any contract terms with your legal or HR team first.
