Guide · When things go wrong
Our developer has left. What do we do now?
The first week after your only developer or IT person leaves: access, code, hosting and who to call, in the order we'd do it.
It happens more than you'd think.
The developer who built your system, or the one IT person who knew where everything was, hands in their notice. Or worse, they just stop answering. Suddenly nobody knows how the website is hosted, where the code lives or what that monthly charge from a company you've never heard of is for.
Don't panic, and don't rush to hire a replacement this week. The first job isn't finding someone new. It's making sure you own and control your own systems. Most handovers go wrong because the business can't prove it owns them. Here's the order we'd do it in.
Is this friendly or not?
Most departures are perfectly amicable, and a good developer will help with a handover. Ask them for one, in writing, and give them a list (the checklist below is a good start). Offer to pay for their time if they've already gone. A few days of a cooperative former developer is worth more than weeks of someone else digging.
If it isn't friendly, or you can't reach them, move faster on the access steps and slower on everything else. Don't delete anything, don't change hosting, and don't let anyone "tidy up" until you know what's running.
The first-week checklist
Work through these roughly in this order. For each one, the question is the same: whose name is on the account, who can log in, and is it you?
1. Domain names
- Find out where each domain is registered. A "whois" lookup gives you the registrar. In the UK, .co.uk and .uk domains are run by Nominet, and you can check who the registered owner is.
- Make sure the registrant is your company, not the developer personally. If it isn't, sort it now while things are calm.
- Get the registrar login into your own hands, change the password and turn on two-factor login.
- Check the renewal date and that the card on file is one you control. Plenty of businesses have lost their website and email because a domain failed to renew on a card that had been cancelled.
2. DNS
- Find out where DNS is managed. It's often not the registrar: it might be Cloudflare, your hosting company or AWS.
- Get that login too, and export or screenshot every record. DNS controls where your website and email go, so whoever holds it holds the keys.
3. Hosting and cloud accounts
- List every hosting provider and cloud account: AWS, Azure, Google Cloud, DigitalOcean, a web host, a server in a data centre. Your bank statements and the developer's email inbox are good places to look.
- For each one, get the top-level ("root" or "owner") login, not just a user account. Change the password, turn on two-factor login and remove the developer's personal access and keys.
- On AWS in particular, check for access keys belonging to the developer's user, see when each was last used, and deactivate them rather than deleting them straight away. That's AWS's own advice: if something breaks, you can switch the key back on while you move it to a new one, then delete the old key.
4. The code
- Find out where the code lives: GitHub, GitLab, Bitbucket, or only on the developer's laptop and the live server.
- Make sure the repository is owned by a company account, not their personal one. If it's personal, ask them to transfer it. If they won't, take a full copy of the code from the live server as a fallback.
- Check whether the live server is running the same code as the repository. It often isn't, because someone made a "quick fix" directly on the server.
5. SSL certificates
- Note when each website's certificate expires (your browser shows this if you click the padlock). Most now renew automatically, but only if the automation keeps running. An expired certificate puts a big red warning in front of every visitor.
6. Email and accounts
- Close or convert the leaver's own email account, and forward it to someone for a few months. Supplier renewals and password reset emails will keep arriving there.
- Check they aren't an administrator in Microsoft 365 or Google Workspace. If they are, remove them and make sure at least two people in the business have admin access.
- Go through the shared password manager, if you have one, and change anything they had access to.
7. Payment and third-party keys
- If your systems take payments, log in to Stripe, PayPal, GoCardless or similar and check who has access. Rotate the API keys (the secret codes your website uses to talk to them), but only once you know where they're used, or payments will stop.
- Do the same for anything else your systems connect to: email sending services, SMS, mapping, accounting integrations.
8. Backups
- Take a fresh backup of everything (code, databases, uploaded files) into an account the business controls, before anyone changes anything.
- Find out what backups were already running, where they go and whether they work. Our guide on testing your backups walks through it.
Find out what's actually running
Once you control the accounts, write down what you've got. A simple document is fine: each system, what it does, where it's hosted, what it costs a month, what it connects to, and where the passwords are kept. You'll almost certainly find a server nobody uses, a subscription you can cancel, and something important that's badly out of date.
Then, and only then, find someone
With access secured and a written list of what you've got, handing over to a new developer, an agency or an outsourced team is a normal job. Without them, the new person spends their first month as a detective, at your expense.
When you're choosing, ask how they'll document things so this doesn't happen again, and make it a condition that every account is in the company's name.
Start with the domain and DNS today
They're the two that can take your website and email offline, and they're usually the quickest to sort. Then work down the list.
When one person leaving can put the website, email and systems at risk, that's the real problem, and it'll happen again with whoever replaces them. The fix isn't just a new developer. It's making sure the business, not an individual, owns its technology. Have a look at the signs you've outgrown your IT setup.
Taking over from a developer who's moved on is one of the most common reasons people ring us. We read the code, tell you in writing what you've got, and then look after it month to month: that's our software support and maintenance. That's our pitch, so add a pinch of salt. Whoever you use, insist on the accounts being yours.
Common questions
Under UK law, a freelancer or agency owns the copyright in code they write unless the contract assigns it to you. Employees' work normally belongs to the employer. If you are unsure, check the contract and ask for a written assignment. This is general information, not legal advice.
Start with what you can prove you own: domain registrars, hosting providers and cloud platforms all have account recovery processes for the business that pays the bills. Keep invoices and company documents to hand. If the contract is in dispute, take legal advice.
Every login and who owns it, where the code is and how to deploy it, the hosting and DNS setup, any third-party services and their keys, how backups work, and a list of known problems.
Keep every account in the company name with at least two people able to log in, use a shared password manager, and ask for short written notes on every system as it is built.
Yes. It is one of the most common reasons people ring us. We start by reading the code, since there usually isn't documentation, and tell you in writing what you've got. See our software support and maintenance page.
Developer gone? Talk to us
Tell us what they built and what you can still get into, and we'll tell you where to start.
Even if you just want a second pair of eyes on the checklist, give us a call.
What we will cover:
- What to lock down first
- How to get the code and accounts into your name
- What we'd look at in the code
- Who should look after it next
Rather talk now? Book a call or ring 01474 639 089.
We reply within one working day.
