Taking Over a Web Application From Another Agency: A Handover Checklist

Key Takeaways

• Before you announce the change, secure what you need to own: the code repositories, hosting and cloud accounts, domain names, third-party services and the data.
• A handover covers five things: access, code, infrastructure, data and knowledge. Missing any one of them turns a takeover into reverse engineering.
• Your leverage is the contract: a written assignment of IP rights and a reversibility clause. If you have neither, negotiate them before the relationship ends, not after.
• The new team should start with a read-only assessment: rebuild the application from the repository, test a backup restore and rotate every secret before changing any feature.
• Decide whether to rescue or rewrite only once you know what is really in the code and in production.

Taking over a web application means moving responsibility for a running system from one supplier (an agency, a freelancer or a departing internal team) to another, without losing the code, the data or the knowledge of how it works. It usually happens at a bad moment: the previous supplier has stopped answering, deadlines are slipping or the relationship has broken down. The steps below are the ones we follow when a client brings us an application built by someone else. This is a practical guide, not legal advice; have a lawyer look at your contract if the previous supplier is disputing anything.

Secure what you need to own, first

Do this before you tell the current supplier you are leaving. Most of it should already be in your name; the point is to check, not to assume.

Anything still registered to the supplier is the first thing to move. Repositories can be transferred between accounts without losing their history, issues or pull requests. For a domain held by the supplier, the transfer needs an authorization code, which ICANN's rules require the registrar to provide on request.

The handover checklist

A complete handover covers five areas. Ask for them in writing, as a list the outgoing supplier can tick off.

1. Access

• Administrator access to every account in the table above, in your name.
• A list of every person and service that currently has access, so it can be revoked.
• The secrets the application uses (API keys, database passwords, signing keys), delivered through a password manager, never by email. They will be rotated anyway.

2. Code

• All repositories, including side services, scripts, infrastructure code and anything that was never merged.
• Confirmation of which commit or tag is running in production today.
• Build and deployment instructions that someone outside the team can follow.

3. Infrastructure

• A description of the environments (production, staging, development) and where each runs.
• How deployments happen: a pipeline, a script, or someone's laptop.
• Scheduled jobs, queues, workers and anything else that runs outside the main application.
• Monitoring and alerting: what exists, and who receives the alerts today.

4. Data

• Database schema and migrations, and where the production data lives.
• The backup policy, and the date of the last successful restore test.
• Any personal data processed, with the related data processing agreements, since the new supplier will become a processor under the GDPR (Article 28).

5. Knowledge

• Known bugs, workarounds and "don't touch this" areas.
• Decisions that explain the strange parts: why a service exists, why a library was pinned.
• One or two working sessions between the outgoing developers and the new team. An hour of explanation saves days of reading code.

When the previous supplier is slow or uncooperative

Most handovers go smoothly. When they don't, your position depends on what you signed.

• IP rights. Code written by an agency or freelancer belongs to its author unless the rights were assigned to you in writing. Our guide on who owns the code explains what that assignment must contain under French law. If there is no assignment, get one signed before the relationship ends.
• Reversibility. A reversibility clause obliges the outgoing supplier to hand back the data, documentation and assistance needed to transfer the service. French public IT contracts set out this obligation in the CCAG-TIC, article 42; it is a useful model for private contracts too.
• Access you already hold. If the repositories and hosting are in your accounts, a supplier who stops answering cannot block you. If they are not, prioritize the accounts that keep the application running: hosting, domain and DNS.
• Escrow. For software you license rather than own, a deposit with a trusted third party such as the Agence pour la Protection des Programmes gives access to the source code if the supplier disappears.

Keep requests in writing, with dates. If the situation turns into a dispute, that record matters more than any phone call.

The first two weeks with the new team

A new team should not change features until it can run the system safely. The first steps are the same whatever the stack.

1. Rebuild from the repository. If the application can't be built and deployed from the code you were given, something is missing, and it is better to find out now.
2. Test a backup restore. A backup that has never been restored is a hope, not a backup.
3. Rotate every secret. Former suppliers and their staff should no longer hold working credentials. Move configuration into environment variables if it is in the code (The Twelve-Factor App describes why).
4. Inventory dependencies. Outdated frameworks and libraries with known vulnerabilities are one of the most common risks in inherited applications (OWASP A06).
5. Set up monitoring and alerts that reach the new team, so the first incident is not discovered by your customers.
6. Write down what you find, with risks ranked, before proposing a plan.

This is the same ground a technical audit covers, and it is how our software rescue engagements start.

Rescue or rewrite?

Only decide once the assessment is done. Inherited code often looks worse than it is, and a full rewrite throws away years of fixes for edge cases nobody documented. Most struggling applications are better recovered step by step. Our guide on whether to rescue or rewrite covers the warning signs and the decision in detail.

Red flags during a handover

• The supplier offers a ZIP file instead of access to the repository and its history.
• The code you receive does not match what runs in production, or nobody can say which version is deployed.
• Hosting, domains or payment accounts are in the agency's name and they ask for a fee to transfer them.
• Credentials are sent by email or chat, or the supplier refuses to let you rotate them.
• No documentation of scheduled jobs, servers or external services, only "it's all in the code".

Frequently asked questions

Can the old agency refuse to give us the code? If the rights were assigned to you and you paid what the contract required, refusing access is a breach you can enforce. Without a written assignment, the code belongs to its author under French law, which is why the assignment matters so much. In either case, get a lawyer involved early if the supplier refuses.

How long does a handover take? With a cooperative supplier and accounts already in your name, the transfer itself takes days. The new team then needs time to understand the system before changing it; how long depends on its size and on how much was documented.

Should the old and new teams overlap? Yes, if the relationship allows it. A short overlap, even a few working sessions, is the cheapest way to transfer knowledge that was never written down.

Is it safe to keep the old supplier's hosting for a while? It can be, as a temporary measure, if you have administrator access and the credentials have been rotated. Plan the migration to your own accounts rather than leaving it open-ended.

---

At FNB Solutions, repositories and hosting stay in the client's accounts from day one, the client owns the code and IP, and every engagement ends with maintenance or a structured handover. Our full contract terms are public. If you need to take over an application, tell us about it.

Sources

• Transferring a repository, GitHub Docs
• Authorization code, ICANN glossary
• CCAG-TIC 2021, article 42: reversibility and transferability (in French)
• GDPR Article 28: processor
• Agence pour la Protection des Programmes, source code deposit and escrow
• The Twelve-Factor App: config
• OWASP Top 10, A06: vulnerable and outdated components