Handing a website over to another development team

A handover is usually treated as done once a code archive and a few passwords have been sent. In practice the real test is different: can the new team make a small change themselves and ship it to the live site without phoning anybody. Until that has been demonstrated, the handover is a promise rather than a fact. The distinction matters, because the missing pieces reveal themselves exactly when an urgent fix is needed.

In short

• There is one acceptance criterion for a handover: the new team independently ships a small change to the live site.
• Access should be handed over as an inventory with owners, not as a list of passwords in an email.
• More important than the code is being able to run it: environment variables, database structure and the release process.
• Hand over the code's history, not just its latest state — without history nobody can tell why something was done.
• Rotate passwords and keys afterwards. A handover without rotation means the old team still has access.

The access inventory

The thing most often missing is not the code — it is access to accounts nobody listed, because one person always used them. It helps to build a table: the account, who owns it, who has access now, and who will have access after the handover.

• The domain registrar and DNS management — the most often forgotten and the most important entry.
• Hosting or the deployment platform, including where environment variables are configured.
• The code repository, and the right to create new releases.
• The database: access, where backups live, and how a restore is performed.
• The email sending service and the domain verification records.
• Analytics, Search Console and any monitoring tools.
• Content management system administrator accounts.
• Payment or other external service accounts, where used.
• Certificates and keys, where they are not issued automatically.
• Third-party licences: fonts, images, components.

Code and its history

A compiled or archived result is not a handover. The new team needs the code with its version history, because the history is the only place that records why something was done a particular way. Without it every unusual decision looks like a mistake, and somebody will try to "tidy it up" — usually breaking whatever that decision was protecting.

• The full repository with history and branches, not an archive of the latest state.
• A list of the parts that are not your code: libraries, templates, external components.
• A description of the database structure and the history of its changes.
• A list of environment variables explaining what each one does — without the values.
• Automated tests, if any exist, and instructions for running them.

Can it actually be run

This check answers the most important question and is often skipped. It helps to have the new team bring the site up in their own environment from scratch, following the handed-over documentation, with no help from the outgoing team. If that does not work, the documentation is incomplete — and it is far better to discover that during the handover than during the first incident.

• A local run following the documentation, with no additional verbal explanation.
• A staging environment that is not the live site, so changes have somewhere to be checked.
• The release process: how a change reaches the live site, and who is able to do it.
• The rollback process: how a previous version is restored if a release goes wrong.
• A tested backup restore — a backup nobody has restored is an assumption.

Documentation that is actually useful

A long document usually goes unread. A short text answering the specific questions the new team will ask in their first week is worth more: where things are, what is not obvious, and what not to touch.

• A brief description of which parts make up the system and how they relate.
• Decisions that look unusual, and the reason they were made that way.
• The fragile places: where a change can unexpectedly affect something else.
• Routine maintenance tasks and their rhythm.
• Known issues and deferred work — an honest list is more useful than silence.
• Contacts for external services you do not control.

Proof of acceptance

A handover is worth treating as accepted only when there is proof rather than verbal confirmation. The simplest and strongest proof is a small real change: the new team edits one piece of text or fixes a small detail and ships it to the live site themselves. That single act tests access, the environment, the release process and the documentation together.

An illustrative example

Illustrative scenario, not a description of a client project. Imagine a handover treated as complete: code sent, passwords passed on, invoice paid. A month later a phone number in the site footer needs changing. It then emerges that the number is not in the content system but in the code; that releasing requires an environment variable nobody handed over; and that DNS is still managed from the outgoing team's account. Technically these are small things — but an urgent five-minute change takes a week. Had the acceptance criterion been "the new team ships a small change themselves", all three gaps would have surfaced on handover day.

Rotating credentials afterwards

A handover is not finished until access has been changed. While the passwords and keys are the same, the outgoing team still has access — usually with no ill intent, simply historically. Rotation is also a practical test: if changing a key breaks something, there was a dependency nobody knew about.

• Change administrator passwords and the keys for external services.
• Review who has access to each account and remove people who no longer need it.
• Check that rotation broke nothing — this is the best moment to notice.
• Record who now owns each account.

What this guide does not tell you

It contains no amounts, no timelines and no contract wording. The scope of a handover depends on the system, so any duration or figure written here would be an assumption. Nor is it legal advice about intellectual property or terminating an agreement — those are worth checking with your own lawyer. Its purpose is different: that a handover has a verifiable acceptance criterion rather than just a ticked box.

If you take only one thing from this list, take this: do not treat a handover as accepted until the new team has shipped a small change to the live site themselves.