Your Web Developer Disappeared? What to do next?

If your developer has gone quiet and you cannot get into your own website, the first thing to establish is not who owns the website. It is who controls the domain. A domain can be recovered through the registry or through a formal dispute even when the relationship has broken down completely. A hosting account can usually be reproduced. Website files can be rebuilt. A domain that ends up in someone else’s name, on a registrar you cannot reach, with an expiry date you cannot see, is the one failure that costs you years of search visibility and every email address in the business.

This is a more common situation than most business owners expect. We inherit websites every week, and a meaningful share of them arrive without a single credential. Sometimes the previous developer has closed down, emigrated, died, or simply moved on to a job where nobody is chasing old clients. Sometimes there is a fee dispute and access has been withheld deliberately. Sometimes the developer is perfectly willing to help but genuinely cannot, because the website was built on a reseller account that was cancelled two years ago.

The emotional read is usually that somebody is holding your website hostage. Occasionally that is true. More often the picture is messier, and the practical question is the same either way: what do you actually control, what can you take back, and in what order.

The four assets you think are one asset

Almost every recovery problem starts with a category error. Business owners say “my website” and mean one thing. In reality there are at least four separate assets, held in four separate places, each with its own owner, its own login and its own recovery route.

The domain. Registered through a registrar, recorded at the registry. For .co.za, that registry is the ZA Central Registry, operating under the .za Domain Name Authority. The domain has a registrant, which is the legal holder, plus administrative, billing and technical contacts. Whoever controls the email address on those contact records effectively controls the domain.

The hosting. A server account, usually cPanel, held by whoever opened it and pays for it. The hosting account contains the website files and the database, and often the mailboxes too.

The website itself. The WordPress installation, the theme, the plugins, the page layouts, the images and the copy. This is the part everyone argues about and, ironically, the part that matters least in a recovery, because a modern WordPress website is mostly licensed third-party code wrapped around content you supplied.

Everything hanging off it. Email, the Google Business Profile, Google Ads, Meta Business Manager, Google Analytics, Search Console, the payment gateway, the SSL, the DNS. These are separate accounts with separate owners, and in a bad handover they are where the real damage sits.

Recover them in order of consequence. Domain first. Email second, because it usually rides on the domain. Hosting third. The website files last, because by then you may not need them.

Step one: find out what you actually control

Before you contact anyone, establish the facts. You can do most of this yourself in twenty minutes.

Run a WHOIS lookup on your domain. For .co.za domains, the registry publishes registrant and contact information subject to privacy rules, and your registrar can tell you the rest. What you are looking for is three things: which registrar the domain sits with, whose name is on the registrant record, and which email address the registry will contact. Then check the expiry date, because an abandoned domain with an unpaid renewal is a much shorter fuse than a disputed one.

Next, check where the domain points. The nameservers tell you which DNS provider is authoritative. The MX records tell you where your email is being delivered. It is quite common to find a domain registered with one company, DNS hosted at a second, the website on a third, and email running through Microsoft 365 or Google Workspace billed to the developer’s own account.

Then look for proof of payment. Whose bank account has been paying the annual domain renewal and the monthly hosting? If the invoices came to your business and you paid them, you have documentary evidence that matters later, both with providers and, if it comes to it, with an adjudicator.

Finally, check your own inbox history. Registry notifications, registrar renewal reminders and hosting welcome emails often went to an address in your business at some point, even if nobody recognised what they were at the time. A five-year-old email containing a client area login is worth more than any amount of argument.

Step two: the domain

There are three scenarios, and they need very different responses.

Scenario one: you are the registrant and you can receive the registry emails

This is the good outcome and it is more common than people fear. A .co.za transfer does not work the way a .com transfer does. There is no authorisation code to extract from your current provider. Your new registrar initiates the transfer, and the registry emails a voting request to every contact on the domain: registrant, administrative, billing and technical.

Understand how that vote resolves, because it is the opposite of what most people assume. An approval from the registrant moves the domain immediately. A denial stops it. And if nobody votes at all, the transfer fails at the end of the five-day window rather than going through by default. Silence is not consent here. If the only address that can vote belongs to somebody who has stopped answering email, an unattended transfer request simply expires.

So if the contact email reaches you, act on it. You can move the domain to a registrar you control without the outgoing developer’s cooperation. Note that a domain registered or transferred in the last 60 days is locked and cannot move yet, which occasionally matters on a very new website.

