Taking over someone else's codebase — what to check first
Not the code. With an inherited system the biggest risk isn't that it's badly written, but that you can't undo what you break in it.
The first instinct on a handover is to look at the code. That's understandable, and it's the wrong order. Code quality is a professional annoyance; a missing backup is a business risk, and it becomes yours the moment you touch anything.
- 01 1 · can it be restored
- 02 2 · is every credential available
- 03 3 · what runs, and on which version
- 04 4 · is there custom code, and who understands it
5 · and only now: what the code is like
One — can it be restored
The first question isn't whether a backup exists but whether anything can be restored from it. Those aren't the same: most hosts run some automatic backup that nobody has ever tried.
Until that's answered, every change is irreversible. So the first step is always the same: your own backup, in your own place, files and database separately — and ideally a copy you can test the restore on.
Two — is every credential available
Not just the admin panel, but the full list: hosting, database, domain control panel, mail configuration, and the licences for any paid extensions.
The licence is the most common hidden gap. A plugin keeps working without anyone noticing it's missing — right up until a security update arrives that can't be downloaded without a valid licence. That's when it emerges that the key belonged to the previous developer's account.
This is the same list worth going through from the client's side; there's a piece on who your website is tied to. As the incoming maintainer the only difference is that I have to report the gaps before taking the job on.
Three — what runs, and on which version
The language version on the server, the system version, the plugin versions, and most importantly: how far behind they are.
The size of that gap determines the risk of the work. One or two skipped versions is routine. Many skipped versions is no longer an update but a migration, because in the meantime the extensions can also have fallen out with each other.
What you must not do is update on day one. If something breaks then, it will be attributed to the new maintainer even if the fault had been ripening for two years. Backup and a copy first, then update the copy, and only afterwards production.
Four — is there custom code, and does anyone understand it
Most inherited sites carry a few bespoke pieces: a form extension, a price calculator, a link to some external system. These aren't bad by default — the question is whether they're comprehensible.
I look at three things: where it lives (in the theme or in a separate extension), what calls it, and what happens if it doesn't run. If those can't be established on the spot, then what's in front of me isn't code but a black box — and a black box can't be maintained, only hoped for.
Five — and only now: code quality
This is where most people would start, and it matters least. Ugly code is workable if it's comprehensible and recoverable. Beautiful code is worth nothing if there's no backup and half the credentials are missing.
One thing here is worth taking seriously: whether there's any sign that somebody has edited the system's core — the framework's own files. If so, the next update overwrites it, and the fault appears after the update, apparently out of nowhere.
When to say no
Three cases where I don't take it on. When full access can't be obtained — the responsibility would be mine, the tools wouldn't. When there is no backup and none can be made. And when the system rests on custom code nobody can explain and whose author is unreachable.
This isn't fastidiousness. Anyone taking on a site without these isn't selling maintenance but responsibility for something they can't see — and at the first serious failure, both parties lose.
The first week: document, don't fix
If the assessment checks out, the next temptation is tidying up. That's worth postponing. In the first week of a handover the urge to fix is at its strongest and knowledge at its lowest — that combination causes the most damage.
Instead: write down what is where, what does what, and what looks suspect. That note is what turns a half-day investigation three months later into a five-minute answer.
Questions on this topic
What's the first thing to check on an inherited site?
Not the code, but recoverability. Is there a backup, and can it actually be restored from. Until that's answered, every change is irreversible — and in an unfamiliar system the first change always brings a surprise.
Should a neglected site be updated straight away?
No, assess first. An update jumping across many skipped versions frequently breaks things, and if that happens on day one of a handover, the fault gets attributed to the new maintainer. Backup and a copy first, then update the copy.
When should you turn down a handover?
When full access can't be obtained, when there is no backup and none can be made, or when the system rests on custom code nobody can explain and whose author is unreachable. In those cases you wouldn't be taking on maintenance but responsibility for something you can't see.
What should the first week of a handover be spent on?
Documenting, not fixing. Writing down what is where, what does what, and what looks suspect. The urge to fix is strongest in the first week and knowledge is at its lowest — that combination causes the most damage.