Websites change hands more often than their owners expect. A freelancer moves on, an agency relationship ends, the person who built it with an AI tool changes role. The website keeps running — until something needs changing and nobody knows where to start.
A good handover turns that moment into a short, organised transfer. You don’t need technical knowledge to lead it. You need a list, a little persistence and a clear idea of what the new developer should be able to do afterwards.
Begin with what your business controls.
Before anyone touches the code, make sure the important accounts belong to your business rather than to a person who is leaving. List each one with its owner, the login email and when it renews:
- The domain registrar and DNS provider.
- Hosting, or the platform subscription if the site lives on a hosted builder.
- The code repository and deployment service, if there is one.
- Email sending, form, booking, analytics and any other connected services.
If an account is registered to someone else’s personal email, arrange a transfer now. It is much harder to do after a relationship has ended.
Give access the right way.
A new developer needs working access, not your passwords. Most platforms let you invite a user or add a collaborator with their own login. That way you can see who has access, and remove it later without changing everything.
Avoid sending credentials by email or chat. Share them through the platform’s invitation, or through a password manager if a shared login cannot be avoided.
Hand over the knowledge, not just the logins.
Access tells the new developer where things are. It does not tell them why. Ask the previous developer, or whoever knows most, for a short written note covering:
- How the site is built: platform, frameworks, themes or templates, and anything custom.
- How changes are made and published — directly on the live site, through a preview or staging copy, or through a repository and deployment.
- Where forms and integrations send their data, and who receives it.
- How backups or exports work, and whether a restore has ever been tested.
- Known issues, workarounds and anything that “must not be touched”.
Let the new developer review before they promise.
A responsible developer will want to look at the site before agreeing to maintain it. Expect questions about access, the deployment process and any backlog of updates or problems. That is a good sign: it means the scope will be based on the real website rather than assumptions.
The review may turn up work that needs doing before regular care can start — outdated components, a broken integration, a missing recovery route. It is reasonable for that to be quoted as a separate, one-off job, so it does not blur into the monthly scope.
The first weeks after the handover.
- Confirm every account on the list is accessible to the right people.
- Establish a recovery point you control, and check that it can actually be restored.
- Test the most important customer journey end to end.
- Record the current state: versions, open issues and agreed priorities.
- Remove access for people who no longer need it.
After that, the new developer is in a position to take responsibility — and you know exactly what they are responsible for.
On WordPress?
WordPress handovers have a few specifics of their own, from plugin licences to admin users. Our sister service has a detailed first-week handover checklist for WordPress sites.
For other platforms, including AI-built websites, tell us about the site you want to hand over. We’ll tell you what we need for a clean start.
