Before anything else, confirm you can rebuild the system from what you hold. Code, database, and server configuration, all three.
Most people in this position have the code and assume that is enough. It is the natural assumption. The code is the part you can see, the part with a name and a repository and a login. But code on its own will not bring your platform back up if the server it ran on disappears tomorrow.
The glitches are not the real risk. An incomplete backup is.
Work through the four checks below in order, and resist fixing anything until all four are answered.
The four checks
- Do you have the code, and is it the version that is actually running?
- Do you have a database backup you have restored, not just one that exists?
- Do you control the accounts?
- Do you know how the server is set up?
01. Do you have the code, and is it the version that is actually running?
A repository that stopped being updated eighteen months ago is not your live system. It is a picture of what your live system looked like eighteen months ago.
The repository says 1,204 commits. The server says something else.
Check two things. First, the date of the last commit, against the date of the last change you remember seeing on the site. If those two dates disagree, the repository is behind. Second, ask your host for a copy of the files that are actually deployed, and compare them against the repository. Small fixes applied straight to the server are common, and they leave no trace in source control.
Then look for code that was never in the repository at all. A scheduled script. A small internal admin tool. A function running somewhere separate to handle webhooks or imports. These are easy to miss precisely because they work quietly.
02. Do you have a database backup you have restored, not just one that exists?
An untested backup is a hope.
Backed up nightly since 2023. Restored never.
Restore it. Put it on a separate machine, point a copy of the application at it, and open the application. Then check the parts that carry your business: order counts, customer counts, the date on the newest record. A backup that restores cleanly but stops three months short is still a serious problem, and you would far rather find that out this week than during an outage.
While you are in there, find out where backups are being written, whether the schedule is still running now that its author has gone, and whose account owns that storage.
03. Do you control the accounts?
Hosting, domain registrar, DNS, SSL, email, payment gateway, and any third party API keys. Add source control, error monitoring, analytics, and any app store listings.
This is where departures hurt most, and the damage is delayed. A domain renewing to an inbox nobody can open will take your site down months later, with no warning and no obvious cause.
The mailbox still receives. Nobody still here can open it.
For each account, ask four questions. Is it registered in the company's name? Is the card on it a company card that will not expire? Is the recovery email an inbox someone still here can open? Is two factor authentication tied to a phone you control?
Fix the recovery email first, before you change any passwords. Point every account at a shared company inbox. If you change a password but leave the recovery address pointing at a mailbox you cannot reach, you have made that account harder to recover rather than easier.
04. Do you know how the server is set up?
Runtime versions, cron jobs, queue workers, environment variables. Add the database version, the web server configuration, how the SSL certificate renews, and which ports are open.
Four jobs. Two comments. One person who knew what they did.
Cron jobs are the usual casualty. Nothing breaks visibly, and then a monthly report does not arrive, or invoices stop going out, or a supplier feed quietly stops updating. Copy out the full schedule now, write down what each job does, and check when each one last ran successfully.
Environment variables matter for the same reason. They hold the API keys and connection strings, they live only on the server, and by design there is no copy in the repository. Export them and store them somewhere safe before anyone touches that machine.
Once the four are settled
Now you are safe to move slowly and read. Learn the system before you change it. The urge to rewrite is strong and almost always premature: a system you do not yet understand is a system whose edge cases you do not yet understand either.
Until then, every day carries a risk you cannot quantify. Not a risk you have weighed and accepted, an unknown one.
One last thing, and it matters. None of this is a judgement on the developer who left. One person holding an entire platform in their head is a structural problem rather than a personal failing, and most of the gaps you are about to find are the ordinary result of one person doing the work of a team. Say that out loud to your own people before the finger pointing starts.
We start every takeover the same way, with an assessment before anything is touched: what exists, what is missing, what is at risk, and what it would take to put the system properly back in your hands. The fixing comes after that, not before.
DuskByte. Architect-led. Modernising platforms that already carry revenue.