Your Only Backend Engineer Just Quit:
A 30-Day Takeover Plan

Your only backend engineer has given notice, the wiki is a README from the first month, and nobody else has ever deployed the thing. If the developer left no documentation, or is about to, the next few weeks decide whether this is an awkward quarter or an outage you can't explain. There is a notice period to use and a reason to spend on it now.

One fact sets the priority. The Azure activity log keeps management events for 90 days, and Microsoft's documentation says it is the only place that records who created a resource. After that, the answer to "who set this up, and why?" exists only in one person's head. Everything in this article follows from that split: some knowledge can be read out of your systems after the engineer leaves, and some can't.

Below is a ranking of what to get out of the departing engineer, ordered by what can't be recovered afterwards. After it comes a week-by-week 30-day plan, the checks that use Azure's own documented behaviour, and the limits of the approach. It's written for the founder or CTO holding the notice letter. Notice terms, when to cut access, and anything about the person's obligations are matters for your counsel and HR. This article covers the engineering steps only.

Developer Left No Documentation? Rank the Gaps by Whether They Can Be Recovered

Most takeover checklists start with an architecture diagram and a code walkthrough. Those are the worst use of the first days, because a competent engineer can rebuild both from the repository and the cloud subscription. The scarce resource is the engineer's remaining time, so spend it only on what the system can't tell you later. Here is the ranking we use. It's our own model, not a standard, and it sorts each hand-over item by what is left afterwards.

The order is the point. Items one and two are lost if you wait. Items three and four are half-recoverable: a stranger can find the schedule and read the pipeline, but not the intent behind either. Item five is recoverable from the tenant, as long as the activity log is exported before its 90 days run out, so it ranks last. It goes first in the plan anyway because it takes an afternoon and protects the rest. Rank by recoverability, and ask the person only for what the system can't say.

Week 1: Secure What Can Expire

Start with the access checks, and start the day the notice is given. None needs the engineer's cooperation, and each closes a way for the handover to fail.

• Make sure at least two other people can administer the subscription. In the Azure portal, open the subscription, then Access control (IAM) and the Role assignments tab, and read the Owners section. The documentation walks through it. Assigning roles takes the role-assignment write permission, which the Owner and User Access Administrator roles carry, so check that at least two people besides the departing engineer hold one of them, at the subscription or above.
• Export the activity log now. Retention is 90 days by default, and creator information is only in the log. A diagnostic setting can send it to a Log Analytics workspace, where retention can be extended. Note the limit: the activity log covers control-plane changes and doesn't typically record reads. Data-plane events, such as a secret being read from a key vault, need resource logs and a diagnostic setting, and aren't collected by default.
• Find out who can read your secrets. A key vault uses either Azure RBAC or the legacy access-policy model. Under RBAC, Key Vault Reader shows metadata but can't read secret contents. Key Vault Secrets User and Key Vault Administrator can. The Key Vault RBAC guide also warns that a user with the Contributor role on the vault's control plane can grant themselves data-plane access by setting an access policy. And it warns that switching the permission model to RBAC invalidates every access-policy permission and can cause outages. Read both before anyone touches a vault during a handover. It is the wrong week to change a permission model.
• List every credential and its expiry date. In the Microsoft Entra admin center, each app registration has a Certificates & secrets page. Per Microsoft's documentation, a client secret's lifetime is capped at 24 months, and Microsoft recommends under 12. Whoever created each secret knew the date it stops working. Write the dates down with an owner, and move the ones on the calendar inside the next quarter first. The same page recommends certificates or federated credentials over secrets in production. Certificates still expire, but it describes federated credentials as letting workloads such as GitHub Actions authenticate without managing secrets at all. If a pipeline deploys through an Azure DevOps service connection that created its own service principal, the page says to update that secret from Azure DevOps rather than directly in Entra.
• Put a delete lock on production. A CanNotDelete lock stops deletion by every user and role, and it needs the locks permission that Owner and User Access Administrator carry. Two caveats from the locks documentation. Locks apply to control-plane operations only, so they don't protect data. And a cannot-delete lock also prevents deleting role assignments, so finish any access cleanup first. Prefer it over a read-only lock: the same page says a read-only lock on a resource group containing an automation account stops all runbooks from starting.

Weeks 1 to 2: Inventory the Scheduled Work

