Your developer left and you can't get into your website: what to do first

Taking over a website from another developer comes down to four moves. Find out who holds each account. Take a full backup. Get access in your own name through each provider's own recovery process. Then close the old access. Only after that should you decide whether to keep, fix or rebuild the site.

This applies to a freelancer or a company, whether they have gone quiet or moved on. Once access is back, ongoing development and support can take on sites and software we didn't build, after a short review. The rest of this page is what you can do yourself.

For a routine handover, inventory before changing settings

In a routine handover, the pull is to act: reset everything, move the site, cancel payments you don't recognise. Each can make things worse. A yearly charge a bakery owner doesn't recognise may be the hosting behind their ordering page.

For now, only look and write things down. Hold off on these until you have a list and a backup:

• Changing DNS records or nameservers. A wrong value takes the site and email offline.
• Updating the platform, plugins or themes. An update can break a site nobody understands.
• Deleting old user accounts. First see who has access.
• Cancelling subscriptions. Hosting, the domain and licences often renew quietly from a forgotten card.

List what exists and who holds it

A website is a handful of accounts, and your developer may have opened each under their own email address. Fill in a name and an email for each row, and mark the ones you can't answer.

The lookup rarely names the owner, because contact details are often redacted, but it shows the registrar, name servers, dates and status. Country domains such as .in may have their own registry lookup; IANA's root zone database points to each.

Take a backup first

A backup is a full copy of the site: its files, its database where there is one, and the content in it. It is your way back if a later step goes wrong. In a routine handover, take it before you reset a password or change a setting, and keep a copy outside the hosting account.

The hosting control panel usually has a backup or download option. A content export from the site's admin helps but is not enough. On WordPress, Tools, then Export makes a file of posts, pages and comments, not a copy of the whole site. If you can reach neither yet, ask the host what copies they hold.

Open the backup once you have it: a copy that won't open, or is empty, is not a backup. Opening it shows the files are there. Only a test restore to a separate copy of the site proves it works, so ask whoever reviews the site to do one.

Recover access account by account

Each provider has its own way to prove you are the right person. Use it, in this order, because each step often depends on the one before.

1. Get into your own email firstReset links go to an email address, so make sure it is one you control, not the developer's mailbox.
2. Find the registrar and recover that accountUse the registrar's own password reset, and if the account is in the developer's name, ask the registrar what it needs to verify you.
3. Check the DNS and take a written copyCopy every record as text or a screenshot so any later move can be undone.
4. Recover the hosting accountUse the host's reset, or contact the host with the invoices that show you pay for it.
5. Recover the site's adminTry the site's own "lost password" link first, then ask the host or a developer about the next option.
6. Move the rest to your nameSearch Console, analytics, forms, payments and any paid licences.

On WordPress, "Lost your password?" emails a reset to the address on the account. WordPress's own guide lists other routes, including the database. Most need hosting access and care, so they are a developer's job if you haven't done them before.

On Shopify, only the store owner can transfer ownership, and Shopify sends its messages to the owner's email address. If that address isn't yours, ask the store owner for a transfer or contact Shopify Support. Do not try to recover someone else's mailbox.

For the domain, the registrar deals with the registrant, the person or company listed as its holder. If your developer registered it in their own name, the cleanest route is a polite written request that they transfer it or change the registrant. Moving a domain between registrars needs an authorisation code. ICANN's guide for registrants says registrars must give it to the holder and provide a way to remove a transfer lock. Who the holder is can turn on your contract and local law. This is general information, not legal advice, and we can't promise access will be recovered. For the ownership question itself, see who owns your website.

Close the old access

Once the new logins work and the backup is safe, take the old access away. This is housekeeping, not an accusation: a former developer's login stays a way in until you close it. If the developer is still in touch, tell them first.

As a benchmark, a handover leaves the code in your account and the hosting, domain and tools in your name. Credentials go in a shared vault, with a written guide. That is what How we work sets out for our own projects. Gaps between that and your list are the gaps to close.

Keep, fix or rebuild: what a review looks at

With access and a backup in hand, a review says whether the site is sound, fixable or better rebuilt. It looks at six things.

Ask for the review in writing, with each area marked fine or needing work. A rebuild is not the default. It makes sense when the platform is unsupported, nobody you can hire can work with the code, or fixing it is more work than starting again. Whoever looks after the site next, agree in writing what is covered: what website maintenance should include sets out what to ask for.

Next step: fill in the table above with whatever you know, then tell us what you have. We'll say what we'd look at first, and whether the site is something to keep, fix or rebuild.

Reviewed and edited by Online Scope before publishing. Something out of date? Tell us at info@onlinescope.in. How we write the Blog.