Establish the live position before planning change

Taking over a legacy web application means assuming operational control of a system that was built and previously run by someone else. That distinction matters because the work extends well beyond receiving files. A running application depends on servers, databases, domains, scheduled tasks, third-party services and institutional knowledge that may never have been written down.

Handovers fall into two broad categories. A planned transfer happens when a supplier contract is ending, a product has been acquired, or a business has decided to bring development in-house. An unplanned takeover occurs when a supplier becomes unresponsive, enters insolvency, or the relationship breaks down abruptly. The steps are broadly similar, but the unplanned scenario introduces urgency, incomplete information and higher risk.

The core components that must move across are the source code, the infrastructure it runs on, the domain and DNS configuration, any continuous-integration or deployment pipelines, credentials and API keys for connected services, and whatever documentation exists. Missing any one of these can leave the application partially or fully inoperable, even if the code itself is intact.

It is worth understanding at the outset that a takeover is not the same as a modernisation or rebuild. The immediate goal is safe custody: keeping the system running and accessible while you assess its condition. Decisions about improving, replacing or retiring the application come afterwards and depend on what the takeover reveals.

Typical scenarios that lead to a takeover

Supplier insolvency or closure is one of the most common triggers. If the development company stops trading, access to hosting accounts, domain registrars and source-code repositories can disappear overnight unless arrangements were made in advance. A contract dispute is another frequent cause, where the working relationship has deteriorated to the point that continued collaboration is not viable. In mergers and acquisitions, the buyer inherits software as part of the deal and needs to bring it under its own technology governance. Finally, a business may simply decide that an externally maintained system is strategically important enough to own and operate directly.

Establishing priority of access

Not all components carry equal urgency. Domain registration and DNS control should be secured first because losing those means losing the address users rely on, and recovery through registrars or Nominet can be slow and uncertain. Hosting and server access comes next, followed by database credentials. Without the database, the application may start but serve no useful data. Source-code repositories, deployment pipelines and third-party API keys can usually follow once the system is confirmed to be running under your control.

Third-party services and integrations

Legacy applications commonly depend on external services: payment gateways, email delivery providers, mapping APIs, cloud storage, identity providers or industry-specific data feeds. Each of these represents a separate account with its own credentials, billing arrangement and terms of service. During a takeover you need to identify every external dependency, establish who currently controls each account, and determine whether the account can be transferred, whether you need to create a new one and reconfigure the application, or whether the service itself is approaching end of life.

Deployment and operational processes

How does the application get from committed code to a running service? In well-maintained systems there will be a continuous-integration or continuous-deployment pipeline that automates testing and release. In older or less formally managed applications, deployment might involve manual file transfers, database migration scripts run by hand, or configuration changes applied directly on the server. Understanding this process matters because at some point you will need to make a change, however small, and you need to know how to do it without breaking the live system.

Scheduled tasks and background processes

Many business applications include cron jobs, queued workers or scheduled tasks that handle overnight processing, report generation, data synchronisation or cleanup. These are easy to overlook because they do not have a visible user interface, but if they stop running the application will silently degrade. Part of the takeover is identifying every scheduled process, where it is configured, what it does and what happens if it fails.

Knowledge transfer

Documentation is valuable but rarely sufficient on its own. The most important knowledge often lives in the heads of the people who built and maintained the system. Where possible, arrange structured handover sessions that walk through the architecture, known issues, recent changes and the reasoning behind non-obvious decisions. Record these sessions. If the previous team is not available, you will need to reconstruct this understanding from the code, infrastructure configuration and whatever written records exist.

Before technical work begins, confirm what the existing contract says about ownership, licence grants, data return obligations and post-termination access. If there is no contract, or if it is silent on these points, seek current legal advice. The technical takeover can proceed in parallel, but you need to understand whether you have a clear right to the source code, the data and the infrastructure, or whether you are relying on cooperation that could be withdrawn.

Assuming the code is the system

The most frequent mistake is treating the source-code repository as the entire deliverable. A repository contains the application logic, but without the correct server environment, database schema, configuration files, environment variables and connected services, the code will not run. Always verify that what you have received actually starts and functions, rather than assuming completeness from a file count or a repository clone.

Ignoring licence obligations in dependencies

Legacy applications often include third-party libraries, frameworks or packages, each subject to its own licence. Some licences permit commercial use and modification without restriction. Others impose conditions such as attribution, copyleft requirements or restrictions on redistribution. Reviewing the dependency list for licence compliance is a task that requires current specialist attention, particularly if you intend to modify the software or make it available to other parties.

Overlooking security posture

An inherited system may have unpatched vulnerabilities, outdated dependencies, weak authentication configurations or exposed administrative interfaces. Taking it over does not make it secure. Before exposing it to your wider network or customer base, commission a security review appropriate to the sensitivity of the data it handles. Treat any security assessment as a point-in-time snapshot, not a permanent guarantee.

Not having a rollback position

Before making any changes during the takeover, ensure you can return to the exact state the system was in when you received it. That means taking full infrastructure snapshots, database backups and copies of all configuration. If your first attempt to reconfigure deployment or update a dependency causes a failure, you need a clean path back to a working state.

Underestimating the knowledge gap

Even with thorough documentation, there will be implicit decisions that are not recorded anywhere. A particular database index might exist because of a performance issue discovered two years ago. A configuration value might be set to an unexpected number because of a bug in a third-party API that has since been fixed but never revisited. Expect to spend time investigating anomalies, and budget for that investigation rather than assuming the system can be taken over and understood in a fixed, short window.

Key checks to carry out early

  • Confirm you can log into the hosting environment, the database and the domain registrar.
  • Verify the application starts and serves its primary functions in a controlled environment before making any changes to the live system.
  • List every external service the application calls and confirm you can access or recreate each account.
  • Identify all scheduled tasks and confirm they are running and producing their expected outputs.
  • Review the deployment process end to end, from code commit to live release.
  • Check that SSL certificates are valid and that you control the renewal process.
  • Confirm backup arrangements: where backups are stored, how often they run, and whether you can restore from them independently.
  • Establish who currently has access to each component and revoke credentials that are no longer needed.

Limitations of a takeover

A takeover gives you control, but it does not give you a modern, well-architected or easily maintainable system. The application may be built on a framework or language version that is no longer supported. It may have accumulated technical debt that makes even small changes risky and time-consuming. The infrastructure may be undersized, misconfigured or tied to a single provider in a way that limits your options. Understanding these limitations early allows you to plan realistically for the period between taking over and deciding whether to modernise, rebuild or replace the system.

Keep the decision traceable

Once the application is running under your control and you have a baseline understanding of its condition, the next practical step is ensuring you have complete and unrestricted access to the source code itself. That subject is covered in the next article in this series.