Taking over a web application: the method, from initial assessment to maintenance

Taking over a web application written by another team does not start with development. A web application takeover happens in three stages: gather the access and the code, check what the company really owns, then have the existing system audited before committing to anything. Here is the method, in order.

End of a contract with an agency, a supplier who can no longer keep up with the workload, an in-house team that is shrinking, the acquisition of a company and its software: there are many reasons to change teams, and the method stays the same. This guide is aimed at managers and product owners who are not developers. It starts with what to gather before the change and ends with what follows a successful takeover: documented, tracked application maintenance.

Before the change of team: gather what lets you carry on

An application is more than its code. For another team to run, fix and deploy it, they need everything around it. Gather the list below while the outgoing team is still under contract and available: afterwards, every missing item costs time.

• The code repository, with its history. Administrator access to the platform that hosts it, or its transfer to an account in the company’s name. The change history explains choices that the code alone does not.
• Hosting. The server or cloud accounts, the administration access, and the list of what runs there: application, database, scheduled tasks, certificates.
• The domain name and DNS. Check who holds the domain and who can change the zone: it is what directs your users to the application.
• The database and backups. Where they are stored, how often, and whether a restore has ever been tried.
• Third-party services. Email sending, payment, file storage, SMS: every account must be in the company’s name.
• Secrets. API keys, environment variables, certificates: these are what is most often missing when restarting elsewhere.
• The deployment procedure and documentation. Even if short, even if imperfect: how the project is installed, how it goes to production, what to monitor.

Also plan a handover: one or two sessions where the outgoing team explains the architecture, the fragile points and the recurring operations. It is the cheapest information you will get about your own application.

Who owns the code?

It is the question people ask too late. Under French law, paying for a development does not automatically make you its owner. Bpifrance Création sums it up this way: when software is developed by an external supplier, the client does not automatically become the rights holder. A contract assigning the rights must be explicitly concluded, failing which the supplier remains the owner of the code delivered.

Source: Bpifrance Création, “Protection juridique d’un logiciel” (legal protection of software), which cites articles L. 112-2 and L. 113-9 of the French Intellectual Property Code among its reference texts.

In practice, reread your contract and your invoices: does the assignment appear there, and what does it cover? If it is missing, now is the time to have it signed, before the collaboration ends. The same source points out that protection covers the source code, the object code and the documentation when it is sufficiently detailed, and that a deposit with the Agence pour la protection des programmes (APP) or the INPI (the French intellectual property office) is evidence, not a title of ownership.

Personal data changes hands too

If the application processes personal data (users, customers, employees), your development supplier or your host generally acts as a processor within the meaning of the GDPR. Article 28 of the GDPR provides that at the end of the service, the processor deletes the personal data or returns it to the controller, at the controller’s choice, and destroys existing copies, unless there is a legal obligation to retain them.

Two practical consequences. Ask the previous supplier in writing to return, then delete, the data and backups it holds. And sign a contract with the team taking over that governs its access to the data, as the same article requires.

The takeover audit: knowing what you are taking over

A team that quotes for maintenance without having read the code takes a risk, and makes you take it. The takeover audit replaces assumptions with an initial assessment, before any commitment.

The first point often weighs heavily: a language or framework that has reached end of support no longer receives security fixes, and bringing it up to date then comes before any new development.

The audit ends with a document you keep, whichever supplier you choose next: the state of the application, the risks ranked by severity and an upgrade plan.

Keep the existing system or rewrite it?

The temptation to redo everything is strong, especially when the team taking over did not write the code. It is rarely the right first answer: an application in service contains years of business rules that no specification describes completely.

• Take it over as it is when the application provides the expected service, its technology stack is still maintained or can be updated, and the code can be read by a team that knows these technologies.
• Upgrade in stages when the foundation is dated but sound: version upgrades, adding tests on the critical journeys, gradually replacing the fragile parts.
• Rewrite, in whole or in part, when the technology has been abandoned, the code can no longer be installed or tested, or the need has changed so much that the existing system no longer serves it.

How a takeover unfolds, step by step

• Secure the access. Transfer accounts to the company’s name, change the passwords and keys shared with the outgoing team, check the backups.
• Audit. The initial assessment described above, with an upgrade plan ranked by priority.
• Get it working again. A reproducible development and test environment, automated deployment, a backup restore that has actually been tried.
• Stabilise and secure. Security updates, the most urgent fixes, monitoring. No new features at this stage.
• Move to ongoing maintenance. Corrective, preventive and evolutive, with tracking of requests that you can consult: this is the regime of application maintenance (TMA).
• Resume new development. Once the application is stable and documented, the product roadmap can restart.

Order matters. Building new features on an application that you can neither test nor redeploy means adding risk to a foundation that nobody yet controls.

Choosing who takes over: the questions to ask

The answers to these questions quickly tell a team used to takeovers from a supplier who will discover your application while billing for it.

• Which applications have you already taken over on this technology stack, and who will work on mine?
• Do you start with an audit, and what does the document you hand over contain?
• Will the code be hosted on a repository that belongs to me, with accounts in my company’s name?
• How will I track requests, time spent and the state of the application?
• If we stop working together, what do you hand over to me, and what handover do you provide?
• How is continuity ensured during holidays and absences?

These questions apply to a supplier close to you as much as to a French-speaking nearshore partner: what matters is that the language, working hours and tracking tools are shared. For a supplier based outside France, the points specific to working at a distance, including how data transfers are governed, are covered in our guide to choosing a nearshore maintenance provider.

Staying in control after the takeover

A successful takeover can be recognised by this: the next change of team, if it happens, will be simple. Four habits are enough.

• Accounts in the company’s name: repository, hosting, domain name, third-party services. The supplier is invited to them; it is not the holder.
• A written assignment of rights in the contract, for the existing code as well as for future developments.
• Documentation kept up to date: installation, deployment, architecture, recurring operations.
• A reversibility clause that describes what is handed over to you at the end of the contract and the assistance owed during the handover.

To draft this clause, public procurement offers a useful model, even for a private contract where nothing requires it. The CCAG-TIC 2021 (the French general administrative terms for public ICT contracts) distinguishes reversibility (the buyer takes the services back itself, or entrusts them to a third party it designates) from transferability (it has them taken over by a new contractor). Its article 38 provides for a reversibility plan, annexed to the contract documents, which sets its duration and conditions, and whose content may include the executable software and, where applicable, the source code with its documentation, configuration files, operating scripts and files in documented formats. Its article 42 governs how it is carried out: access to hardware and software during the handover, and data security during the transfer. The other clauses to review before signing are covered in our article on the application maintenance contract.

Finally, depositing the code with a trusted third party, such as the APP, dates and proves what was delivered. Bpifrance Création points this out: the deposit is evidence, it does not create rights.

Frequently asked questions

Taking over a web application: start with the initial assessment

A change of team goes well provided you act in order: gather the access and the code, check what the company owns, have the existing system audited, then stabilise before evolving. What you put in place on this occasion (accounts in the company’s name, documentation, reversibility) will make the next change simpler.

If you then entrust maintenance to a supplier, our guide to outsourcing application maintenance sets out the selection criteria and the steps. The iones team carries out the audit and application maintenance of existing applications. You can also write to us for an initial discussion.