Do this first, before you tell anyone you are unhappy. Not out of bad faith, but because a domain sitting on a registrar account you do not control is an unnecessary risk while a relationship is deteriorating.

Scenario two: the contact email is the developer’s, but the registrant is your business

Here you have a paperwork problem rather than an ownership problem. Approach the registrar directly with proof: your CIPC registration documents, proof that the registrant name matches your entity, invoices showing you paid for the domain, and a formal written request to update the contact records. Registrars deal with this regularly and most have a documented process. It is slower than a self-service transfer and it usually requires certified documents, but it works.

If the registrar is unresponsive, escalate to the registry. The registry will not simply hand you a domain on request, but a well-documented complaint from the named registrant carries weight that an angry email does not.

There is one published position here worth quoting to anyone who tells you your domain is being held until an invoice is settled. The ZA registry states plainly in its own registrant guidance that its policies do not allow a registrar to lock in a registrant over a contractual dispute by denying or ignoring a transfer request, and that any contractual dispute must be taken to a court with jurisdiction. A billing argument is not a lawful basis for refusing to release a domain. That does not make the money owed disappear, and if you owe it you should pay it, but the two are separate matters and the registry treats them that way.

Scenario three: the domain is registered in the developer’s name

This is the difficult one, and it is not rare. Many small developers registered client domains in their own name as a matter of convenience years ago, without any intention of ever using it as leverage. The intention does not change your position.

Start with the commercial route. A written request, a deadline, and a clear statement that you are the beneficial owner and have paid every renewal resolves a surprising number of these. Keep it factual and keep it in writing.

If that fails, South Africa has a formal route that most business owners do not know exists. The Alternative Dispute Resolution Regulations, made under the Electronic Communications and Transactions Act, allow a complainant to challenge a .co.za registration on the basis that it is an abusive registration, meaning it was registered or used in a way that takes unfair advantage of, or is unfairly detrimental to, the complainant’s rights. Those rights include trade mark rights, whether registered or established at common law through trading under the name.

Disputes are handled by accredited providers, the best known being the South African Institute of Intellectual Property Law, with the Arbitration Foundation of Southern Africa also accredited. ZADNA’s published fee structure for adjudication is R10,000 for a single adjudicator and R24,000 for a three-adjudicator panel, and the process includes a mediation stage before adjudication. SAIIPL indicates that a case filed with it is normally concluded within about two months, run on documents without in-person hearings. Where a decision orders transfer, the registry implements it after a short window unless the decision is appealed.

The relevant precedent is encouraging for businesses in this position. Adjudicators have ordered transfer where a domain was registered by someone whose role in relation to the complainant, an employee or service provider, meant the registration was made in the course of serving the complainant rather than for the registrant’s own benefit. Registering a client’s business name as a domain, in your own name, while being paid to build that client a website, is not a strong position to defend.

ZADNA also runs an ADR financial assistance programme for complainants who cannot afford the adjudicator’s fees, assessed per application against published eligibility criteria. If the cost is the only thing standing between you and a legitimate claim, that is worth an enquiry before you write the domain off.

The honest caveat: R10,000 and two months is cheap next to litigation and expensive next to a domain renewal. Weigh it against the cost of losing the domain. For an established business whose name is the domain, whose email runs on it, and whose search rankings sit on it, the sum is usually not close.

Step three: email, before anything else breaks

Email is where recovery situations turn from frustrating into damaging, and it is routinely overlooked while everyone argues about the website.

If your mailboxes are hosted on the same cPanel account as the website, and that account gets suspended for non-payment or cancelled by an irritated developer, your business loses live mail and historic mail at the same time. If your mail runs on Microsoft 365 or Google Workspace under the developer’s billing account, they can remove your licences. If the MX records live on DNS you do not control, someone else can redirect your mail entirely.

Practical sequence: export or back up existing mailboxes locally now, today, before any confrontation. Most mail clients will do this. Then plan to move mail to a tenancy in your own name, billed to your own card, as soon as you control the DNS. Mail migration is disruptive and nobody enjoys it, but it is far less disruptive than discovering on a Tuesday morning that eleven years of correspondence has gone.

Step four: hosting and the files

Hosting accounts are held by whoever opened them. If the account is in your business name and billed to you, the provider will verify your identity and restore access. If it is in the developer’s name, or inside a reseller account the developer resells from, the provider will not give you access to another party’s account, and they are right not to.

