Taking Over a Website From Another Developer

Before you hire anyone to take over your website, secure four things: the domain registrar account, the hosting account, the code, and an owner-level CMS login. Without them no developer can help you, and any developer who says otherwise hasn't understood the problem yet. Everything else in a takeover is negotiable. These four are not.

This post is for the situation where the site exists, it's working or half-working, and the person who built it is unreachable, unresponsive, or simply someone you'd rather not work with again. If you're earlier than that — still choosing who to hire — how to compare web developer quotes is the better starting point.

The four things to secure before you hire anyone

1. The domain registrar account

This is the one that matters most, because it's the one that's hardest to recover and easiest to lose. Your domain is registered with a registrar — GoDaddy, Namecheap, a NZ registrar like Freeparking or 1st Domains, a Cyprus provider, or a reseller account owned by your developer.

Run a WHOIS lookup on your domain. It will show the registrar and, unless privacy protection is on, the registrant contact. The registrant should be your business, not your developer. If it isn't, that's the first thing to fix, and it's fixable — see the recovery section below.

2. Hosting or server access

Either a control panel login (cPanel, Plesk, a managed WordPress host) or a cloud account (AWS, Vercel, Netlify, DigitalOcean). What you want is the account owner login, not a user account someone created for you — an account owner can add and remove people, and a user cannot.

The fastest way to find out who's paying for hosting is your own bank statement. If hosting doesn't appear on it, someone else is paying for it, and that someone controls whether your site stays online.

3. The code

Repository access is what you want — GitHub, GitLab or Bitbucket, with your own account added as an owner or admin. A zip file emailed at handover is much weaker: it's a snapshot with no history, and version history is exactly what a new developer reads to understand why the code is the way it is.

If there's no repository at all, the files on the server are the code. That's recoverable, but it tells you something about how the site was built, and it belongs in the audit conversation below.

4. An owner-level CMS or admin login

Administrator, not editor. On WordPress that's the Administrator role; on a custom build it's whatever role can manage other users. The test is simple: log in and try to create another admin account. If you can't, you don't have owner-level access.

Locked out of your own website, or not sure which of these you actually hold? Tell me what you can and can't log into and I'll tell you what's recoverable, what isn't, and roughly what each path costs — free, before you commit to anything. Get in touch.

