Taking over a project from another software house — handover checklist

A project handover doesn't end with the code

You're switching vendors. The contract has been terminated, the handover date is set, access to the repository has been promised. Everything looks sorted — until the new team tries to ship its first fix and discovers it can't be signed, because the certificate sits on an account nobody has the password to.

This isn't a hypothetical scenario. In practice, code is the easiest part of a handover. What blocks you are the things around the technology: accounts, keys, copyright, domains, access to services nobody remembered until they stopped working. Each of them looks like a trifle on its own. Together they can halt releases for weeks — and in extreme cases force you to rewrite the app from scratch.

Below is the checklist we work through on every project we take over. It's worth completing before you sign the acceptance protocol, because once it's signed, the other side's motivation to help drops sharply.

1. Rights to the code — check this before anything else

The most expensive mistake in this category is assuming that because you paid for the software, it's yours. Under Polish copyright law it doesn't work that way: paying for a service does not automatically transfer the economic rights to the work. A transfer requires a written agreement that specifies the fields of exploitation (the specific ways in which the work may be used).

What to check:

• Whether the contract transfers the economic rights or merely grants a licence. A licence may be limited in time or territory and may not include the right to modify — which is exactly what you need.
• Whether it covers derivative rights, i.e. the right to create and use adaptations of the work. Without them, you formally cannot legally develop the code further.
• Whether the vendor actually held the rights it's transferring. If some of the work was done by subcontractors or B2B contractors, an equivalent agreement was needed between them and the vendor. This is the most common gap in the chain.
• Open-source licences in your dependencies. A copyleft-licensed library in a closed-source product can turn into a legal problem you discover at the worst possible moment — during due diligence. Ask for a list of dependencies along with their licences.
• Rights to materials a developer didn't write — graphics, icons, fonts, photos. The licence for a font used in a mobile app is sometimes issued to the vendor, not to you.

This is the only item on the list that can't be fixed technically after the fact. Everything else is a matter of time and patience.

2. Code and history

• The full repository with its Git history, not a ZIP archive of the latest version. The history is a record of reasons: why a given condition is there, what a given commit fixed. Without it, every odd line is a puzzle.
• All branches and release tags, including those matching the versions in the stores.
• Side repositories — the admin panel, shared libraries, migration scripts, infrastructure configuration. They very often live separately and fall out of the handover.
• Verification that the project builds on a clean machine. This is the only reliable test of completeness. If the build needs a file that isn't in the repository, you've just found the missing piece.
• Documentation, if it exists — and if it doesn't, at least instructions for setting up the environment.

Red flag: "we'll send you a package with the code". A package without history means either someone has something to hide, or the repository was run in a way they'd rather not show.

3. Accounts and access — the most common source of blockers

This is a list worth going through item by item, checking not "do we have access" but "are we the owner". Access can be revoked; ownership can't.

App stores:

• Apple Developer account — the key question is who the Account Holder is. Only that role can transfer ownership and manage the critical settings. The account should be registered to your company, not the vendor.
• Google Play Console account — likewise, the account owner and admin permissions.
• Signing certificates and keys. On Android, losing the signing key used to mean you could no longer release updates to an existing app; today Play App Signing saves the day, but only if it was enabled. On iOS, certificates can be recreated as long as you have access to the account.
• The APNs key or Firebase configuration for push notifications, test accounts, and the credentials used for store review.

Infrastructure:

• The cloud account, together with the billing owner. A project on the vendor's account is a ticking time bomb — one unpaid invoice after the engagement ends is all it takes.
• Domains: the registrar, the owner account, DNS access. Check the expiry date too.
• TLS certificates and how they're renewed.
• Databases, file storage, queues, caches.

Tools:

• The code repository and the organisation it lives in.
• CI/CD, including environment variables and secrets.
• Monitoring and error tracking, analytics, product tools.
• Third-party services: payment gateway, email and SMS delivery, maps, integrations with the client's systems.
• Email accounts and aliases linked to all of the above — because that's exactly where password resets will go.

