Taking over an application built by another developer

1. Recover access before anything else

This is the most neglected step, and the one that blocks the most takeovers. Before talking about code, list everything that keeps the application running and check who holds it:

• the source code repository with its full history (Git), not just an archive of the latest version;
• hosting: servers, cloud account, control panel;
• the domain name and its DNS zone;
• the database and its backups;
• the Apple Developer and Google Play accounts, if there is a mobile app;
• third-party services: payments, email and text delivery, maps, file storage;
• the API keys, passwords and certificates the application uses;
• monitoring, logging and deployment tools.

Ideally, every account is in your company's name and your former vendor only has guest access. If that is not the case, get the accounts transferred first, while the relationship still allows it.

2. Check that the application can be rebuilt and deployed

Having the code is not enough: another team has to be able to install it, run it and put it in production without help from its author. Ask for:

• the steps to set up a development environment;
• the list of environment variables and settings (secret values go through a secure channel, never by email);
• the deployment procedure, manual or automated;
• the procedure to restore a backup, tested at least once.

The best test is simple: can a new developer complete a full deployment using only the documentation? If so, the biggest risk is out of the way.

3. Have the application audited

The audit gives you an accurate picture of what you are taking over, before you commit to new work. It covers:

• Dependencies: versions of languages, frameworks and libraries, components that have reached end of life.
• Security: secrets left in the code, overly broad access rights, known vulnerabilities, protection of personal information.
• Code and tests: structure, readability, whether automated tests exist and what they actually check.
• Data: model, consistency, volumes. Data often outlives the software, and it is usually what holds the most value.
• Operations: backups, monitoring, logs, incident recovery plan.

An application without documentation can still be taken over. Understanding is rebuilt from the code, the database, the logs and the way your teams use it. One of the first deliverables should then be minimal documentation.

At GentBit, the audit ends with a list of risks ranked by severity, a takeover plan and an estimate of the work.

4. Keep, stabilize or rebuild

The urge to rewrite everything is strong, especially when the code is hard to read. It is rarely the best call: a full rewrite is expensive, slow, and often brings back problems the old version had already solved.

• Keep and improve when the foundation is sound: fix, update, add tests where they matter.
• Stabilize, then rebuild piece by piece when some parts are fragile: isolate the risky areas and replace them one at a time, without interrupting service.
• Rebuild when the technology is no longer maintained, security cannot be guaranteed, or fixing costs more than a new version.

Either way, plan a stabilization period before adding new features: update components, fix known bugs, set up monitoring.

5. Handover day

• Change every password and rotate the API keys your former vendor had access to.
• Remove their access from every account, on a set and recorded date.
• Run a first supervised deployment to confirm the new team controls the whole chain.
• If possible, agree with the former vendor on a short, paid period during which they answer questions.

How long it takes, what it costs

For a mid-sized application with the code available, the audit and stabilization usually take a few weeks. The cost depends mostly on the size of the application and on the state of its documentation and access. For a first order of magnitude, pick "Takeover of an existing app" in our budget estimator.

To avoid going through this again, one rule is enough: the code, the hosting and the accounts stay in your name from day one, whoever the vendor is. It is the rule we follow on our own engagements, and our software maintenance service takes on applications we did not build.