Start by securing access, not by changing the software.
When a developer or agency leaves, the most urgent risk is losing the ability to operate the application, not the absence of new features. Before anyone edits a line of code, list every place the software depends on: the code repository, hosting account, domain registrar, DNS, email delivery service, payment processor, app store listings, and any third-party APIs. For each one, record who holds administrative access today.
Where a departing developer is the only administrator, ask for a second administrator to be added from the business side while the relationship is still cordial. Most platforms support several administrators with separate logins, which is safer than sharing one password. Change shared credentials after the transition, and rotate API keys and secrets that the former team could have copied into outside tools.
Hold off on new feature work during this period. An application that is running today can keep running while access is resolved, but a rushed change made without the deployment knowledge can take it down. The goal of the first phase is simple: make every critical account reachable by someone inside the business, and change nothing that cannot be undone.
Collect the knowledge that lives only in the departing team’s heads.
Source code alone rarely tells a new team how to run a system. Ask for the steps to set up a development environment, build the application, run the tests, and deploy a release. Ask where configuration and environment variables are stored, which scheduled jobs run and when, and how backups are made and restored. Even rough notes in a shared document are far better than nothing.
Request a written list of known issues, workarounds, and anything the team was partway through. Unfinished branches, pending database migrations, and half-applied upgrades are common after a sudden departure, and they are much easier to understand with a short explanation from the person who started them. A recorded walkthrough of the deployment process can answer questions nobody thinks to ask in writing.
Review the existing agreement with the developer or agency for any handover obligations, notice periods, or terms about delivering code and documentation. Those terms vary widely, so read them before the final conversation and ask an attorney about anything unclear. A cooperative, well-documented handover is worth a short paid extension of the relationship if the contract allows it.
Keep the application stable while a new team gets oriented.
Once access and knowledge are gathered, confirm that someone can deploy the current version from scratch. A test deployment to a separate environment proves that the build steps work, the configuration is complete, and nothing depends on a laptop that just left the company. If that deployment fails, the gaps it reveals are the most important items on the transition list.
Put basic monitoring in place if it is missing. Uptime checks, error reporting, and alerts on failed scheduled jobs tell the business when something breaks, rather than waiting for a customer to call. Confirm that backups exist, that they run on a schedule, and that a restore has actually been tested. A backup that has never been restored is only a hope.
Keep a short log of incidents, user complaints, and odd behavior during this stretch. It becomes useful evidence for the next team, showing which parts of the system are fragile and which simply look messy. Resist pressure to fix everything at once. Small, reversible changes with clear notes build confidence and keep the operation running while the bigger decisions wait.
Have the next team assess the code before committing to a plan.
A new developer or firm should begin with a structured assessment rather than a quote for new features. A useful assessment covers how the code is organized, the state of dependencies and frameworks, test coverage, security practices, hosting setup, and how data is modeled. It should end with a plain written summary of risks and recommendations that a nontechnical leader can follow.
Expect the assessment to separate urgent problems from cosmetic ones. Outdated libraries with known vulnerabilities, missing backups, and exposed secrets belong at the top. Inconsistent naming, unfamiliar patterns, or a framework the new team would not have chosen are real but secondary. A reviewer who recommends a full rewrite before understanding the system is making a guess, not a judgment.
Ask how the new team would take over day-to-day support: how they would handle a production issue, how releases would be tested, and what they would document as they learn. The answers show whether the transition will reduce dependence on individual memory or simply move that dependence to a new set of people.
Set up the next relationship so a departure is routine.
The best time to plan for a developer leaving is at the start of the engagement. Agree in writing where the code will live, who holds administrative access to each account, what documentation will be kept current, and what a handover includes if the work ends. These terms protect both sides and make the relationship easier to manage.
Ask for a living runbook that covers setup, deployment, scheduled jobs, backups, and common support tasks. Test it now and then by asking someone other than the author to follow it. Keep an inventory of accounts, vendors, and renewal dates inside the business, so no single person outside the company is the only record of how the system fits together.
When evaluating a replacement, favor teams that document as they work and that describe a handover process without being asked. Baybloom Software takes over existing applications through an assessment and a documented handover, and the same questions apply to any firm under consideration. A departure handled this way becomes an ordinary change of staff rather than an emergency.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project