What you can usually achieve, even in a reseller situation, is a copy. Providers are generally willing to assist a verified end client with a backup of the data associated with their own domain, particularly where the reseller is unresponsive and there is documented payment. Ask for a full cPanel backup, which gives you the files, the database, the email and the DNS zone in one archive. That single file is the difference between a migration and a rebuild.

If the hosting is unrecoverable and there is no backup anywhere, you are not finished. A live website is public. Every page, every image and most of the structure can be recovered from the live website and from archive services. Content recovery is tedious and unglamorous, but it is possible. A database with ten years of WooCommerce orders in it is the genuinely painful loss, which is why the backup request comes first.

Step five: who actually owns the website

This is where most advice on the internet is wrong, and where South African law differs from what people assume.

Paying for something does not automatically make you the copyright owner of it. Under the Copyright Act 98 of 1978, copyright vests in the author, and for a computer program the Act defines the author as the person who exercised control over the making of the program rather than the person who typed it. The Supreme Court of Appeal applied that control test in Haupt t/a Soft Copy v Brewers Marketing Intelligence (Pty) Ltd 2006 (4) SA 458 (SCA), which remains the reference point in South African software authorship disputes.

The interesting part of that judgment is that it cuts in both directions. The court held that control has a wider meaning than the ordinary employment sense, and that a person can be the author of a program even where the actual creator was an independent contractor, because he could direct the development at any time, could stop it, and was in a position of authority over the work. You do not have to be a programmer to control the writing of a program.

So a client who genuinely directed the build, set the requirements, reviewed and approved the work at each stage and could have halted it, has a considerably stronger authorship argument than a client who paid a deposit and waited for a link. That is worth knowing before anyone concedes the point, and it is also a reason to keep your project correspondence.

There is a commissioned-works exception in section 21, but it is limited to specific categories such as photographs, portraits, engravings, films and sound recordings. A website build does not fall into it. And any assignment of copyright has to be in writing and signed by the assignor to be effective. A line in a quotation saying “full ownership on final payment” that nobody signed is not an assignment.

So the uncomfortable answer is that a business can pay R40,000 for a website and not own the copyright in the code that was written for it. Before that ruins your week, three practical points.

Your content is yours. The copy, the photographs you supplied or commissioned, the logo, the product data, the customer database. Those are separate works with separate ownership, and they are the part with commercial value.

Most of a WordPress website is not the developer’s to own anyway. WordPress core, the theme and the plugins are licensed to you. What the developer created is the configuration, the layout work and perhaps some custom code. It is worth less than the argument about it costs.

Nobody wins a copyright fight over a five-year-old website. In practice these matters are resolved commercially or not at all. A developer who claims copyright in the website while refusing to hand over a backup is making a legal point that does not get them paid and does not stop you rebuilding.

The lesson to take forward is the one about paperwork, not the one about litigation. Get the assignment in writing on the next build.

Step six: the accounts nobody remembers until they are gone

The peripheral accounts are often where the most recoverable value sits, and they each have their own route.

Google Business Profile. If the developer is the owner and is unresponsive, Google runs a request-access process: you submit a claim, the current owner gets a window to respond, and if they do not, you may be able to take over the profile. This is worth starting early because the clock runs in the background while you deal with everything else.

Google Ads and Meta. If the ad accounts were built inside the developer’s manager account, the accounts themselves may not be transferable, but the historic data can usually be exported and the campaigns rebuilt. The bigger risk is billing details sitting on someone else’s card, or conversion tracking that stops firing the moment the website changes.

Analytics and Search Console. Both are recoverable through domain verification once you control the DNS. That is another reason the domain comes first: DNS control is the master key to most of the verification-based accounts.

Payment gateway. If you are running WooCommerce, confirm whose merchant account the gateway credentials belong to. Money flowing through an integration configured by someone you can no longer reach is a problem worth solving before it becomes an accounting one.

When the domain is genuinely gone

Occasionally a recovery fails. The domain lapsed and was picked up by a squatter, or the dispute was not worth running, and you have to move to a new domain.

This is a real loss and it should be treated seriously rather than glossed over. You lose the accumulated authority attached to that domain, every backlink pointing at it, and the address printed on your vehicles. What you can do is limit the damage: choose the closest sensible alternative, rebuild the same page structure so old paths map cleanly, put redirects in place if you ever regain even temporary control of the old domain, update your Google Business Profile and every directory listing that carries the old address, and tell your customer base directly rather than hoping they notice.

