Developer Left? How to Take Over a Software Project Without Starting Over

Your developer is gone.

No handover. No checklist. Just software that mostly works, and nobody who knows how it works.

Starting over can feel like the safe choice. But don't decide that in week one.

Here's what to secure first, two tests to run, and how to choose: rescue, repair or rebuild.

The developer left. How to take over a software project without starting over.

Step one: secure control. You can't fix or replace what you can't log in to.

Picture four keys: code, domain, hosting and paid services. For each one, note who can log in, and whose name and card are on it.

Your code lives in a repository, like GitHub. If it's in the developer's account, they have to transfer it. Then remove their access, and have a developer replace its keys.

The domain has a quiet risk: expiry. The expiry warnings go to the domain's holder. So make your business the holder, with an email you read, and put the expiry date in your calendar.

For hosting and every paid service, find the login and the card. A service on the developer's card can stop when they stop paying.

Then change the passwords the developer knew. But leave the software's own keys to a developer, or the software stops working.

One note: control is not legal ownership. If that's unclear or disputed, ask a lawyer before you move anything.

Step two: two tests. First, has a backup ever been restored?

A nightly backup job proves nothing until the data comes back. CISA, the US cybersecurity agency, tells you to test your backups regularly.

Have a developer restore the latest backup into a separate copy, never over the live system. Check that it starts, and that the data is recent.

Test two: can anyone still deploy, meaning put a new version live? Have a developer deploy one harmless change to a test copy, then live.

If nobody can deploy, every fix waits.

Step three: after the first week, decide. We use three words for three paths.

Rescue: stabilize, recover, regain control. Repair: fix, improve, strengthen. And Rebuild, when starting again is the smarter move.

Ask four questions. Does it still do the job? Can someone deploy and restore it? Are the problems in a few places, or everywhere? And who depends on its exact behavior?

The last question is where rebuilds go wrong. As Martin Fowler puts it: replacements seem easy to specify, but often it's hard to figure out the details of existing behavior.

Hiring help? A good sign: a new developer who asks to restore and deploy first.

A real case. A client's old API ran on a server nobody maintained. A partner's software depended on it, and sent its requests from PHP 5.6, unsupported since the end of 2018.

We rebuilt that one API inside the client's new system, with one rule: answer exactly like the old one.

We recorded 64 real requests and replayed them. 57 matched exactly. The other 7 only spelled a few option codes differently, and each one went into a report.

Of 59 prices, 52 matched. The other 7 came from a newer price list: the correct change. And the old server stayed as it was, so we could switch back.

It went live on 10 September 2026. The partner changed nothing, and has reported no problem since. A rebuild, but not a fresh start.

Your first week: list every account. Move the code and the domain into your business's name. Put the expiry date in your calendar. Have a developer test a restore, then a deploy. Then decide.

Not sure what you still control? Tell us what you have at teamarcai.com. You'll hear from a person within one business day.