How to hand over a website you inherited from a previous developer
The developer is gone and the site is yours. How to take control safely: accounts, code, documentation, and what to check before changing anything.
The short answer
A website you inherited, from a departed developer, a closed agency or a previous owner, is a system you do not yet understand running on accounts you may not control. The instinct is to start fixing. The right order is to stop, find out where everything is, get access, take a backup, check it is not already compromised, and only then change anything.
Most inherited-site disasters come from skipping that order: a change made without knowing where the DNS lives, a plugin update on a site with no backup, an improvement built on a compromised install.
Week one: locate and secure
- Inventory the six things. Domain, DNS, hosting, code, content, analytics. For each: which provider, which account, whose name, who can log in. Fill in the who-owns-what table.
- Get or recover access. The registrar from a public domain lookup, which still shows it. Hosting via the DNS records. Content system via an admin reset if you control the email domain. Code from the hosting if there is no repository.
- Take a full backup before touching anything. Files, database, DNS records exported, content exported. Store it outside the hosting.
- Rotate every credential you inherited. Passwords, API keys, hosting tokens. Remove accounts you cannot identify. Turn on two-factor everywhere.
- Run a security scan. You need to know whether you inherited a clean site or a compromised one before you build on it.
What to look for during inventory
| Finding | What it means | What to do |
|---|---|---|
| Domain in the previous developer’s name | The business does not own its address | Transfer to a company account first, before anything else |
| Hosting on their plan, with nothing in writing about transfer | The site can vanish with their account | Move it to your name, or get the transfer promise in writing |
| No repository, only files on the server | The code exists in one place | Copy it out; put it under version control |
| Unknown admin accounts | Possible leftover access, possible compromise | Remove; rotate; scan |
| Plugins years out of date | Likely vulnerable | Update after backup, or plan a move off the platform |
| Analytics owned by an agency | Your data in someone else’s account | Request ownership transfer; create your own if refused |
| No documentation | Everything is in someone’s head | Write the one-page version yourself from the inventory |
Week two: document and decide
With inventory, access, backup and a scan in hand, write the one-page ownership document and a short technical description: platform, how content is edited, how the site is deployed, which services it depends on. Then decide: is this a site to take over and run, or a site to rebuild with a content import? The inventory gives you the answer; the scan and the platform decide it.
What this means for you
If a site has landed in your lap, resist the urge to improve it. Locate the six things, get access, back up, rotate, scan, document. Then decide whether to run it or replace it. The order is what turns an inherited liability into an asset you actually control.
Frequently asked questions
The previous developer is not answering. What can we still do?
More than you think. A public lookup shows which registrar holds the domain and when it expires; the registrant's name and contact details are redacted under the applicable registration data policy, so finding out who registered it means a disclosure request to that registrar. DNS records show where the site and mail are pointed, which identifies the host unless it sits behind a proxy. The code may be recoverable from the hosting itself. Start with what you can reach, document it, and treat anything only they held as a gap to close. If the domain is in their name, that is the priority.
Should we rebuild instead of taking it over?
Decide after the inventory, not before. If the site is on a platform you can run, the code is recoverable and a scan is clean, taking it over is cheaper. If the code is missing, the platform is unmaintainable or the scan is alarming, a rebuild with a content import is the safer path. The inventory gives you the facts to choose.
How long does a proper takeover take?
Inventory and access in days, if the accounts are reachable. Documentation, credential rotation, backup and a first scan in the first two weeks. Then the site is yours to run. A takeover that skips those steps feels faster and costs more later.