Taking Over Someone Else's Code: A Handover Checklist

Changing development vendor tends to go wrong quietly. The new team receives a zip file and a server password, everything appears to work, and three months later nobody can deploy because the build step lived on a laptop at the old agency. A software handover checklist exists to find those gaps while the outgoing team still answers email.

This one is written for the client, the person changing vendor, although incoming developers will use it too. The order matters: ownership first, then what to collect, proof that it works, credentials, an audit and the first month.

Get every account into your own name first

Do this before you give notice if you can. The principle is that your company owns each account and vendors are invited into it as users. Go through the list and note whose name and card is on each:

• the domain registrar and DNS;
• the hosting or cloud account;
• the code repository. On GitHub a repository can be transferred to your organization with its history, issues and pull requests;
• the Apple Developer and Google Play Console accounts. An app published under the agency's account has to be moved to yours, and both stores have a transfer process that keeps users, ratings and reviews (Apple's app transfer overview, Google Play's transfer guide);
• payment, email, SMS, maps and any other API accounts;
• analytics, tag manager and Search Console;
• licenses for paid plugins, themes, libraries and fonts.

Read the contract at the same time. Look for who owns the source code and when ownership passes (often on final payment), the notice period, and whether help with the handover is included. Have your counsel confirm anything unclear before the conversation with the vendor, not after.

What to ask the outgoing team for

• The repository with its full history, branches and tags, and a note of which commit is live. A zip of the current files is not a substitute.
• The data: a database dump and the uploaded files, unless both already sit on hosting you control.
• Environment configuration: every variable in the .env file or its equivalent, with a line on what each is for. Values should travel through a password manager, never by email.
• Server setup: the PHP version and extensions, web server configuration, cron entries, queue workers and whatever keeps them running.
• Build and deployment: the exact steps or the pipeline file, including anything that only runs on one person's machine.
• Integrations: each third-party service, what it is used for, and where its keys and webhooks are configured.
• Mobile apps: signing keys, keystore passwords and store listing access.
• Documentation as it exists, and an honest list of known bugs and unfinished work.
• A recorded walkthrough in which the developer who knows the system deploys it and explains the odd corners.

Agree a date for all of this, and if the contract allows, a few paid hours for follow-up answers during the weeks after.

Check that the repository is what runs in production

The most common surprise is a live server carrying changes that were never committed: an urgent fix made over SFTP two years ago, or a config file edited by hand. Three commands on the server show where you stand:

cd /var/www/app
git status --short
git log -1 --format='%H %cd'
crontab -l

The first lists files changed or added on the server but missing from the repository. The second prints the deployed commit, which you compare with the head of the main branch. The third shows scheduled jobs that may appear in no document. If the live folder is not a Git checkout at all, compare it with a fresh clone using a directory diff tool.

On a Laravel application, php artisan about, php artisan schedule:list and php artisan migrate:status add the environment summary, the scheduled tasks and any migrations that are pending or have lost their files.

The real acceptance test is simple to state. The new team builds a working staging copy from the repository, the database dump and the documented configuration, without asking the old team anything. Until that succeeds, the handover is not finished.

Rotate credentials in a planned order

Changing every credential after a handover is routine hygiene, like changing the locks when a tenant leaves. It says nothing about trust. Do it in one planned session, because a rotated key breaks an integration until every place that uses it has been updated.

1. Give the new team their own named accounts everywhere. No shared logins.
2. Remove the outgoing team's access: hosting users, repository members, admin users in the application, SFTP accounts, SSH keys in authorized_keys, deploy keys, pipeline secrets and store users.
3. Change the shared secrets: database passwords, API keys for payment, email and SMS, SMTP passwords and webhook signing secrets. Update the environment configuration and redeploy.
4. Handle application keys with care. On WordPress, wp config shuffle-salts replaces the salts and signs every user out. On Laravel, changing APP_KEY signs users out and makes previously encrypted data unreadable unless the old key is listed in APP_PREVIOUS_KEYS, as the Laravel encryption documentation explains.
5. Look for things that should not be there: unknown admin users, unfamiliar scheduled tasks, extra SSH keys, mail forwarding rules.
6. Switch on two-factor login for every account that offers it.

Audit before anyone promises a deadline

A sensible incoming team spends its first days reading, not building. What you should get back is a short list of risks in order of seriousness, covering at least:

• the PHP, framework, CMS and database versions, and whether each is still supported;
• known vulnerabilities in dependencies, from composer audit and npm audit, and how far behind the packages are, from composer outdated --direct;
• whether automated tests exist and pass;
• whether backups exist, sit off the server and have been restored;
• what the error log shows failing today;
• the basics of security: debug mode off in production, no secrets committed to the repository, the admin area protected;
• a speed baseline for the main pages.

Be wary of a team whose first recommendation is a rewrite. Unfamiliar code always looks worse than it is, and most inherited systems need a handful of targeted repairs. Our guide to technical debt for founders covers how to weigh those repairs against new work.

The first 30 days

Week	Focus	Done when
1	Access, a fresh backup, a staging copy built from the repository	The new team can sign in everywhere it needs to, and staging works
2	First deployment and monitoring	A trivial change has travelled from the repository to production by the documented process, and alerts reach the new team
3	Credential rotation and urgent audit findings	Old access is gone and the top security items are fixed
4	Documentation and backlog	A README covers setup, deployment and integrations, and priorities for the next quarter are agreed

Keep feature work out of the first two weeks. One small, real change shipped end to end is the best evidence that the handover worked. Support terms for the new arrangement can be settled in the same month, and our explanation of support SLAs shows what to look for in them.

If the old vendor will not cooperate

When you control the hosting you already hold most of what matters. Take a full server snapshot and a database dump before anything else, then make the code on the server the first commit of a new repository. What you may lose is the commit history, the build configuration, and the readable source of any front-end code that exists on the server only in compiled form.

Mobile apps are harder, because publishing an update needs the signing keys and the store account. For an Android app enrolled in Play App Signing, a lost upload key can be reset through the Play Console. Without access to the developer account itself, expect to deal with the store's support team, and plan that route early.

Who should run the software handover checklist

If you have developers in-house, they can work through everything above, and the outgoing vendor will usually help when asked for specific items by a specific date. If the system is moving to another agency, that agency should run the process as its onboarding and show you the results: the access list, the staging build, the audit.

That is how takeovers begin in our maintenance and support work, and for apps in mobile app maintenance. When the audit shows that the platform itself is the problem, such as an unsupported framework or a server nobody can rebuild, the next step is a migration or modernization plan. On our own projects the client owns the source code, and that is the term to insist on with any vendor, so the next handover starts from a better place.

Frequently asked questions

Should the old and new teams overlap?

Yes, whenever it can be arranged. A few weeks in which the outgoing developers are still under contract and answering questions is the cheapest insurance in the whole process. Most of the knowledge that is written nowhere comes out in those conversations.

What if there is no documentation at all?

Then writing it becomes part of the takeover. The incoming team documents setup, deployment and integrations as it works them out during the audit, and you should ask for that document as a deliverable.

Do customers or users need to be told?

Usually not, since nothing changes for them. The exceptions are a key rotation that signs everyone out, any planned downtime, and privacy paperwork: if your policies or data processing agreements name the old vendor as a processor, they need updating. Confirm the wording with your counsel.