How to take over a website from a previous developer

To take over a website from another developer safely, first make sure your business controls every account the site depends on, then collect the code and database, document how the site is deployed, audit its condition, and put arrangements in place so you are never locked out again. A common way for handovers to go wrong is a business discovering, too late, that the domain, hosting or code is in someone else's name. Working through the steps in order avoids that.

A handover may be friendly, such as a developer retiring or changing focus, or difficult, such as a dispute or a developer who has stopped responding. The steps are the same, but the order matters more when relations are strained. If you need help taking over a site, our website service page explains how we work.

Taking over a website from another developer: accounts to control first

Start with accounts, because without them nothing else is secure.

1. Domain name. The registrar account where the domain is registered. The domain should be in your business's name, with your contact email.
2. DNS. The service that points your domain to your website and email. This may be the registrar, the host or a separate service.
3. Hosting. The server or hosting account where the site runs, including control panel access.
4. Website admin. Administrator access to the CMS or application admin area.
5. Email. Business email accounts, which often depend on the domain and DNS.
6. Code repository. The place where the site's code is stored and versioned, if one exists.
7. Third-party services. Analytics, search console, payment gateway, email sending, maps, backups and paid plugins or themes.

A checklist for each account

For every account above, record:

• Who owns it, and whose name and email it is registered to.
• Who has access today.
• When it renews, and who pays for it.
• Whether two-step login is enabled.

If an important account is in the developer's name, ask for it to be transferred to your business before anything else. Change passwords and remove old access once the transfer is complete.

Getting the code and database

A website is more than what you see in the browser. You need everything required to run it elsewhere.

1. Request a full copy of the code, ideally through access to the code repository with its history.
2. Request a database export, which holds content, users, orders and settings.
3. Collect uploaded files, such as images and documents, which may be stored separately from the code.
4. Collect configuration details, such as environment settings and the list of services the site uses, without sharing passwords in plain email.
5. Collect licences for paid themes, plugins or libraries, so they can be updated legally.
6. Take your own backup immediately once you have hosting access, before making any changes.

A worked example

A business receives a zip file of the website's code from its former developer and assumes the handover is complete. Months later, the hosting renewal fails and the site goes offline. The zip file turns out to be missing the database and uploaded images, so the site cannot be restored. Taking a full backup from the live hosting on the first day, and testing that it restores, would have prevented this.

Documenting how the site is deployed

Deployment is how changes get from a developer's computer to the live website. Without knowing it, the next developer may break the site with their first update.

1. Ask how updates are made: directly on the server, through an automated deployment tool, or by uploading files.
2. Record the server details: operating system, PHP version, database type and any scheduled tasks.
3. List background processes, such as scheduled jobs, queues or automated emails.
4. Note custom changes, such as code modified inside plugins or themes, which could be lost at the next update.
5. Document the staging site, if one exists, and how it is kept in step with the live site.

Questions to ask the previous developer

1. How do you deploy changes, and are there any manual steps?
2. Which plugins, libraries or core files have you modified?
3. Which scheduled tasks or background jobs does the site rely on?
4. Are there any known problems or unfinished work?
5. Which external services does the site depend on, and who owns those accounts?

If the site runs on an old PHP version, our guide on whether PHP is still used explains what modern PHP offers when you plan updates.

Auditing the site after handover

Once you have control, find out the site's real condition before planning changes.

1. Check software versions for the CMS or framework, themes, plugins and PHP, and note anything outdated or unsupported.
2. Check security basics: admin accounts, passwords, two-step login, file permissions and HTTPS.
3. Test backups by restoring one to a staging site.
4. Test key journeys, such as contact forms, bookings, checkout and emails.
5. Check speed on key pages, especially on mobile.
6. Check search settings, making sure the site is not accidentally blocked from search engines.
7. List what needs fixing first, separating urgent security and stability issues from improvements.

If the site runs on Laravel, a Laravel-experienced developer can also check how outdated the framework is. Our guides on how to upgrade an old Laravel application safely and what to check before hiring a Laravel developer cover the next steps.

For Laravel sites, our Laravel security checklist covers the framework settings to review.

Avoiding the same problem next time

A difficult handover is a lesson worth applying straight away.

1. Keep every key account in your business's name, and give developers access rather than ownership.
2. Put ownership in the contract: the code, content and data belong to your business once paid for.
3. Require version control in a repository your business controls.
4. Ask for simple documentation covering deployment, services and credentials locations.
5. Keep an account register listing every service, its owner, renewal date and who has access.
6. Review access when people change, removing former staff and agencies promptly.

A common mistake and its fix

A common mistake is letting a developer register the domain "to save time" during the original build. The fix, for new projects, is simple: register the domain yourself, then give the developer the access they need to connect it.

Summary

• Secure the domain, DNS, hosting, admin, email, repository and third-party accounts first.
• Collect the full code, database, uploaded files, configuration and licences, and take your own tested backup.
• Document deployment, server details, background tasks and any custom changes.
• Audit versions, security, backups, key journeys, speed and search settings before planning changes.
• Keep accounts in your business's name, put ownership in contracts and maintain an account register.

A careful handover protects your website and gives the next developer a clear starting point. If you need help taking over a website from a previous developer, you can tell us about it here.