Taking over a codebase from another developer: the first-week audit

What should you check when taking over a codebase from another developer?

In the first week, secure ownership of every account, get the application running on a safe copy, then audit dependencies, secrets, backups, tests, deployment and documentation, and turn the findings into a prioritised written plan before any new feature work starts. Handovers often happen under pressure: a freelancer moves on, an agency relationship ends, or the original developer is suddenly unavailable. A calm, structured first week protects the business and gives the new team a fair starting point.

This is the checklist our custom software team uses when we take over an existing application.

Step 1: Who owns the accounts?

Before touching any code, list every account the application depends on and confirm your business owns it:

• Code repository, ideally in your own organisation on GitHub, GitLab or Bitbucket. GitHub documents how to transfer a repository from a personal account to an organisation.
• Hosting, servers, databases and storage.
• Domain registrar and DNS.
• Email sending, payment, SMS, maps and analytics services.
• App store developer accounts for mobile apps.

Then reset passwords and rotate API keys the previous developer knew, enable two-factor authentication on every account, and remove access you no longer need. Do this in a planned way, so nothing breaks because a key changed without the application being updated.

Step 2: Can you run it safely?

Get the application running on a developer machine and on a staging copy that mirrors production. This tests the setup instructions, if any exist, and reveals hidden requirements such as specific language versions, environment variables or services nobody mentioned. Use a copy of production data with personal details masked where possible. Never make the first changes directly on the live site.

Step 3: How healthy are the dependencies?

List the language and framework versions, plus every package the application uses. Check which ones are out of support, which have known security advisories, and which are abandoned. Unsupported framework versions are a common finding; our guide to upgrading an old Laravel app shows how to plan that work once you have the list.

Step 4: Where are the secrets?

Look for passwords, API keys and tokens committed into the code repository, including its history, and in configuration files on the server. Move them to environment variables or a secrets manager, and rotate any that were exposed. This is one of the most valuable checks in any takeover, because leaked keys can be abused long after a developer leaves.

Step 5: Do backups exist, and do they restore?

Confirm what is backed up (database, uploaded files, configuration), how often, where the copies are stored and for how long. Then test a restore to staging. A backup that has never been restored is only a hope. If there are no reliable backups, setting them up comes before anything else.

Step 6: What tests and checks exist?

Note whether automated tests exist and whether they pass. If there are few or none, list the business-critical flows, such as sign-in, checkout, bookings or invoicing, and plan tests for those first. Also check error logging: if nobody sees errors, problems reach customers before the team. Our guide on what to monitor on a production web app lists the minimum set.

Step 7: How does code reach production?

Our cloud and DevOps team usually sets up a simple automated deployment early, because it makes every later change safer.

Step 8: What knowledge is missing?

Read through the main parts of the code to understand its structure, and list the business rules that seem to be encoded in it. Look for scheduled jobs, background queues and integrations that run quietly in the background. If the previous developer is available, a few recorded walkthrough calls are worth a great deal. Write everything down in a short README as you go.

Which problems turn up most often?

• Accounts in the wrong name: hosting, domains or app store listings registered to the previous developer.
• Secrets in the repository: database passwords or API keys committed to the code history.
• No working backups, or backups stored on the same server as the application.
• Outdated framework and language versions that no longer receive security fixes.
• Undocumented manual steps, such as a monthly script someone ran by hand.
• Changes made directly on the live server that never reached the repository.

None of these mean the previous work was bad overall. They are simply the gaps that appear when one person carries knowledge in their head.

How should the business stay involved?

Name one person on your side who can approve access changes, answer questions about how the business uses the software and sign off priorities. Ask for a short update at the end of the first week, in plain language, with the risks ranked. Business owners often know about hidden features and important customers that never appear in the code.

What should the audit report contain?

1. Ownership status of every account, and what was changed.
2. Versions, dependencies and support dates.
3. Security findings, ranked by urgency.
4. Backup and restore status.
5. Test coverage of critical flows.
6. Deployment process and recommended improvements.
7. A prioritised plan with estimates: urgent fixes first, then stability, then features.

What happens after the first week?

Work through the urgent items, then set up a steady rhythm: regular updates, monitored errors, tested backups and reviewed changes. Ongoing maintenance and security care keeps the application from drifting back into the state you found it in, and it gives you a clear record of what changed and why.

Frequently asked questions

Last updated November 2, 2026