Why developers go quiet (it's usually not malice)

Worth saying plainly, because the internet's version of this story is always a villain. Most disappearances are mundane: the developer took a full-time job and let the side work lapse, the studio closed, the person who built it left the company, or the project ended on bad terms years ago and nobody expected to speak again.

The site keeps running regardless — that's the trap. A website with nobody maintaining it works fine right up until a certificate expires, a host migrates, or a dependency breaks. Then it stops, and only at that point does anyone discover the access problem. The best time to fix this is while everything still works.

What to do if you can't reach your current developer

In order, cheapest and most likely to work first:

• WHOIS the domain to identify the registrar. This tells you which company to talk to, which is more than most people in this situation start with.
• Attempt registrar account recovery directly with that registrar. If the domain is registered to your business, registrars have a documented process for proving ownership — typically company documents, an ID, and matching billing details. This works more often than people expect.
• Check your card and bank statements for hosting, domain and email charges. Whoever the payments go to is who holds that account, and a paying customer has leverage a third party doesn't.
• Try CMS password recovery to the email address on the admin account. If that email is your own domain and you control mail, you may already be able to get back in.
• Check whether your email is separate from your hosting. If your business email runs through the same provider, prioritise it — losing email is worse than losing the website.

What's genuinely unrecoverable: a domain registered in someone else's name at a registrar that won't transfer it, and code that only ever existed on a machine you can't access. Both have workarounds — a new domain, or a rebuild — but neither is a recovery, and a developer who implies otherwise is selling you something.

What a new developer needs before quoting a takeover

A takeover quote is different from a build quote, and you should be suspicious of anyone who prices one without looking at the code first. A new build is a known quantity — the developer decides how it's made. An inherited codebase is somebody else's decisions, and nobody can price the cost of understanding decisions they haven't read yet.

This is why most honest takeovers start with a paid audit rather than a fixed project price. The audit is small, bounded, and it produces the information a real quote needs:

• What the site is actually built on — platform, framework, versions, and how far behind they are
• Where it's hosted and what that costs
• Whether there's version control, and how much history survives
• What's broken now, and what's about to break
• Which dependencies have known vulnerabilities
• Whether the thing you actually want next is feasible on this codebase, or whether it fights it

A developer who quotes a firm fixed price on an unseen codebase is doing one of two things: padding heavily to cover the unknown, or about to be unpleasantly surprised. Both end up costing you.

What a takeover costs

These are market ranges from published price guides, not my quote — and takeover pricing varies more than new-build pricing precisely because the starting condition varies so much. Inherited code is normally priced above equivalent greenfield work, because someone has to read and understand another developer's decisions before safely changing any of them.

New Zealand (NZD)

Sources: Web Maniacs, Fuel Design and Lucid Media. Hourly work on an existing site is commonly billed at $50–$150/hr in NZ.

Cyprus (EUR)

Sources: Uveler and Bandziuk. For full build ranges rather than takeover costs, see what a website costs in Cyprus.

Red flags in the code you're inheriting

You don't need to read code to ask about these. Each one has a plain-English cost attached, and a new developer should be able to tell you which apply within a day of getting access.

• No version control. There's no history, so nobody can see why anything was done or safely undo a change. Every edit is riskier and therefore slower — this is the single biggest driver of "why is this so expensive to change?"
• Outdated dependencies. Old libraries with published vulnerabilities. The fix is usually mandatory and rarely quoted for, because upgrading one thing tends to break another.
• No staging environment. Changes get tested on the live site, in front of your customers. Setting up staging is cheap and it's the first thing worth paying for.
• Hardcoded credentials. Passwords and API keys written into the code itself. If the code has ever been shared, those credentials are effectively public and all of them need rotating.
• No backups. Nothing to restore from when something goes wrong. Verify that backups both exist and have been restored from at least once — an untested backup is a hope, not a backup.
• No documentation. Not fatal, but it converts directly into hours, because the new developer has to rediscover everything by reading.

When rebuilding beats recovering

Sometimes the honest answer is that the existing site isn't worth saving, and you should want a developer who'll tell you that even though a rebuild is the bigger invoice. The rough test: if the audit finds more than about half the red flags above, and you also want significant new functionality, a rebuild is usually cheaper within eighteen months.

The reverse is also true and less often said. If the site works, ranks, and just needs someone to look after it, a rebuild is an expensive way to solve a maintenance problem — and you'd be giving up accumulated search visibility to do it. If what you actually want is one new capability rather than a new site, what it costs to add features to an existing website covers that decision directly.

What to do differently with the next developer

This is the part that stops you being here again in three years:

• Register the domain yourself, in your business name, on an account you control, and put the renewal in a calendar.
• Get repository access on day one, not at handover. An owner seat on the repo from the start costs nothing and changes everything if the relationship ends.
• Pay for hosting on your own card, with the developer added as a user. Access follows the bill.
• Get ownership in writing before work starts — the code, the domain, the hosting, the design files, transferring on final payment. What a web developer contract should include covers the specific clauses.
• Ask for a documented handover: where things live, how to deploy, what breaks, who to call. A recorded screen-share is worth more than a PDF nobody reads.

Frequently asked questions

My web developer isn't responding. Can I get my website back?

Usually yes, at least in part. Start with a WHOIS lookup to identify your domain registrar, then go through that registrar's ownership-recovery process — if the domain is registered to your business, this is a documented procedure requiring proof of identity and company details. Check bank statements to find who's paying for hosting, and try CMS password recovery to an email address you control. What's genuinely unrecoverable is a domain registered in someone else's name at an uncooperative registrar, and code that never existed anywhere but their machine.

Who legally owns my website code?

It depends on your contract and on the law where each party is based, so treat this as background rather than a ruling — I'm a developer, not a lawyer, and anything significant is worth a proper legal opinion. In practice, ownership follows what the written agreement says. Where a contract is silent, many jurisdictions leave copyright in commissioned work with the person who created it, even though the client paid for it — which surprises people. That's precisely why an explicit assignment-on-final-payment clause matters more than assuming.

Should I rebuild instead of recovering a site I'm locked out of?

Sometimes, and a developer worth hiring will tell you so even though the rebuild is the larger invoice. If the domain sits in someone else's name at a registrar that won't transfer it, or the code only ever existed on a machine nobody can reach, recovery can cost more than starting clean — and you may need a different domain either way. Recover rather than rebuild when the site still ranks and access is the only missing piece. The general version of this decision is in should you fix your website or build a new one.

Can a developer work on a website someone else built?

Yes, and it's routine — but it should start with a paid audit rather than a fixed quote. An inherited codebase is another developer's decisions, and nobody can honestly price the work of understanding decisions they haven't read. Expect a small bounded audit first, then a real quote based on what it found.

What access do I need to give a new web developer?

Domain registrar, hosting or server, the code repository, and an owner-level CMS or admin account. Add them as a user on accounts you own rather than handing over your own credentials, so you can remove access later without changing every password. If any of the four doesn't exist or you can't produce it, say so up front — it changes the scope, and it's better discovered before the quote than after.

Where to start

Do the WHOIS lookup today. It takes a minute, it's free, and it tells you whether you have an inconvenience or a real problem — which determines everything else you do next.

If you'd like a second pair of eyes, send me what you have and what you're locked out of. I'll tell you honestly what's recoverable, whether the site is worth keeping, and what I'd do first — including if the answer is that you don't need to pay anyone yet. Get in touch, or see what I work on.