Before you hand over your code

Changing developer is ordinary. It only turns into a recovery operation when the domain, the hosting or the code are in somebody else's name. What to check, and what to ask for while everyone is still speaking.

At some point most businesses change developer. The last one moved on, or the work stalled, or you need something they cannot build. Whatever the reason, there is a handover, and the handover is where nearly all of the avoidable pain in this situation happens.

Almost none of it is about the code. It is about a login nobody can find.

Work out what you actually own

Ask most owners whether they own their website and the answer is yes. Ask them to log in to the account the domain is registered in and the answer gets less certain. There are four things that matter, and the test for each one is the same: can you get into it yourself, today, without asking anybody?

In your name, not theirs

The most common trap is ownership that was never really transferred. A domain registered inside the developer's own registrar account. Hosting on their card, re-billed to you. A code repository under a personal account rather than a business one.

This is rarely done to trap anyone. It is what is convenient on the day a project starts, when nobody is thinking about how it ends. It only becomes a problem later, and usually not because somebody turns hostile, but because they are unreachable, or they have moved on and stopped paying attention to an account they forgot they held.

Fix it while the relationship is good. Transferring a domain takes minutes when everybody is cooperating, and it is the single most valuable half hour of admin in this whole list.

The code is not the whole system

A copy of the source code, on its own, will not run. The pieces that turn code into a working system live outside it, and they are the parts that get forgotten in a rushed handover.

Ask specifically for the configuration and secrets the application needs to start, the database and a recent backup of it, anything that runs on a schedule, the DNS records, and how it gets from the code to the live site. A new developer handed only a folder of code will spend their first week rediscovering these, and you will pay for that week.

Buy the handover conversation

If the previous developer is still contactable and on reasonable terms, an hour of their time written down is the cheapest thing you will ever buy. Not a formal document. A plain note covering how to run it, how it gets deployed, what was left unfinished, what is fragile, and what they would have done next.

Ask for it before the relationship ends rather than after. People are far more willing to help while they are still being paid, and a departing developer who leaves things tidy usually wants to.

Do not cut access on the first day

After a falling out the instinct is to revoke everything immediately. Resist it just long enough to be safe. Make sure your new developer has working access first, and that you know what each credential does before you change it, because somewhere in that list is the one that sends your invoices.

Then rotate properly. Every shared password and every key the previous developer knew should be changed once the new arrangement is running, and that includes the keys sitting inside the application's configuration. This is ordinary hygiene rather than an accusation, and a professional will expect it.

What a good new developer asks for

Watch what they want before they quote. Access to the code, a way to run it, sight of the hosting, and some time to read. Those requests are a good sign. So is being told that the first piece of work is understanding what is there.

Be wary of the opposite. A fixed price for a feature in a codebase nobody has opened is a guess, and the guess gets priced in somewhere: in padding, in a change request later, or in a shortcut that breaks something that was working. The same applies to an instant recommendation to rebuild from scratch, which is the most expensive advice in the industry and needs the strongest evidence behind it.

If some of it is already gone

Sometimes you come to this list and find you cannot reach the developer and several things are in their name. That is uncomfortable, and it is usually recoverable. Registrars have processes for proving a domain belongs to a business. Hosting providers do too. A site that is currently running can often be recovered from what is deployed, even without the original repository.

It costs time rather than being impossible, and knowing which parts you have lost is the first step either way.

The short version

Ownership of the domain, the hosting, the code and the connected accounts, all in your name and all reachable by you. The configuration and data that make the code run. A written note from whoever built it. Sort those while everyone is still speaking, and changing developer becomes an ordinary piece of admin rather than a recovery operation.