Your Developer Has Disappeared: Taking Back Your Website

It happens more often than anyone admits. The freelancer who built your site stops answering emails. The small agency you used closes, gets bought, or quietly moves on to bigger clients. The developer who looked after everything for fifteen years retires.

Nothing seems wrong at first. The site is still up and the enquiries still come in. Then you need a change made, or a renewal notice arrives for something you have never heard of, or a security fix like this month's PHP2Shell lands and there is nobody to apply it. That is when you find out how much of your website you actually control.

This post is a practical guide to taking it back. What to secure first, how to get hold of everything, how to judge what you have inherited, and how to decide whether to keep it or start again.

Do not panic, and do not touch anything yet

The instinct is to log in and start fixing things. Resist it. Until you know who controls what and have a copy of everything, a change on the live site can make things worse: a broken update with no backup, or a password reset that locks out the one account you needed.

Your first job is not to fix the site. It is to find out what you own, where it lives and who holds the keys.

Step one: secure the domain name

Your domain name decides where your website and your email go. Whoever controls it controls both, which makes it the most important thing to secure and the one most often in the wrong name.

• Find out where it is registered. A renewal email, an invoice or a WHOIS lookup will usually tell you which company holds it.
• Check whose name it is in. It should be your business, with an email address you control. It is very common to find it registered to the developer, or to an old member of staff's address.
• Check when it renews. A domain that expires because the renewal notice went to an inbox nobody reads can be lost entirely.

If the domain is in your developer's name, moving it needs their agreement. For .com and most other domains, the registrar issues an authorisation code to the owner, which is then given to the new registrar. For .uk domains, the move is done by changing the registrar tag, often called the IPS tag. Note that changing the owner's contact details can lock a .com domain against transfer for up to 60 days, so plan the order of changes.

If your old developer will not or cannot cooperate, the registrar has a dispute process. It is slower, so start early.

Step two: find the hosting and the DNS

Next, find out where the site actually runs and who pays for it.

• The hosting account. Is it in your name, on your card? Or does your developer resell hosting to you as part of a monthly fee? If it is theirs, the site can vanish when they stop paying.
• The DNS. This is the address book that points your domain at your server and your email provider. It may be with the domain registrar, the host, or a third service such as Cloudflare. Find out which, and get access.
• Email. Check where your email is hosted and that it is not tied to the same account as the website. Losing email is often more damaging than losing the site.

Step three: get a copy of everything

Once you know where things are, get your own copy before anything else changes.

• The code. Ideally from a code repository such as GitHub or Bitbucket, with its full history. If there is none, a copy of the files from the server is the fallback.
• The database. This holds your content, customers, orders or bookings. Without it, the code is an empty shell.
• Uploaded files. Images, documents and anything your customers have uploaded.
• Backups. Find out whether backups exist, where they are stored, who pays for them and when one was last restored to check it works.

Store all of this somewhere you control, not on the same server as the site.

Who owns the code?

This catches people out. In the UK, copyright in code usually belongs to the person who wrote it unless a written agreement says otherwise. Paying for a site does not automatically make the code yours. Most development contracts do hand it over, or give you a licence to use it, but check yours. If there is no contract, take advice from a solicitor before the relationship ends completely.

Step four: collect the credentials

Make a list of every account the site depends on, and make sure each one is in your business's name with access you control:

• Domain registrar, hosting and DNS accounts.
• The site's own admin logins, including one administrator account that belongs to you.
• Payment providers, such as Stripe or PayPal, connected to the site.
• Email sending services, used for contact forms and receipts.
• Third-party services with keys stored in the site: maps, analytics, CRM, accounting or booking integrations.
• Licences for paid plugins, themes or software, which may be registered to your developer's account.

Once you have them, change the passwords and remove access for anyone who no longer needs it. Do this carefully and one at a time, so you know which change broke something if anything does.

Step five: an honest audit

With access secured and a copy in hand, you can find out what you have actually inherited. A proper audit answers a short list of questions:

1. What does the site run on? The language, the version, the CMS or framework, and the server.
2. Is any of it out of support? PHP 8.1 and older, for example, got no fix for PHP2Shell. Old CMS versions such as Joomla 3 and Drupal 7 get no fixes at all.
3. Can it be updated? Some sites cannot move to a supported version without parts being rewritten first.
4. What state is the code in? Is it organised, consistent and understandable by another developer, or a tangle only its author could follow?
5. What does it do for your business? Pages, or also bookings, payments, member areas and connections to other systems?
6. Is it already compromised? Neglected sites are sometimes hacked quietly. Unknown admin users, odd files or spam pages in Google are warning signs.

The output should be a plain written summary: what is fine, what is risky, what needs fixing now, and what it would cost to keep going.

Keep and maintain, or rebuild on Laravel?

This is the decision the audit is for. Be wary of anyone who gives you an answer before they have looked. A developer who recommends a rebuild for every site they inherit is selling, not advising.

When keeping it is the right call

• It runs on supported software, or can be brought up to date without major surgery.
• The code is in reasonable shape, so another developer can work on it safely.
• It does what your business needs and you are not planning big changes.

In that case the sensible move is to tidy it up, update it, put it on proper hosting and have someone look after it from now on. That is usually the cheapest outcome, and often the right one.

When rebuilding makes more sense

• It is stuck on unsupported versions, and getting it current means rewriting large parts anyway.
• Nobody can change it safely. Every small request takes days and breaks something else.
• It depends on things you cannot replace, such as abandoned plugins or a bespoke framework only the original developer understood.
• It has grown into something your business relies on, and is held together with patches.

If that sounds familiar, rebuilding on Laravel gives you a site built on a widely used, well-documented framework with a published release schedule, so the next developer can pick it up without starting from scratch. Your content, URLs and search rankings come across, and the old site stays live until the new one is ready. We explain the move in moving from a legacy CMS to Laravel, and what a Laravel migration actually costs sets out realistic timings: a typical small business site takes four to eight weeks.

How to avoid this happening again

Whatever you decide, set things up so the next change of developer is an inconvenience, not a crisis:

• Everything in your name. Domain, hosting, DNS, code repository and every paid service.
• Code in a repository you own, with your developer given access to it, not the other way round.
• Written agreement on ownership, so the code is yours or licensed to you.
• Backups you can reach, stored off the server and tested.
• A short document listing what the site runs, where it lives and how it is deployed.
• More than one person who understands it. A support arrangement with a team, rather than a single individual, means holidays and retirements do not leave you stranded.

How we can help

At AugmentBLU we regularly take over websites and web apps from developers and agencies who have moved on. We help recover access, get a safe copy of everything, and give you a plain written audit of what you have. Then we tell you honestly whether to keep it, fix it or rebuild it on Laravel.

Once it is stable, our support and maintenance retainers keep it updated, monitored and backed up, with a team rather than one person responsible for it.

If your developer has gone quiet, get in touch. The sooner the domain and the backups are secured, the easier everything else becomes.

We reply within 24 hours.