Scheduled jobs are where a one-person system hides its promises. A report that lands in someone's inbox every Monday, a cleanup that keeps a table small, a sync with a partner: each is a commitment nobody listed. There is no single list of them, because the schedule can live in several places:

• Azure Functions timer triggers. Defined in code or, if the attribute holds a name wrapped in percent signs, in an app setting. The timer trigger reference says the default time zone is UTC, that only one instance runs when the app scales out, and that a failed run isn't retried by default: the function isn't called again until the next time on the schedule. A function can opt in to a retry policy, and Microsoft's retry guidance describes the maximum retry count as best effort. So look for one, and keep asking the question for every job: what happens to the business if one run never happens?
• Azure Automation. A runbook is linked to one or more schedules, and a schedule can carry several runbooks, per the Automation schedules page. Look under Schedules in the Automation account.
• SQL Server Agent. In SQL Server Management Studio, jobs are under SQL Server Agent, then Jobs (documented here).
• Virtual machines. Windows Task Scheduler tasks and cron entries on any host the engineer could log in to.

The naive way to start is to search the code for the trigger attribute. This is what most people run first:

# NAIVE: prints matching lines from this one repo. It doesn't resolve
# %SettingName% schedules and knows nothing about anything outside the repo.
git grep -n "TimerTrigger"

That misses every schedule stored in an app setting, and it only reads one repository. A better version resolves what it can and marks what it can't, then covers the machines as well:

# 1. Every timer trigger in the repo: the schedule, or the app setting to look up.
git grep -n -o -E 'TimerTrigger\([^)]*\)' -- '*.cs' |
  ForEach-Object {
    $file,$line,$call = $_ -split ':',3
    $schedule = $call -replace '^TimerTrigger\("?','' -replace '"?(,[^)]*)?\)$',''
    [pscustomobject]@{ File=$file; Line=$line; Schedule=$schedule
      Where = if ($schedule -match '^%([^%]+)%') { "app setting $($Matches[1])" } else { 'in code' } }
  }

# 2. On each Windows host: tasks that aren't Microsoft's, and the account they run as.
schtasks /query /fo csv /v | ConvertFrom-Csv |
  Where-Object { $_.TaskName -ne 'TaskName' -and $_.TaskName -notlike '\Microsoft\*' } |
  Select-Object TaskName, 'Next Run Time', 'Run As User', 'Task To Run'

Step one prints one row per attribute with its file and line. A row whose Where says "app setting" sends you to the function app's configuration for the real value. It won't catch a schedule built from a constant, or an attribute split across lines, so treat it as a first pass. Step two shows the identity each task runs as, and that column matters: a job that runs as the departing engineer's account stops with the account. The output is only an inventory. For each row you still owe the questions from the table: who owns it, what breaks if a run is skipped, and is it safe to run twice.

The Item That Never Shows Up in an Inventory

Manual data fixes rank first because nothing points at them. The pattern is familiar: support asks for a record to be corrected, or a partner's file arrives malformed, and the one engineer who understands the schema patches it directly in the database. It works, it's never written down, and it happens every month. Ask for the list in a working session, not a document: "walk me through the last five times you changed production data by hand." Each answer should end as a named script that logs what it changed, supports a dry run, and is reviewed by a second person before it runs.

The goal isn't to automate everything at once. It's to make each manual step visible. In our 1099 reporting automation work, the first digital-asset filing cycle went through a deliberate manual submission by the client team, and the code made the manual-versus-automated choice an explicit, per-item switch instead of something people just knew. A manual step that the code names can be handed over. One that lives in a person's routine leaves with them.

The 30-Day Plan, Week by Week

The weeks follow the ranking, adjusted for what is time-limited. If the last day falls inside week one, do the rows in order until it arrives and carry the rest on afterwards. This is the emergency version of the sequence in our Series B health-check article, which treats key-person risk as one item in a wider fundraising prep. This article is the version for when the notice period is already running.

A note on the deploy in week three. A new senior hire three weeks in is not a second owner of anything: the second owner is whoever has done the deploy while the first watched. That is why the plan asks for a witnessed deploy and not a longer document. For the moment the person leaves, the Microsoft Entra documentation on revoking user access lists the engineering steps: disable the account and revoke sessions. By default an access token lasts one hour, and an application that issues its own session token has to end that session itself. Anything the person knew that isn't tied to their account, such as a shared secret or a vendor password, stays valid until someone rotates it. That last point is our advice, not the page's. When to run these steps, and whether the departure terms allow the timing you want, is for your counsel and HR.

