Lost Access to Your Server, Domain or Code After the Developer Left: A Recovery Guide

You have lost access to your website after the developer left, and three separate systems, the domain registrar, the hosting account and the code repository, might each be locked behind a login that only one person ever had. This happens more often than most business owners expect, usually a few weeks after a freelancer stops answering emails or an agency quietly closes down. Some of these accounts can be recovered without the developer at all. The harder cases need either their cooperation or a different kind of pressure, and a few need a lawyer.

What you can usually get back without the developer

Four systems commonly get locked behind one person's login, and three of them have a recovery path that does not depend on that person.

The domain registrar is usually the easiest. Every registrar, GoDaddy, Namecheap, IONOS, requires proof that you are the business or person on file as the owner, not the person who registered the domain on your behalf. If an invoice, a business registration or an ID matches the account holder's details, support can usually transfer access or reset the login within a few days. The slow part is rarely the registrar. It is finding the original invoice.

Hosting access depends on who the contract is with. If the account is in your company's name, even if the developer set it up, you contact the provider directly, prove ownership of the billing relationship, and request a password reset or a new admin user. If the contract and billing sit in the developer's own name, this stops being a recovery and becomes a negotiation, which is covered further down.

Git hosting, GitHub, GitLab, Bitbucket, follows the same pattern as hosting. If your company owns the organisation account on the platform, someone on your team who still has owner rights can remove the departed developer and keep full access. If the developer personally owns the organisation, or the repository lives under their personal account, you are back to needing their cooperation.

App store accounts, the Apple Developer Program and the Google Play Console, are usually the hardest of the four. Both platforms tie ownership closely to the entity that originally registered, and identity verification can take weeks either way. If the account was registered under your company's own business details, Apple and Google support can generally work with you directly. If it was registered under the developer's personal account, expect the slowest recovery of the group, sometimes a full resubmission under a new account.

What actually needs the developer

A few things rarely exist anywhere except on the departed developer's own machine: API keys for third party services that were never written down anywhere, SSH keys that grant direct access to the production server, two factor authentication tied to their personal phone, and any code that was finished but never pushed to the shared repository. If none of this was documented or backed up elsewhere, there is no workaround. You need either the files themselves or the cooperation of the person holding them.

Getting a non-responsive developer to cooperate

Before assuming the worst, check whether the silence has an ordinary explanation. People change numbers, ignore unknown senders, or genuinely believe the handover already happened on their end. Send one clear, written request by email: list exactly what you need (the access or the files, by name), reference the contract or statement of work, and give a specific date.

If that gets no response, widen the channels. Try the email the invoices came from, any messaging app you used during the project, and a phone call if you have the number. Keep the tone professional rather than accusatory. Mention that the request is for the return of company property under the agreement you both signed, and that you would rather resolve this directly than involve anyone else.

Leverage usually runs in both directions. If a final invoice is still unpaid, that is something to settle at the same time as the handover, not before it, since paying first removes your only point of pressure. If money is owed to the developer and they are withholding access until it is paid, get that agreement in writing before you send anything, so there is no dispute afterward about what was promised.

When to bring in a lawyer

A few situations are worth a short consultation with a lawyer rather than more emails. If a developer explicitly asks for payment in exchange for access they are contractually obligated to hand over anyway, that looks like extortion in most jurisdictions, and a lawyer's letter often moves things faster than another message from you. If customer data or personal information is involved and you cannot confirm it is secure, that is a compliance question as much as an access question. If the original contract is unclear about who owns the code and the intellectual property, that ambiguity is worth resolving properly rather than guessing. None of this is legal advice, and the right answer depends on your contract and your jurisdiction, so treat a lawyer's read on your specific situation as the actual answer, not anything in this guide.

Rebuilding a working codebase from what is running in production

If the repository truly cannot be recovered, and no clean export exists anywhere, there is still a path forward as long as you can reach the live server. Pull the files directly off production over SFTP or SSH, export the database separately, and keep the two together. This gives you a snapshot of the application exactly as it runs today, even without the commit history that would normally come with a proper repository.

From that snapshot, a developer can initialise a fresh Git repository, commit the current state as a starting point, and get the application back under proper version control. It will not have the years of history the original developer built up, but it will be a working, deployable copy that a new team can build on immediately. Treat this reconstructed codebase as unaudited until someone checks it. A former developer's code, especially one who left under bad terms, can carry outdated dependencies, hardcoded credentials, or shortcuts nobody signed off on, and a code quality audit before you build further on top of it is worth the time.

This kind of recovery, turning a production server into a maintainable codebase again, is the same work involved in taking over any inherited system, and it overlaps heavily with legacy code modernization: understanding what is actually running, documenting it properly, and making it safe to change.

Preventing this from happening again

The cheapest fix is structural, not legal. Register every domain, hosting account and Git organisation under your company's own details, with your company email as the primary contact, even when a contractor sets it up. Add a second admin to anything important the moment it is created, not after someone leaves. Keep one document listing every account, who has access, and where the credentials live.

If you are already past the point of prevention and dealing with a departure right now, the first 14 days after a developer quits covers the immediate triage, who actually owns your code and accounts covers the contract side of this same problem, and a knowledge transfer template is worth using with the next person before they ever become the only one who knows how things work.

If you are stuck mid-recovery and want a second opinion on what is salvageable, write to hello@wolf-tech.io or have a look at wolf-tech.io. Most of these situations look worse from the outside than they turn out to be once someone actually gets into the server.