This situation walks in our door more than any other: the site was built by an agency or a freelancer, the relationship faded or blew up, and now something is broken, nobody has the passwords, and the person who knew how it all worked is gone. Here is the exact order of operations, from recoveries we have actually run.
Step 1: Access. Everything else waits.
Inventory what you control right now: domain registrar, DNS, hosting account, CMS admin, database, transactional email, analytics. The domain is the crown jewel; whoever controls the registrar account controls your existence on the internet. If the agency registered your domain under THEIR account, fixing that is priority one, politely and immediately, while the relationship is still salvageable enough to cooperate.
Step 2: Backup before you touch anything.
Full copy: files, database, DNS records (screenshot the zone), email routing. The recoverable state you have today is the worst state you should ever be in again. Do this before rotating passwords, before “just trying something,” before the well-meaning nephew logs in.
Step 3: Rotate and lock.
Every credential the old party ever had: hosting, CMS admins, FTP, database users, API keys. Audit the user lists while you are in there; abandoned sites accumulate ghost admin accounts. In one takeover we found 632 stale email accounts riding on the client’s infrastructure.
Step 4: Audit what is actually running.
Now, and only now, look under the hood. What you are looking for:
- Security exposure. On one recovery, the site’s entire source control history sat publicly downloadable in an exposed .git folder. Ten minutes to close, catastrophic to leave.
- Disk archaeology. Error logs and backup files that grew for years (we have cleared 144 GB from a single site), old staging copies, plugins nobody used.
- Buried business data. This is the good surprise. Databases of abandoned sites often hold form submissions and orders that never reached anyone’s inbox. That same recovery surfaced 1,327 legitimate leads sitting unanswered in a database table. The site everyone had written off was holding a pipeline.
Step 5: Decide rebuild vs. stabilize, with numbers.
Only after the audit do you make the money decision. Stabilize when the platform is sound and the problem was neglect. Rebuild when the foundation itself is the liability, and take the audit findings with you so the new build inherits the lessons instead of the debt. Our build vs. buy vs. partner framework covers how to price those paths honestly.
The lesson to carry forward
None of the disasters above were exotic. They were all the same root cause: a single point of failure with no documentation and no second set of keys. Whoever you work with next, the standard is simple: your accounts in your name, credentials in a manager you control, a written map of how the system works, and backups you have personally seen restore.
If you are staring at a black box right now, send us a brief and we will tell you honestly whether it is a stabilize or a rebuild. And if the old site has data in it, do not let anyone wipe it before someone looks.
