How to Take Over a Website Built by Someone Else

Taking over a website someone else built starts with collecting the keys, not the code. Before you change anything, get control of the domain, hosting, and admin logins, take a full backup, and gather the design files and a list of every plugin and third-party service the site depends on. Only once you actually hold all of that do you really have the site. Then you audit it, so you know what you have inherited before you rely on it. Here is the clean way to do a handover.

Step 1: Collect the accounts and files

This is the part that goes wrong most often, so do it first and thoroughly. You want, in your own name:

1. The domain registrar login. Whoever controls this controls the site and email.
2. The hosting account. Or a clear plan to move to your own.
3. The CMS admin. An administrator account that is yours, not a shared one.
4. A full backup. Files and database, downloaded and kept somewhere safe.
5. Design source files. Logos, images, and any design assets.
6. A dependency list. Every plugin, integration, payment gateway, email service, and third-party account the site uses, with its own logins.

If the previous developer is cooperative, ask for all of this in writing. If they have gone quiet, getting access when a developer will not reply covers your options, and who owns your website explains why each piece matters.

Step 2: Audit before you trust it

An inherited site is an unknown. Before you build on it or promise anyone it is fine, find out what state it is really in. Run a proper website audit covering:

• Security. How out of date is the software? Any signs of malware? Old, unused plugins?
• Backups. Is anything actually backing it up, and does it work?
• Speed and mobile. Does it load fast and work on a phone?
• How it is built. Is it a standard, maintainable setup, or something custom and undocumented that only its author understood?

This audit is what tells you whether you have inherited a solid site that needs routine care, or a problem that needs real work.

What if the site is a mess?

Sometimes the audit reveals a site that is insecure, outdated, or built in a way nobody can maintain. That is a real fork in the road: stabilise and keep it, or rebuild.

Keep and maintain it when the bones are sound and the problems are the normal backlog of neglect: pending updates, missing backups, a few broken things. Most inherited sites are this, and a period of catching up fixes them.

Rebuild when the site is fundamentally insecure, depends on abandoned software, or is so custom and undocumented that every change is a gamble. In those cases, patching it forever costs more than a clean start. Do not rebuild just because you did not write it, though. That is ego, not economics.

The traps to avoid

A few things that catch people taking over a site:

1. Assuming a backup exists. Confirm it, do not hope.
2. Changing things before you have a backup and access. If you break it, you want to be able to undo it and get back in.
3. Missing a dependency. A payment gateway or email service tied to the old developer's account can fail later when you did not know it existed.
4. Not resetting shared passwords. The previous developer may still have access. Reset everything.

What to do next

Before you touch the site, make sure you hold all six items from step one, then run an audit so you know what you have. That order matters: control first, then knowledge, then changes. If the site turns out to need ongoing care to bring it back up to standard, that is exactly what a maintenance plan is for.