A physiotherapy clinic's booking site stops sending confirmation e-mails. The owner messages the freelancer who built it four years ago. Nothing. A week later a call goes to voicemail. Then a patient mentions that the site now shows a security warning in the browser, and nobody in the clinic knows where the site lives, who pays for it or how to log in.
That clinic is an illustration, but every part of it is common. Developers stop answering for ordinary reasons: they changed jobs, moved country, got ill, took on too much work, or fell out with the business over an invoice. Usually nobody planned it, and usually nobody wrote down where everything is. The result is always the same: a business pays for a system it cannot change, cannot move and, in the worst case, cannot keep online.
This piece is the order I work through when someone comes to me in this situation. It is written so you can start on it yourself today, before you talk to any new supplier. Most of it is paperwork and patience, not code.
Step 1: Find out what you actually own
Before you write to anyone, make a list of everything the system depends on and, for each item, whose name it is in. Often more is in the business's name than people expect, because the developer signed up with the company card or the company e-mail address.
Start with paper rather than passwords:
- **Invoices and bank statements.** Every recurring payment to a hosting company, a domain registrar, an e-mail provider, a booking or payments service, Apple or Google.
- **The original quote or contract.** It often lists what was to be delivered, and sometimes who owns it.
- **Old e-mails from the developer** with server names, logins or "here is your admin access".
- **Welcome e-mails from the services themselves.** Search your inbox for "welcome", "verify your e-mail" and "your account".
Look at which e-mail address each account was opened with. Password resets go to that address. If it is a business mailbox you control, you can often get in on your own today. If it is the developer's personal address, every reset goes to them.
And if a service is billed to your card, you are its paying customer. That gives you a real conversation with its support team, even when the login is in someone else's name.
Step 2: The domain comes first
Of everything on the list, the domain matters most. Your website, your e-mail and often the logins to other services all depend on it. If the domain expires or stays in the wrong hands, everything else you recover is worth much less.
To see where it is registered, use ICANN's own lookup at lookup.icann.org. Since 28 January 2025, a newer system called RDAP has been the official source of registration data for generic domains such as .com, .net and .org, in place of the old WHOIS service (ICANN announcement). The result shows the registrar, which is the company the domain is registered with, and the expiry date. It will often hide the owner's name and e-mail for privacy. That is normal, and the registrar is the part you need. Country domains such as .bg, .de or .co.uk are run by national registries, with their own lookup and their own rules, so check that registry's site.
Then one of three things is true:
- **You can get into the registrar account,** or reset its password because the account e-mail is yours. Do it now, turn on two-factor login, and check the expiry date and automatic renewal.
- **The domain is registered to your business, but the account belongs to the developer.** Ask the registrar's support how to prove who you are. Most have a process for this.
- **The domain is registered in the developer's own name.** On paper it looks like theirs, whatever you paid. That case needs the developer, or the steps further down.
Why you should not move the domain straight away
There is one rule to know before you change anything. Under ICANN's rules for generic domains, when the registered owner of a domain changes, the registrar must lock it against moving to another registrar for 60 days. Registrars may, but do not have to, let the owner opt out of that lock before the change is requested (ICANN: About Change of Registrant). ICANN has been reviewing its transfer rules, so ask your registrar what applies on the day.
In practice this means: first get the domain into your name where it already is, and only then think about moving it to a registrar you prefer. Trying to do both at once is how people end up waiting two months.
Step 3: Your e-mail hangs off the domain
Business e-mail is where people get caught next. If your addresses end in @yourbusiness.com, your mail is routed by settings on the domain called DNS records. Whoever controls those records controls where your mail goes. They also decide whether other mail servers trust the messages you send.
Find out who provides the mailboxes (Microsoft 365, Google Workspace or the hosting company) and whose name the administrator account is in. If you pay for it, the provider will have a way to prove that you own the domain and take over that account. Do this before anything else changes. A mistake in DNS can stop e-mail quietly, and you may not notice for a day.
Step 4: Hosting, where the system actually runs
Your site or app runs on a server somewhere. It might be with a hosting company, in a cloud account, or on a server the developer rents in their own name alongside other clients. The domain's DNS records show where it points, and anyone technical can read them in a minute. Match that against your invoices.
Again, three situations:
- **The hosting account is yours.** Log in, turn on two-factor login and download a full copy: files, the database and any uploaded documents. Once you have that copy, the worst case is off the table.
- **It is the developer's account, and you pay them for it.** Your system is sitting on their server. You need them, or a copy.
- **It is the developer's account and nobody pays for it any more.** This is the urgent one. The site can disappear when their account is closed, for reasons that have nothing to do with you.
In the last two cases, the priority is a copy of what exists. A simple brochure site can be partly rebuilt from its public pages. Anything with a database, such as bookings, customer accounts or records, needs the database itself, and that needs access.
Step 5: The code, and whether it is yours
The code may sit in a repository on GitHub, GitLab or Bitbucket under the developer's account. It may be only on the server, or only on the developer's laptop. A repository in their account can be transferred to an account you own, or shared with you, but only they can do it.
Who owns the code is a separate question from where it sits. Read the contract. Some agreements say the client owns the work once it is paid for. Others keep the rights with the developer and give the client a licence to use it. Some say nothing at all. If there was no written contract, the answer depends on the law where you are, and a short conversation with a lawyer is worth having before you assume anything. The point is not to start a fight. It is to know what you can reasonably ask for.
Step 6: Everything else with a password
Then the long tail. Each of these can stop a business for a day if it is lost:
- **App store accounts,** if you have a mobile app. An app published under the developer's own Apple or Google account can only be updated from that account until it is transferred to yours, and both sides have to take part in that transfer.
- **Payment, booking and invoicing services** that the system talks to, and the keys it uses to talk to them.
- **The e-mail sending service** behind confirmations and password resets.
- **Analytics, your Google Business Profile, advertising accounts and social pages.**
- **The security certificate** that gives the site its padlock. If it is not renewed automatically, it expires, and browsers start showing a warning, as the clinic found out.
For each one, write down whose name it is in, who can log in, and whether you can be added as an owner.
Step 7: Write to the developer once, properly
Most people send several short "are you there?" messages. One clear message works better, and it becomes your record if things go further.
Keep it calm and specific:
- **What you need, as a list:** the domain moved into the business's name, you added as owner of the hosting account, the repository transferred or shared, a database export, and the logins handed over in a password manager or a sealed document.
- **That you will settle any invoice that is genuinely due,** if there is one. Sometimes the silence is about money or embarrassment, and an easy way back helps.
- **A reasonable date** by which you need it.
Send it to every address and number you have, and keep a copy. Often this is enough. People drift away from projects; very few of them want to hold a client's business hostage.
- Do not change DNS records "to see what happens". It can take down your e-mail and your site at once.
- Do not cancel the old hosting or any subscription before you have a full copy, even if it looks as if you are paying for nothing. That payment may be the only thing keeping your site online.
- Do not let a new supplier start rebuilding on day one. First make sure someone has seen what exists.
- Do not argue about it in public. It rarely speeds anything up and makes the conversation harder.
- Do write down every date, message and phone call.
Step 8: When there is still no answer
If the date passes and nothing comes back:
- **Registrar and hosting support.** Explain the situation and ask what proof they accept: company registration documents, invoices showing you paid, the domain on your letterhead and listings. Policies differ, and some will not act without the registered owner, but this is the first door to knock on.
- **The contract.** If it says the work is yours, a formal letter is the next step, from a lawyer if it needs to be.
- **Formal disputes.** For domains there are formal dispute procedures, but they are designed for specific situations, such as someone registering your name in bad faith, and they take time and money. Take legal advice before choosing that route. While it runs, keep the system alive and keep everything you have.
Step 9: Once you have it back
Recovery is not finished the day you log in. Every password and key the developer knew should be changed. Do it as a planned change, because the system itself uses some of them, and changing them blindly can take it offline. Then:
- turn on two-factor login on every account
- put every account in the business's name, on a business e-mail address that is not one person's private inbox
- add a second owner from inside the business wherever the service allows it
- set the domain to renew automatically, and write the expiry date down somewhere other than the registrar's e-mails
- keep a current copy of the code and the database in a place you control
- write one page that lists all of it, where it is, and who to call
The whole thing on one page
- List every service from invoices, contracts and old e-mails, and note whose name each is in.
- Look up the domain at lookup.icann.org, or your country's registry. Note the registrar and the expiry date.
- Get into the registrar account, or start the registrar's process for proving ownership.
- Find the e-mail provider and recover its administrator account.
- Find where the system runs and whose account that is.
- Get a full copy: files, database and uploaded documents.
- Find the code, and read what the contract says about who owns it.
- List app store, payment, booking, e-mail sending and analytics accounts.
- Send one clear written request, with a list and a date.
- If the silence continues: registrar and hosting support, the contract, legal advice.
- Once you are back in: change passwords and keys carefully, turn on two-factor login, move everything into the business's name, add a second owner, write it all down.
Making sure it cannot happen again
None of this needs bad intentions to go wrong. It only needs everything to be in one person's name.
When I start a project, the accounts are opened in the client's name from the first day. The client is the owner and I am added as a user. If the work ever ends, the client removes me and nothing else changes. Ask any supplier, me included, to work that way. It costs nothing at the start and is very hard to fix later. What a proper handover should contain is covered in a separate piece.
What I do first
When someone brings me a system whose developer has gone quiet, I start with the list above, not with the code: what exists, whose name it is in, and what is at risk this week. Usually the first job is a full copy of everything and the domain safely in the business's name. Only then is it time to fix whatever broke. The technical checks I make before changing anything in someone else's system are written up in What I check before taking over an existing application.
Lost touch with the person who built your system?
Discuss your projectTell me what you have and what you can still log in to, and I will tell you where to start.