Taking over a project from a developer who is leaving

A familiar case: the agency relationship is ending on good terms. The last invoice is paid, and the agency sends a zip file and a password list. Two months later the new team tries to deploy a small change and discovers the zip does not match what runs in production, the password for the payment integration is missing, and nobody knows why a scheduled job runs every night at 03:00. The handover happened. It was not complete.

The short answer#

A good handover transfers four things: ownership of every account, the exact code and configuration that runs in production, the knowledge needed to change it safely, and a list of what is unfinished or fragile. Ask for them in that order, because accounts are the hardest to recover later and knowledge disappears fastest once people move on. Before the final invoice or the end of the notice period, verify the handover by having someone other than the outgoing developer deploy a small change to production and restore a backup to a test environment. If those two things work using only what was handed over, the handover is complete.

First: accounts and ownership#

Everything should be owned by your company, with the outgoing developer removed or reduced to a user.

• Domain registrar and DNS.
• Hosting or cloud account, and the billing on it.
• Code repositories.
• CMS or shop administrator accounts.
• Third-party services: payment providers, email sending, delivery integrations, analytics, error monitoring.
• API keys and credentials for every integration.
• Licences for paid themes, plugins and libraries.

The article on who owns your website has the full list and how each transfer works.

Second: the code and configuration that actually run#

• The repository, including the full history, not just the latest files.
• Confirmation of which branch or version is in production right now.
• Environment configuration: variables, secrets, settings, stored securely, not in email.
• Deployment: how a change gets to production, including scripts, pipelines and manual steps.
• Scheduled jobs: what runs, when and why.
• Database access and a recent backup.
• Infrastructure details: servers, services and their versions.

Third: the knowledge#

• An architecture overview: the main parts of the system and how they connect.
• How to run the project locally.
• Integrations: what each one does, who the contact is on the other side, and known quirks.
• Known issues, workarounds and things that break if touched.
• Unfinished work and anything promised to users but not delivered.
• A walkthrough call, recorded, where the outgoing developer shows the system and answers questions.

A handover document does not need to be long. It needs to be accurate.

Fourth: the risk list#

Ask directly: what are you worried about? The outgoing developer usually knows which parts are fragile, which dependencies are outdated, and which shortcuts were taken under deadline. Write the answers down.

Verify before the end#

1. Someone from your side, or the new team, clones the repository and runs the project using only the handover documents.
2. They deploy a small, harmless change to production.
3. They restore a backup into a test environment and start the application.
4. They log in to every account on the list with company credentials.

Anything that fails is a gap to close while the outgoing developer is still available.

Put it in the contract next time#

Handover obligations belong in the original contract: company ownership of accounts from the start, documentation delivered throughout, and a defined handover period at the end.

If the developer has already stopped responding, the situation is different and more urgent. The section on an unreachable developer in who owns your website covers the first steps.

Nevo takes over systems from previous developers and agencies. The codebase takeover page describes how that work starts.