Expect a visibility dip and plan for six to twelve months of rebuilding. It is survivable. It is also entirely avoidable, which is the point of everything below.

Preventing it on the next build

None of this is complicated to prevent. It is only ever prevented in advance.

Register the domain in your own name, on an email address inside your business. Not the marketing manager’s personal Gmail. Not your developer’s address. A role address such as accounts or admin at your own domain, which survives staff changes.

Hold the hosting account yourself, or know exactly whose account it is. There is nothing wrong with an agency managing hosting, and there are good reasons to let them. There is everything wrong with not knowing whether you could leave if you wanted to.

Get the ownership position in writing before the build starts. A signed clause assigning copyright in the deliverables, and confirming your right to a full export on request, costs nothing at proposal stage and is unobtainable afterwards.

Keep an independent backup. Not the one on the server. A copy you can reach without anybody’s permission, taken at least quarterly, stored somewhere in your business.

Document the stack once a year. Registrar, registry, hosting provider, DNS provider, mail provider, gateway, analytics, ad accounts, and who the account holder is on each. One page. Review it when anything changes.

We do this as standard on builds and handovers because it removes an entire category of future argument, and because a client who could leave tomorrow but chooses not to is a better client relationship than one who cannot.

The uncomfortable read on lock-in

There is a version of this problem that is not an accident. Some providers structure their offering so that leaving is technically difficult: proprietary platforms with no export, websites that only function while a monthly fee is paid, domains held centrally as a matter of policy, credentials that are never shared.

It is worth being clear about what that represents. A provider who makes leaving hard has decided that retention is easier to engineer than to earn. That is a commercial strategy, and businesses are entitled to run it, but you are equally entitled to read it for what it is when you are choosing who to work with. The question to ask any agency before you sign is not whether they would ever hold your website hostage. Everyone says no. The question is what the exit process looks like, in writing, and how long it takes.

A good answer is short and specific, because the agency has done it before and has nothing to protect. A vague answer is the answer.

If you are currently locked out of your own website, or you have inherited a website with no credentials and no history, our team handles recovery, migration and rebuilds for businesses across Johannesburg and the rest of South Africa. We start by establishing what you control, which is usually more than you think.

Frequently Asked Questions

Can my web developer legally keep my domain name?

Whoever is recorded as the registrant holds the domain at the registry, regardless of who paid for it. Where you are the registrant and a registrar or reseller is refusing to release the domain over a billing dispute, the ZA registry’s published guidance is that its policies do not permit a registrar to lock in a registrant on that basis, and that contractual disputes belong in court. If the domain is in your developer’s name and they will not transfer it, you can challenge the registration through the .za Alternative Dispute Resolution process on the basis that it is an abusive registration, or approach a court. Documented payment of renewals and established rights in the business name both strengthen your position.

How do I transfer a .co.za domain away from my developer?

There is no authorisation code for .co.za. Your new registrar initiates the transfer and the registry emails a voting request to the registrant, administrative, billing and technical contacts. An approval from the registrant moves the domain immediately, a denial stops it, and if nobody votes the request simply expires after five days. If the contact email belongs to your developer, approach the registrar directly with proof of identity, your CIPC documents and evidence that you paid for the domain.

Who owns a website in South Africa, the client or the developer?

Under the Copyright Act 98 of 1978, copyright vests in the author, and for a computer program the author is the person who exercised control over the making of it. Payment alone does not transfer copyright, and any assignment must be in writing and signed. Your content, logo, photographs and customer data remain separate works that are ordinarily yours.

What does a .co.za domain dispute cost?

ZADNA’s published adjudication fees are R10,000 for a single adjudicator and R24,000 for a three-adjudicator panel, with a mediation stage before adjudication. SAIIPL indicates a filed case is normally concluded within about two months. That is considerably cheaper and faster than High Court litigation, though it is still a meaningful cost to weigh against the value of the domain.

Can I get my website files if the hosting account is not in my name?

A hosting provider will not give you access to another party’s account, but they will often assist a verified end client with a backup of the data associated with their own domain, especially where the reseller is unresponsive and you can show payment. Ask for a full cPanel backup, which includes files, database, email and the DNS zone.

What should I do first if my developer stops responding?

Establish what you control before you escalate. Run a WHOIS lookup to see who the registrant and contacts are, check your nameservers and MX records, find proof that you paid for the domain and hosting, and back up your mailboxes locally. Secure the domain first, then email, then hosting. The website files matter least because they can be rebuilt.