What This Plan Doesn't Solve

• Understanding. Thirty days makes the system operable by a second person. It doesn't make anyone understand why it is designed as it is. Expect the "why" to come back slowly, through incidents and code reading.
• An unwilling engineer. Every hand-over session assumes the person turns up and answers honestly. If they don't, the plan degrades to reverse engineering, and items one and two are the ones you lose.
• Data-plane visibility. The activity log shows control-plane changes. It won't tell you who read a secret last month unless resource logs were already collected.
• Systems outside Azure. Nothing above will find the scheduled task on a machine under someone's desk, or an account with a vendor. Those come from the interviews and from asking every colleague "what does this person do that only they do?"
• The legal and HR side. Notice terms, access timing, ownership of work product and confidentiality are outside what an engineering plan can settle.

One condition where we'd do something different: if the engineer is leaving on bad terms, or you have reason to distrust their access, skip the hand-over sessions. Take counsel's advice on timing, cut access first, rotate every credential the person could have seen, and treat the whole system as a reverse-engineering job. The ranking still holds, but items one and two become losses you plan around. Budget for that outcome, and don't hope for a good handover you can't rely on.

What do you do when a developer leaves and there is no documentation?

Separate what the system can tell you from what only the person knows, and spend the notice period on the second group. Role assignments, credential expiry dates, deployed resources and scheduled jobs can be read out of the environment afterwards. Manual data fixes, accounts held outside your cloud tenant, the purpose of each scheduled job and the unwritten steps of a deploy cannot. Get those first, make a second person perform a real deploy while the first one watches, and secure what can expire before the last day.

What should a departing backend engineer hand over first?

Start with the items that leave no trace in the system: every time they changed production data by hand and why, every account or console that is registered to their own login, what each scheduled job does and what breaks if it stops, and the actual steps of a deploy including the ones nobody wrote down. Architecture diagrams and code walkthroughs come last, because the code and the cloud resources can be read by someone else afterwards.

How do I find every scheduled job running in our Azure environment?

Check each place a schedule can live, because there is no single list. Azure Functions timer triggers are defined in code or in an app setting, Azure Automation links runbooks to schedules, SQL Server Agent keeps jobs on the database server, and virtual machines can have Windows Task Scheduler tasks or cron entries. For each job record the schedule, the identity it runs as, what it does and what breaks if a run is skipped. By default, a timer-triggered function that fails is not called again until the next scheduled time, unless a retry policy is configured.

How do I check who has access to our Azure secrets and accounts?

List the Owner role assignments on the subscription, then the role assignments on each key vault, and confirm which permission model each vault uses. Key Vault Reader shows metadata but cannot read secret contents, while roles such as Key Vault Secrets User and Key Vault Administrator can. Then open each app registration's Certificates and secrets page and record every expiry date. Client secrets can live for at most 24 months, so each one is a dated failure waiting to happen. Accounts held with vendors outside Azure will not appear in any of these lists and must be collected by hand.

How long does it take to take over a backend built by one person?

There is no honest fixed number, because it depends on how much of the system lives in one person's head. Thirty days is enough to stabilize it: a second person has performed a deploy, credentials with expiry dates are inventoried and owned, scheduled work is listed with owners, and the manual fixes have names. It is not enough to understand the whole system. Plan for understanding to continue for months, and rank the remaining gaps by what they would cost if wrong.

When to Bring in External Help

You can run weeks one and two yourself if a second engineer has the time. Outside help pays off when there is no second engineer, when the engineer has already gone, or when the inventory turns up more than one person can work through. The choice between adding a contractor and adding a firm is covered in embedded architect vs consulting agency. Our Embedded Partner model is one option, and we say so up front because we sell it.

If your backend shows any of the patterns above, our Discovery Sprint is a two-week diagnostic that tells you exactly what to fix and in what order. For a takeover that means an inventory of access, credentials, scheduled work and deploy steps, ranked by what can't be recovered, so the next quarter starts from a written list and not from a resignation letter.

Back to Insights