A practical tip: turn this into a spreadsheet with the columns "service / account owner / who has access / which email / transfer status". Without a spreadsheet, something is guaranteed to slip through.

4. Secrets — assume they've leaked

Along with the project, you inherit every key the previous team knew. Even with the best intentions on both sides, the only correct response is to rotate everything: API keys, database passwords, integration tokens, and signing keys wherever possible.

While you're at it, scan the repository history for secrets committed to the code. Something many teams discover too late: removing a secret in a later commit doesn't remove it — it stays in the history and is available to anyone with access to the repository. This problem has grown noticeably in projects built with the help of AI assistants, as we wrote in our article on AI-written code in production.

Plan the rotation as a single coordinated operation rather than spreading it over weeks — otherwise half of it will be forgotten.

5. Data, backups and compliance

• Where the production data physically lives and who has access to it.
• Whether a backup has ever been restored. Having a backup is not the same as being able to restore it; there's only one way to check — by trying.
• Data processing agreements (DPAs) for personal data. After a change of vendor you need a new agreement with the new party and the old one terminated, including deletion of the data on the previous team's side.
• The register of sub-processors — cloud, analytics and email delivery providers. A change of vendor is often the occasion for this register to be created in the first place.

6. Knowledge — the shortest window in the whole process

The people who built the system will stop picking up the phone sooner than you expect. Plan for this while they're still cooperating:

• Recorded handover sessions. Two to four calls of 60–90 minutes each: architecture and decisions, the release procedure, incident handling and known pitfalls. The recording matters more than notes, because things get said that nobody writes down.
• A live walkthrough of critical paths — how payment, registration and synchronisation work. Traced through the code together with the author, not from the documentation.
• A list of known issues. It's worth asking directly: "what would you leave untouched, and why?". The answer to that question is often the most valuable part of the entire handover.
• A post-handover support window — two to four weeks during which you can ask questions, written into the contract. Without a contractual clause, it's goodwill that ends on the day of the last invoice.
• Do your first release while the support window is still open. Even a minor fix. It's the only way to check whether the whole chain — build, signing, release — actually works on your side.

The first month after the takeover

Once the access is yours, it's worth getting a clear picture of the situation before you start planning further development:

1. Build and release — confirmation that the release pipeline works without the previous team.
2. Take stock — framework versions, vulnerabilities in dependencies, test coverage of critical paths, the state of monitoring.
3. Run an initial audit. Not to grade your predecessors, but to establish priorities and a baseline. We describe exactly what we check at this stage in our article on source code audits.
4. Settle the question of direction — evolve gradually or rebuild. We've gathered the criteria for that decision in refactor or rewrite from scratch, and what's worth keeping from the inherited state is covered in our article on technical debt.

Red flags during the handover

Signals that should make you slow down and close out the formalities before signing off:

• Code handed over without history, or with history "squashed" into a single commit.
• Store accounts registered to the vendor, with a refusal to transfer ownership.
• No way to build the project without help from the previous team.
• Production running on the vendor's cloud account.
• Documentation written only during the handover — which usually means it doesn't reflect reality.
• A refusal to record the handover sessions.

None of these necessarily means bad faith. More often it means a project run without any thought that it might one day change hands. But each of them costs you time, so it's better to catch them in the handover week than in the quarter after it.

Summary

When you change vendors, attention naturally focuses on the code, yet the blockers almost always come from elsewhere: copyright, account ownership and keys nobody inventoried. Three things are worth sorting out before you sign the acceptance protocol — a confirmed transfer of economic rights, including derivative rights, ownership of every account on your side and a release done with your own hands while the support window is still open.

At Mobilesoft we've taken over projects in very different states — from well-organised ones to those where the first task was restoring the ability to build the app at all. If you're facing a change of vendor and want someone to go through this list with you, we do it as part of our audits and consulting, and afterwards as app maintenance or IT team support. Take a look at our case studies, get in touch or go straight to getting a quote for your project.