Developer left? Getting back into your server

It happens more than you would think. A freelancer moves on, an agency closes, or the one person who "did the IT" leaves. The website still works, so nobody worries. Then something breaks, or a renewal email arrives, and it turns out nobody knows the passwords.

The good news: if you are the one paying for it, you can almost always prove it is yours and get back in. Here is the order to do it in.

1. Work out what you actually have

Before you chase logins, make a list. Most small business setups have the same four parts:

The domain name, such as yourbusiness.co.uk, bought from a registrar (the company you pay for the name).
DNS, the settings that point the domain at your website and email. Often at the registrar, sometimes somewhere else, such as Cloudflare.
Hosting, where the website or app actually runs. A hosting company, or a cloud account such as AWS.
Email, often Microsoft 365 or Google Workspace.

Look through old invoices, bank statements and card payments. Each regular payment is a clue to where something lives.

2. Get the hosting account back

Contact the hosting company, not the developer, first. Explain that you are the business that owns the account and that the person who set it up has left. They will ask you to prove it, usually with invoices, the card that pays, or company documents.

If you are on AWS, the main login for the whole account is called the root user. You can reset its password from the email address the account was opened with. If two-step login was turned on and the phone has gone with the developer, AWS can verify you using the account's email address and phone number instead, and AWS Support can help if you have neither. This is why the email address on the account should always be one the business owns, not a personal one.

3. Get into the server itself

Getting into the hosting account is not the same as getting into the server. The server usually has its own logins, often SSH keys (the digital keys used to log in) that only the developer had.

If the server is on AWS, there are official ways back in without the developer's key:

Session Manager or EC2 Instance Connect, if they were set up. These let you log in from the AWS console without a key at all.
AWS's reset access tool (an automated runbook called AWSSupport-ResetAccess), which puts a new key on the server for you.
The manual method: stop the server, attach its disk to a temporary helper server, add your own key, then put the disk back.

Before any of these, take a snapshot (a full backup copy of the server's disk). If something goes wrong, you can go back. Other hosting companies have their own rescue or console options: ask their support team.

4. Secure the domain name

The domain is the most important thing you own online. If it lapses or is taken, your website and email go with it.

First, find out whose name the domain is registered in. Your registrar can tell you, or you can check a public lookup. If it is in the business's name, you just need to get back into the registrar account, the same way as the hosting.

If it is in the developer's own name, it legally belongs to them until it is moved. For .uk domains, this is a "registrant transfer" through Nominet, the .uk registry. It costs £10 plus VAT, and the new owner has five days to accept it. The developer, or their registrar, has to start it.

If they won't co-operate, Nominet's Dispute Resolution Service can decide who the domain should belong to. Mediation is free. A full expert decision costs more, so it is worth asking nicely first.

For .com and other generic domains, the registrar has to give you the transfer code within five days of asking. After a change of owner, the domain usually can't move to a new registrar for 60 days, so do the ownership change first and the move later.

5. Change everything, then write it down

Once you are back in:

Remove the old developer's accounts and SSH keys from the server, the hosting account and anything else they could log in to.
Change every password and API key (the keys software uses to talk to other services) they might have known.
Turn on two-step login for the hosting account, the registrar and email.
Put every login in a password manager that the business controls, not one person.
Write a one-page summary: what you have, where it is, who to call.

Where the logins usually hide

If you have access to the developer's old work, these are worth checking before you start resetting things:

Handover emails, invoices and project documents.
The website's configuration files (often called .env), which usually hold database passwords and API keys.
The code repository, if you have access: secrets often end up in its history.
Automated deployment settings, such as GitHub Actions or Bitbucket Pipelines.
A shared password manager or spreadsheet.
Hosting, domain and DNS accounts opened in the developer's own name, often still paid for by the business.
The developer's agency, if they worked for one: they may still have records.

When to call someone

Call for help if:

The hosting company or registrar won't accept your proof of ownership.
You are in, but you don't know what is running or whether it is safe.
The server runs an old system that no longer gets security updates.
You suspect the old developer, or someone else, still has access.

A server health check is designed for exactly this. I review what you have, who can get in, and what needs fixing first, and you get a plain-English report you can keep.

My developer left and nobody can access the server