Taking over a system from the developer who left

Start with access, not code. In the first week you inventory every account the system touches, take control of the ones still in another person's name, and prove that a backup actually restores; reading the source can wait until you are able to recover from your own mistakes. The answer flips when nobody can reach the hosting account or the database: then the handover is a recovery project, and the first job is a restore, not a review.

What do you inventory before you read anything?

Every route into the system, in one table, on the first day. Hosting or cloud account, DNS, domain registrar, database, storage for uploaded files, transactional mail, SMS, payment gateway, monitoring, error tracking, the build pipeline, the repository, app store listings, analytics, the backup service, the third-party APIs, and the administrator logins inside the application itself.

For each row, four columns: the account, whose email receives recovery, who holds the second factor, and whose card pays for it. Mark every line you cannot open. Those marked lines are the project — everything else is reading.

Why does the restore come before the review?

Because a backup nobody has restored is a claim, not a safeguard. Take the latest backup, restore it into an environment that is not production, open the application, and check one record you can verify by hand: the last invoice, the stock of a single item, the most recent payment. Write down how long the whole sequence took. That duration is the only recovery time you actually have, whatever the contract said.

NIST's contingency planning guide puts testing and exercises inside the plan rather than beside it, and the same logic holds at a smaller scale: an untested restore is a hypothesis. If the backups turn out to be database-only, or weekly, or stored on the same disk as the application, you have found the first risk without reading a line of code — and it is a risk you can fix this week.

What do you read first, and what do you leave alone?

Read the path from a commit to production, the scheduled jobs, the integrations with third parties, the error log from the last month, and the parts of the database schema that surprise you. That is where the system's real behaviour lives, and none of it is in the code comments.

Leave alone the refactoring, the framework upgrade, the naming, the style, and the tempting rewrite. In the first month, every change is also a change you cannot attribute to the old code when something breaks — and something will break, on a day you would not choose.

How do you freeze the scope for the first month?

Week	What you do	What you leave alone
1	Inventory accounts, copy data, test a restore	Every code change
2	Read the deploy path, jobs, integrations	Refactors and upgrades
3	Fix only what blocks money	New features
4	Write the findings and the risk list	Promises about dates

Put it in one page: bug fixes and access work only, feature requests collected with dates and no promises, no migrations, no redesign. The reason is not caution for its own sake. The first month is where a handover either settles or becomes a run of incidents that get blamed on the new team, and a written freeze is what lets you say later which changes were yours.

What do you write down, and for whom?

For the person who is not you, arriving in a year. How to get a clean machine to a running environment. The account list with names against it. The scheduled jobs and what stops when each one fails. The integrations, with whoever owns each contract. The known defects with a way to reproduce them. The three things most likely to break next, and what to do first when they do.

Write it while you are learning, not afterwards. The notes from week two are the documentation nobody else has, and they are also the evidence that the handover was done properly.

What turns a handover into an outage?

Two things, mostly. The first is revoking access before you have a way in. The leaver is often the only administrator of the database, the DNS or the mail account, and removing them can remove your route back in. Copy first, then revoke, one credential at a time, logging what you changed and when — and not on a Friday.

The second is changing something early to demonstrate progress. A deploy that goes wrong in week one, before you know how the old system recovers, turns a quiet takeover into a public incident with your name on it.

A third is quieter: letting the previous developer's absence become the explanation for every failure. Some of what breaks next week was already broken.

The order for the first thirty days

1. Take a read-only copy of the database and the repository before touching anything.
2. Inventory every account, credential and billing relationship, and mark what you cannot access.
3. Confirm the renewals are paid — domain, hosting, third-party plans. An expired card is the fastest outage available.
4. Restore the latest backup elsewhere and time it end to end.
5. Change the credentials you now control, one at a time, and log each change.
6. Read the deployment path and the scheduled jobs.
7. Put the thirty-day scope freeze in writing and send it to the owner.
8. Deliver the findings document and the risk list at the end of the month.

Where this goes wrong

• Nobody has the second factor. The leaver's phone is the recovery device for the domain, the hosting and the mail, so recovery runs through a support queue rather than a plan.
• The domain expires during the handover, because the renewal sat on a personal card and nobody noticed until the certificate failed.
• The backups were never tested and turn out to cover the database but not the uploaded documents customers rely on.
• Two people deploy at once, one following the old process and one the new, and neither can say what is running.
• The leaver is still the only one who can deploy, so the handover is nominal and the dependency survives the paperwork.
• A scheduled job stops — the invoice run, the nightly export — and nothing alerts, so it is discovered a month later by a customer.

What this does not cover

This is not a security audit, a performance review, or a reading of the previous contract. It does not tell you whether to keep the system or replace it: that answer needs a month of running it and a cost comparison, not a code review. And if the previous vendor is unreachable while holding the accounts, the next step is a registrar and a lawyer, not an engineer — that is a dispute, not a handover.

We take systems over in this order — access, restore, freeze, document — and we leave the findings behind, because the next handover should be shorter than this one.