Taking over a codebase another team built: a safe handover plan

To take over a site or app another team built, secure access and ownership first, then review the code and hosting before changing anything, and only then fix problems in small, reversible steps. The order matters. A new team that starts rewriting in week one usually loses the knowledge hidden in the old code and breaks things the business depends on. A rewrite is justified only in a few specific cases, and the review is how you find out whether yours is one of them.

#Secure access and ownership before anything else

The riskiest moment in a handover is the one where the previous team still holds keys you do not. Before any technical work, list every account the product depends on and confirm that each one is in your company's name, with your own people as owners or admins. The previous developer can keep a user account for a while if the relationship is friendly, but they should not be the only person who can log in.

• Source code: the Git repository (GitHub, GitLab, Bitbucket or a private server), with full history, all branches and tags. A ZIP of the current files is not a handover.
• Domains and DNS: the registrar account and whoever controls the DNS zone. A lost domain is the hardest problem to undo.
• Hosting and cloud: the server or cloud account, the control panel, SSH keys, database access and the place where backups are stored.
• Third-party services: payment providers, email delivery, maps, analytics, error tracking, CDN, SMS and every API key stored in configuration.
• App stores: for mobile apps, the Apple Developer and Google Play Console accounts, plus certificates and signing keys. Check who holds the Android signing key: if Google Play App Signing is not enabled and the key is lost, the existing store listing cannot receive updates.
• Documentation and credentials: any README, deployment notes, environment files and password vault entries.

Once you have access, rotate the passwords and keys the previous team knew. Do it in a planned window, because a rotated API key that is still hard-coded somewhere will break a feature without anyone noticing at first.

#What a code and hosting review should cover

A review answers one question: can this product be maintained and extended at a reasonable cost, and what has to be fixed first? It should end in a written report with findings ranked by risk, so you can make decisions without reading the code yourself.

The code

• Language and framework versions, and whether they still receive security updates.
• Dependencies: how many there are, how outdated they are, and whether any have known vulnerabilities. Tools such as composer audit and npm audit report this.
• Whether the project builds and runs from the repository on a clean machine, following only the written instructions.
• Automated tests: whether there are any, whether they pass, and whether they cover payments, logins and data changes.
• Structure: whether business rules live in one place or are copied across controllers, templates and scripts.
• Secrets committed to the repository. These must be rotated even if they were deleted later, because Git keeps the history.

The hosting and data

• Where the application runs, who maintains the server, and how new versions are deployed. Manual file uploads over FTP are a warning sign.
• Backups: where they are, how often they run, and whether anyone has restored one recently. An untested backup is an assumption.
• Monitoring and logs: whether errors are recorded somewhere you can read them.
• Differences between the repository and what is live. It is common to find fixes made directly on the server that never reached version control.

That last check deserves care. Compare the deployed files with the repository before your first deployment, or your first release may quietly undo someone's hotfix.

#A staged plan that keeps the business running

After the review, work in stages, each small enough to release and roll back on its own.

1. Stabilize. Move the code into a repository you own, set up a repeatable deployment, confirm that backups restore, and add error tracking. Nothing changes for users.
2. Protect the critical paths. Write automated tests around the parts that make or lose money: checkout, login, registration, data exports and integrations. These tests record how the system behaves today, which becomes the baseline for every later change.
3. Patch security and versions. Upgrade the framework and dependencies one step at a time, running the tests after each step.
4. Improve in place. Refactor the areas that slow the team down most, usually the ones the review flagged as tangled or duplicated.
5. Build new features. By now the team knows the code, and new work lands on a tested base.

Give each stage a written scope and a clear end, so you can pause between stages if the budget or priorities change. If you are planning a budget for this work, the article on what drives the cost of a custom web application covers the same factors from the estimate side.

#Mistakes to avoid in the first weeks

• Judging the old team too quickly. Odd code often handles a real edge case, a customer's special contract or a bug in a partner's API. Ask why before you delete it.
• Upgrading everything at once. A jump across several framework versions, plus a new server, plus a redesign, makes it impossible to tell which change broke what.
• Changing the database without a migration path. Schema changes should be scripted, reversible and tested against a copy of production data.
• Leaving integrations unmapped. List every external system the product talks to, including webhooks that arrive from outside. These tend to fail quietly. The article on what a reliable API integration needs lists what to check.
• Letting the knowledge leave a second time. Write down what you learn as you learn it. A handover that produces no documentation makes the next handover just as hard.

#When a rewrite is justified

Rewrites are expensive because the old system keeps running and changing while the new one is built, and every rule the old code handles has to be rediscovered. Some situations still justify one:

• The platform or language is no longer supported and there is no upgrade path, for example a framework version whose successor is effectively a different product.
• The code cannot be built or deployed in a reproducible way, and fixing that would cost close to starting over.
• The purpose of the product has changed so much that most current features will be removed anyway.
• The data model is wrong at its core, and every new feature has to work around it.

Even then, a gradual replacement is usually safer than switching everything on one day. Move one section of the product at a time to the new code, let the old system serve the rest, and retire it piece by piece. Users see steady progress, and you can stop at any point with a working product.

#Questions to ask the previous team

If the previous developers are available, even for a few hours, their time is worth paying for. Useful questions include:

• Which parts of the system break most often, and what do you do when they do?
• Are there scheduled jobs, queues or background workers, and where are they configured?
• What was changed directly on the server and never committed?
• Which features are half-finished or switched off?
• Which external services send data in, and what happens when they are down?

#How PN Scripts can help

PN Scripts takes over existing sites and apps in any stack. The work starts with a code review and a written report, followed by a staged plan in place of a rewrite. The code, the accounts and the documentation stay in your name throughout. You can read more about how we work on the custom web development page.