When the one developer who built a system leaves, the system usually keeps running. Orders still go through, the nightly sync still runs, and for a few weeks nobody notices anything. What has changed is that the knowledge of how it works, and often the accounts it runs on, left with them.
This guide is for the IT manager, operations lead, finance lead or owner who now answers for software they did not choose. The order matters more than any single step: secure access first, find out what you actually have second, and decide what to change last.
Before they go: the handover worth asking for
If the developer is still working out their notice, or left on good terms and still answers email, this is the cheapest window you will get. Do not ask them to document the code. It takes weeks, it is out of date the day it is finished, and whoever takes over will read the code anyway. Ask for the things nobody can reconstruct from the code.
Ask for these before the last day
- Every account the system uses, who owns each login, and where the password is kept: the cloud portal, the database, source control, the domain registrar, and the email, SMS and payment providers.
- How a change reaches production, step by step. Better still, ask them to do one real deployment on a shared screen while someone records it.
- Everything that runs on a schedule, and what happens when it fails.
- Everything that renews or expires: domains, certificates, client secrets, software licenses, and the card the cloud bill is charged to.
- The three things they were worried about. Every developer has that list. It is the most valuable ten minutes of the handover.
If they were a contractor or an agency, check what the contract says about who owns the code and the accounts, and move both into your name while the relationship is still friendly.
If they left on bad terms, stay inside what belongs to the company. Resetting passwords on company accounts is yours to do. Signing in to the developer's personal accounts is not. Providers have recovery routes for a business that can prove an account is its own: Azure DevOps support, for example, can reassign an organization whose owner is gone once you show billing records or similar proof of your relationship to it.
The first week: what to secure
In rough order of how badly each one hurts if it goes wrong. Most of this needs no developer at all. It needs someone with the authority to sign in, and an afternoon.
The source code repository Day 1
Find out where the code lives (GitHub, Azure DevOps, Bitbucket, or a folder on someone's laptop) and whose account owns it. A repository under the developer's personal GitHub account is under their control, whatever the contract says about who owns what is in it. Have it transferred to an organization account your company owns: GitHub moves the history, issues and pull requests with it and redirects the old address. Then check the collaborator list, because GitHub adds the original owner back as a collaborator on a transferred repository. In Azure DevOps, make sure your company holds the organization owner role and that at least two of your people are Project Collection Administrators. Finally, take a full copy with history (git clone --mirror) and keep it somewhere the developer never had access to.
Accounts and credentials Day 1
Write the list before you change anything: every login and every secret the system uses, where each one is stored, and who else knows it. Then disable the developer's own accounts in your directory, and rotate the shared passwords and keys they knew. Rotate deliberately, one at a time, and test after each. A key changed in a portal but not in the application's configuration takes production down, and on day one nobody knows where that configuration is.
Two traps catch people here. In Azure DevOps a personal access token belongs to the user who created it, and disabling the account revokes it, so a pipeline or script that was quietly running on the developer's token stops the day you lock them out. And a password or key found committed in the repository should be treated as known to everyone who ever cloned it. GitHub's own guidance is to revoke or rotate it first, before anything else.
Domain name and DNS Week 1
Sign in to the registrar account and check three things: that the account is in the company's name with a company email address, that auto-renew is on, and which card the renewal is charged to. A domain registered in a developer's own account, renewing on their own card, is the hardest item on this list to recover and the most expensive to lose, because your email depends on the same DNS records as the website. If nobody knows the registrar, ICANN Lookup shows it. Then find where DNS is actually hosted, which may not be the registrar, and export a copy of the zone records.
Cloud subscription ownership Week 1
In Azure there are two questions, and they have different answers more often than people expect. Who can manage the resources: check who holds the Owner role on the subscription, and make sure at least two people in your company do. And who pays: the billing account the subscription belongs to. If either answer is the developer or their agency, fix it now.
Billing ownership of a pay-as-you-go subscription can be transferred to your account. Do not tick the option that also moves the subscription into your Microsoft Entra directory unless you have planned for it: a directory move permanently deletes every role assignment, breaks managed identities and needs Key Vault reconfigured, and Microsoft warns it can mean downtime. Transferring billing alone keeps the role assignments in place. Microsoft also recommends two cloud-only emergency access accounts in your directory, so that no single departure can lock you out. On AWS, the equivalent question is the root user: the email address it signs in with, and the device that holds its MFA.
Deployment steps Week 1
Find out how a change reaches production. A pipeline file in the repository (azure-pipelines.yml, or files under .github/workflows) is good news: the steps are written down and run somewhere other than a laptop. A publish profile in Visual Studio, an FTP upload or a script on the developer's machine is not, because those steps left with the machine. Write down what you find, even if it is only "publish from Visual Studio, on a laptop we no longer have." Then, unless something is broken, deploy nothing this week.
Backups Week 1
Find out whether a backup exists, how old the newest one is, and whether anyone has ever restored one. Azure SQL Database keeps point-in-time backups automatically, for seven days by default and configurable up to 35, but that covers the database only. Uploaded files, storage accounts and anything on a virtual machine need their own answer. Restore the database to a new, separate database, open it, check the latest rows are there, and delete it. A backup nobody has restored is a hope, not a backup.
What not to do in the first week: rewrite it, upgrade it, rotate every secret at once, or hire the first person who says it has to be started again. Each of those is a decision, and you do not yet have what you need to make it.
How to find out what you actually have
Once nothing can be lost, read what is there. This is the step most often skipped, because the system is working and reading it feels like a cost with no output. It is the opposite: every estimate you get later is only as good as this inventory, and without it the person quoting is guessing too.
- Build it on a clean machine. Not the developer's laptop, and not one of yours that has been used for anything else: a fresh virtual machine or a build agent, with only the tools the repository says it needs. If it builds, you have proof the repository contains the system. If it does not, the errors are your first findings: a private package feed that needed their login, a file that only existed on their disk, a hard-coded path, a tool version nobody wrote down.
- Find the commit production is running. Compare what is deployed with what is in the repository. If nobody can say which commit is live, assume production contains changes the repository does not, and treat the next deployment from the repository as a risk until you know.
- List the dependencies and their support dates. The runtime the code targets, every package it pulls in, the database engine, the server operating system, and the outside services it calls. For .NET code, run
dotnet package list --outdated, then--deprecated, then--vulnerable(on SDKs older than .NET 10 the same command isdotnet list package). Paste the projects' TargetFramework lines into the free .NET end-of-support checker to date each runtime. - Map where it runs. Every web app, function app, database, storage account, virtual machine and scheduled job, and which of them talk to each other. The cloud bill is the most honest map you have: if it is charged, it is running. Card statements show the outside services the system pays for, and the DNS records show which addresses point where.
- List what runs on a schedule. Timer-triggered functions, WebJobs, SQL Server Agent jobs, Windows scheduled tasks, Logic Apps, and anything else that runs at 2 a.m. Scheduled work fails quietly, which is why it is where the surprises are.
- Put it on one page. A diagram a non-developer can follow, the account list from the first week, and the support dates. That page is what makes the next developer, or the next vendor, cheaper.
The support dates that most often catch an inherited Microsoft system:
| Component | End of support | What it means for you |
|---|---|---|
| SQL Server 2016 | July 14, 2026 | Security updates continue only through paid Extended Security Updates |
| .NET 8 and .NET 9 | November 10, 2026 | No further security patches for applications on either runtime |
| Azure Functions in-process model | November 10, 2026 | Each function moves to the isolated worker model, which is a rewrite, not a version bump |
| Windows Server 2016 | January 12, 2027 | Extended support ends for the server and its containers |
| .NET Framework 4.6.2 | January 12, 2027 | Move to 4.7 or later; 4.8 and 4.8.1 follow the Windows lifecycle |
For what changes when a .NET 8 application moves to .NET 10, see .NET 8 and .NET 9 end of life: what actually breaks.
Warning signs in an inherited system
Some of what the inventory turns up is cosmetic. These are the findings that mean the system needs attention, roughly in order of urgency.
An account or domain you cannot get into Act now
If the registrar, the cloud subscription or the repository is still in the developer's name and they are not answering, everything else waits. These are the findings that can turn into an outage nobody on your side is able to fix.
Nobody can deploy a change Act now
If the deployment steps left with the developer, the next urgent fix has no way to reach production. Rebuilding a deployment pipeline is ordinary work. Discovering it is needed during an outage is not.
Secrets in the code, or one shared admin login Soon
Passwords and keys committed to the repository, or a single administrator account that several people used, including the one who left. Either way you cannot tell who still has access, so assume the developer does until each one is rotated.
Something stops working on an anniversary Soon
A sign-in, an integration or a scheduled job that has worked for exactly a year or two fails one morning. That is usually an expired certificate or client secret. A Microsoft Entra client secret lasts at most 24 months, and Microsoft recommends less than 12, so a system built two years ago has an expiry date coming whether anyone wrote it down or not. The app registration's Certificates & secrets page shows each one.
A runtime or database past its end-of-support date Soon
Nothing stops working on the date. The security patches stop, and auditors, insurers and customer security questionnaires catch up with that sooner than most teams expect.
It fails without telling anyone Chronic
Two systems that are supposed to agree, and sometimes do not. You hear about it from a customer, a vendor or the month-end close, never from an alert. Silent failure is the expensive kind, because it compounds before anyone sees it.
Every change breaks something else Chronic
No tests, no separate test environment, and each small edit goes straight to the live system. It is why a one-line change comes back quoted as a week of work.
Repair, replace in stages, or leave it alone
Once you know what you have, the choice is narrower than the quotes make it sound. There are three honest options and one tempting one.
| Option | Choose it when | What it takes | The risk |
|---|---|---|---|
| Leave it alone | It works, it runs on supported versions, and nothing around it is changing | The first-week work, monitoring, a review date | That nobody checks again |
| Repair | The foundations are sound and the problems are specific: deployment, secrets, a failing integration, an old runtime | Weeks, in fixed pieces | Low, when each fix ships on its own |
| Replace in stages | The core is too weak to repair economically, or the platform under it is going away | Months, delivered one piece at a time | Moderate; the old system keeps running until the last piece moves |
| Rewrite all at once | Rarely the right answer | Months before anything ships | High; the new system has to rediscover years of unwritten rules |
Leaving it alone is a real decision. An unglamorous system that does one job reliably costs less to keep than to improve. Leaving it alone still means doing the first-week work, writing down what would make it urgent (an end-of-support date, a change to a vendor's API, a new requirement), and putting a review date in the calendar.
Repair is where most inherited systems land. The code is usually rougher than it is broken. A working deployment pipeline, secrets moved out of the code and into Azure Key Vault, a supported runtime, and a handful of tests around the paths the business depends on change the risk far more than they change the code.
Replace in stages when the foundation is the problem. Microsoft's Azure Architecture Center describes this as the Strangler Fig pattern: put a facade in front of the old system, move one piece of functionality at a time to the new one, and route each request to whichever side owns that piece, until the old system has nothing left to do. The business keeps running on the old system the whole time, and each piece can be checked against it before it takes over.
Be wary of the full rewrite. It is the option most often recommended by someone meeting the system for the first time, and the one with the least to show for the longest. A rewrite has to rediscover every rule the old system enforces, including the ones nobody wrote down, before it can replace anything, and the old system still needs looking after in the meantime.
Whoever makes this call needs the inventory above, and should be able to show you the reasoning. If you would rather have that done for you, our software project rescue starts with a fixed-price, read-only assessment of one application: a written report that maps what you have, ranks what is wrong, and recommends repairing, replacing in stages or leaving it alone, with a fixed price for each fix. The report is yours whatever you decide.
A first month, week by week
Days 1 and 2: the code and the logins
The repository in an account you own, with a mirror copy kept elsewhere. A written list of every account and secret. The developer's own accounts disabled.
Week 1: everything in the company's name
Domain, DNS, cloud subscription and billing, with two of your own people on every owner role. The deployment steps written down, however rough.
Week 2: backups proven, secrets rotated
A restore to a separate database, opened and checked. Shared secrets rotated one at a time, each followed by a test.
Weeks 2 and 3: read it
A clean build, the commit production is running, every dependency with its support date, and the one-page map.
Week 4: decide
Leave it alone, repair it, or replace it in stages, with the reasoning written down and a price on each step.
A developer leaving is not the emergency. The emergency is finding out during an outage that the domain, the cloud account and the only working deployment left with them.
Sources
Platform facts on this page come from each provider's own documentation.
- Transfer an Azure subscription to a different Microsoft Entra directory
- Transfer billing ownership of an Azure subscription
- Manage emergency access accounts in Microsoft Entra ID
- Add and manage application credentials in Microsoft Entra ID
- Azure DevOps: revoke personal access tokens for organization users
- Azure DevOps: change the organization owner
- GitHub: transferring a repository
- GitHub: removing sensitive data from a repository
- ICANN: registrants' benefits and responsibilities
- AWS account root user
- Automated backups in Azure SQL Database
- dotnet package list
- SQL Server 2016 lifecycle
- Windows Server 2016 lifecycle
- .NET 8 and .NET 9 end of support
- .NET Framework lifecycle FAQ
- Azure Functions: in-process to isolated worker
- Strangler Fig pattern, Azure Architecture Center
- Strangler Fig, Martin Fowler