How to Take Over a Legacy Web Application
Taking over a legacy web application means assuming operational control of a system that was built and previously maintained by someone else. The process sits between the initial audit and any future modernisation work: your immediate goal is to establish stable ownership, not to redesign the system. If the application stops working during the handover, the business loses capability regardless of any improvement plans drawn up afterwards.
A structured takeover proceeds through a fixed sequence: secure access to every layer the application depends on, document what you find, confirm you can deploy changes safely, and verify that the outgoing team has transferred enough knowledge for your team to operate independently. Skipping any of these stages creates hidden risk. A system that appears stable on day one can fail the first time someone needs to rotate a certificate, add a server, or fix a data fault.
The practical starting point is a written list of every component the application requires to run: source code repositories, hosting infrastructure, databases, domain names, DNS records, third-party service accounts, scheduled tasks, and any background processes. Without that list, you cannot confirm you have received everything, and you cannot later prove what was missing.
Source Code Access and Repository Recovery
Source code is the foundation of the takeover. If you cannot build the running application from the code you have been given, you do not have control of the system, regardless of what is currently deployed on the servers.
Begin by confirming you have write access to the canonical repository — the single location the previous team treated as the source of truth. Check that the most recent commit in that repository matches what is running in the live environment. Discrepancies between the repository and production are common in legacy systems, particularly where urgent fixes were applied directly to servers without being committed back.
If the original repository is unavailable — for example, a private account belonging to a former developer — you may need to reconstruct a repository from server files. This is significantly more work and introduces uncertainty, because you cannot be certain which files are active, which are backups, and which are obsolete versions. Where reconstruction is necessary, compare files across all available servers and any local copies to establish the most likely working set, then attempt a build before considering the recovery complete.
Check the repository for committed secrets: API keys, database credentials, and encryption keys stored in plain text. Their presence does not prevent a takeover, but it does mean those credentials should be treated as compromised and rotated promptly, which in turn requires identifying every service that uses them.
Verifying a Complete Build
The definitive test of source-code recovery is a clean build on a machine that has never touched the project before. If a new developer can clone the repository, install dependencies, and produce a working build using only the documented instructions, the code is under your control. If the build fails without undocumented steps, tacit knowledge still resides with the outgoing team and has not been transferred.
Server and Infrastructure Discovery
Legacy applications often run on infrastructure that was provisioned ad hoc over years. The hosting environment may include multiple servers, load balancers, file-storage volumes, caching layers, and scheduled-task runners that are not documented anywhere in the codebase.
Request a complete inventory from the outgoing team, then verify it against what you can observe. Log into the hosting provider’s control panel and list every resource associated with the account. Cross-reference server IP addresses against DNS records and application configuration files. Look for servers that are powered on but not referenced in any known configuration — they may be running forgotten services or holding data that the application depends on.
For each server, record the operating system version, the software installed, how access is controlled, and whether automatic security updates are applied. Servers running unsupported operating-system versions are a known risk, but replacing them forms part of modernisation planning rather than the immediate takeover.
Confirm you have administrative access to every layer: the hosting account itself, individual server logins, and any firewall or network-control panels. Read-only access is insufficient; you need the ability to make changes in an emergency, even if your normal practice is to deploy through automated pipelines.
Database Schema Documentation for Legacy Systems
The database is often the most valuable and least understood component of a legacy system. Application code can be read and tested, but a database schema that has evolved over years without migration scripts may contain implicit business rules that are invisible until something breaks.
Start by generating a schema dump from the live database and comparing it against any migration files in the repository. If the live schema includes tables, columns, or indexes that do not appear in the migration history, the schema has been modified outside the normal deployment process. Each undocumented change needs to be understood and recorded before you can safely make further changes.
Identify tables that appear to be unused — no recent writes, no references in the application code — but do not delete them during the takeover. Unused tables may be referenced by reporting queries, external integrations, or end-of-period processes that run infrequently. Flag them for investigation during the modernisation phase instead.
Check for stored procedures, triggers, and scheduled database jobs. These execute outside the application code and are frequently overlooked during handovers. A trigger that modifies records on insert, for example, can cause behaviour that appears to be an application bug if the new team is unaware of its existence.
Confirm you have a recent, verified backup and that you can restore it to a separate environment. The ability to restore is separate from the existence of a backup file; a backup that cannot be restored provides no protection.
Domain and DNS Control for Legacy Applications
Domain names and DNS records are easy to overlook because they rarely change, but losing control of them can take an application offline entirely. The takeover must confirm that your organisation, not the previous vendor or an individual developer, controls the domain registration and the DNS management account.
Check the WHOIS record for each domain used by the application. If the registrant contact is an individual email address at the previous supplier, request a transfer to an address your organisation controls. Domain registrars have specific transfer processes and sometimes lock periods; initiate these early rather than waiting until a renewal is imminent.
Review every DNS record: A and AAAA records pointing to servers, CNAME records for subdomains, MX records for any email services, TXT records for domain verification, and SRV records if the application uses specialised services. Document what each record does and which system depends on it. A subdomain used only by an integration with a third-party service, for example, might be forgotten when the main application is moved.
Check SSL/TLS certificate management. Determine where each certificate was issued, when it expires, and how it is renewed — manual renewal, automated renewal through the hosting provider, or a script running on a server. A certificate expiry is one of the most common causes of sudden outages in handed-over systems.
CI/CD Pipeline Recovery
Continuous integration and continuous deployment pipelines automate the path from code commit to running application. In a legacy system, the pipeline may be fragile, partially manual, or entirely absent. Understanding and reproducing this path is essential because you will need to deploy fixes and changes from the first day of ownership.
If a pipeline exists, document every step: which service runs it, what triggers it, what environments it deploys to, and what credentials it uses. Verify that your team has access to the pipeline configuration and can trigger a deployment without assistance from the outgoing team.
If no pipeline exists and deployments are manual, document the exact steps the previous team followed. Manual deployments are error-prone, but replacing the process with an automated pipeline is a modernisation task. During the takeover, the priority is accurate documentation of the current method so that your team can replicate it reliably.
Pay particular attention to environment-specific configuration. Legacy systems often have differences between development, staging, and production environments that are maintained through manual file edits rather than environment variables or configuration services. These undocumented differences are a frequent source of deployment failures when a new team takes over.
Third-Party Service and API Key Discovery
Most web applications depend on external services: payment processors, email delivery providers, cloud storage, mapping services, analytics platforms, and authentication providers. Each of these represents an account that holds credentials, billing relationships, and configuration that the application requires.
Compile a list of every third-party service by scanning the application code for API endpoints, SDK initialisations, and configuration references. Cross-reference this list against the services the outgoing team identifies. Gaps between the two lists usually indicate services that were added by developers who have since left and were not recorded centrally.
For each service, confirm that your organisation has administrative access to the account, not just the API key. An API key lets the application continue working, but administrative access is needed to rotate keys, update billing details, view usage logs, and add or remove team members. If the account is held under the previous vendor’s email address, request a transfer or create a new account and migrate the configuration.
Review the billing status of each service. An unpaid invoice can result in suspended service with little warning, and if the billing email goes to an address no one in your organisation monitors, the first indication of a problem may be the application failing.
How to Onboard a New Team to a Legacy Codebase
Onboarding a development team to a legacy codebase requires a different approach from onboarding to a greenfield project. The goal is not to understand every line of code but to establish a reliable mental model of how the system behaves and where the risk areas lie.
Start with the architecture at the highest level: what the application does, who uses it, what the main data flows are, and how it interacts with external systems. This context allows developers to make sensible decisions even when they encounter code they do not fully understand.
Identify the areas of the codebase that change most frequently and those that are essentially frozen. A module that handles a specific regulatory calculation, for example, may be well-tested and stable, while the reporting module may be modified regularly and poorly understood. Concentrating initial familiarisation on the volatile areas reduces the chance of introducing faults during the first changes.
Set up a shared development environment that matches production as closely as practical. Developers learning a legacy system need to be able to run it, observe its behaviour, and test changes without affecting live data. If the application is difficult to set up locally — a common problem with legacy systems — invest time in improving the setup process early; the cost is repaid quickly in reduced friction for every developer who joins.
Establish clear rules for making changes: what testing is required, how changes are reviewed, and what the deployment process is. Legacy codebases often lack the guard rails that newer projects have, so the team needs explicit expectations rather than assumed standards.
Knowledge Transfer from Outgoing Developers
Knowledge transfer is the process of moving undocumented understanding from the people who built and ran the system to the people who will run it next. It is the most difficult part of a legacy takeover because much of what the outgoing team knows has never been written down and may not even be consciously recognised as knowledge.
Structured sessions work better than open-ended handover meetings. Prepare specific questions in advance: walk through a recent production incident and explain the diagnosis process; show how a typical change is made from request to deployment; describe any workarounds that are in place and why they have not been fixed properly. These scenarios surface the tacit knowledge that generic questions miss.
Record the sessions where appropriate and store the recordings alongside the project documentation. The value of knowledge transfer is not limited to the people who attend the sessions; future team members will face the same gaps in documentation.
Turn the assessment into a controlled next step
Be realistic about what knowledge transfer can achieve. Outgoing developers may have incomplete understanding of parts of the system they did not build, particularly if the system has had multiple teams over its lifetime. Treat their input as valuable but not authoritative, and verify claims against the code and the running system. Where the outgoing team is unavailable — which is common in disputed vendor exits — the onboarding process must rely entirely on what can be observed and tested, which makes thorough infrastructure and code discovery correspondingly more important.