Recovery guide · Updated August 2026
This is one of the more common calls we get, and it's rarely as bad as it feels on day one. Here's what you actually need to recover, in what order, and what to do if the person holding it won't cooperate.
What to recover
The four marked critical block everything else. Get those and you own your website again, even if the rest takes longer.
| Asset | Priority | What to ask for | Why it matters |
|---|---|---|---|
| Domain name | CRITICAL | Registrar login, or an authorisation code plus registrant email access | Without this you cannot move your site anywhere. Recover it first, before you tell anyone you're leaving. |
| Hosting / server | CRITICAL | cPanel, VPS root or cloud console access | Your site's actual files live here. If it's inside the developer's reseller account, you'll need a migration rather than a login. |
| Source code | CRITICAL | Git repository access, or a full file download from the server | For most sites you can pull files off hosting directly. Custom applications need the repository and its history. |
| Database | CRITICAL | A full SQL export, not a screenshot of tables | Your customers, orders and content live here. Take an export yourself the moment you get hosting access. |
| DNS / email routing | HIGH | Current DNS record list before anything changes | Business email often runs on the same DNS. Move a site carelessly and you take your own email down. |
| Analytics & Search Console | HIGH | Owner-level access, not view access | Years of traffic history. If the developer created the property under their own account, request ownership transfer before the relationship ends. |
| Payment gateway & APIs | HIGH | Merchant dashboard access and API key ownership | Keys registered to a developer's email are a live security exposure as well as an access problem. Rotate them all after handover. |
| Design source files | USEFUL | Figma, XD or PSD files and the font licences | Not blocking — a new team can work from the live site — but their absence makes future changes slower and more expensive. |
One order note that matters: check the domain WHOIS before you tell your developer you're moving on. If the domain is in their name, it's far easier to get transferred while the relationship is still cordial than after you've announced you're leaving.
The process
Order matters more than speed here. Doing step four before step three is how people lose a database.
Look up your domain on any WHOIS tool. If the registrant is your company and the contact email is yours, you're in a strong position. If it's the developer's name, that's the first thing to fix — and doing it quietly, before you announce you're leaving, is much easier.
Send a single email — not WhatsApp — listing every item in the table above. Written requests create a record, and most developers who are simply disorganised rather than hostile respond fine to a clear list with a deadline.
The hour you receive hosting access, download the full file tree and export the database yourself. Don't wait for the developer to send a backup, and don't assume access you have today you'll still have next week.
Open your own account with any registrar and transfer the domain in. This is the step that ends your dependency permanently. Everything else can be rebuilt; the domain can't be replaced.
New passwords everywhere, new API keys, remove old user accounts from hosting, analytics, gateways and the CMS. This isn't about distrust — old credentials scattered across former vendors are simply a standing security risk.
Have someone review what you've inherited before new work starts. Version, dependencies, known vulnerabilities, whether backups exist. It's cheap, it takes a day or two, and it stops you building on something that's about to fall over.
When they won't hand it over
Most cases are disorganisation rather than malice. But when it is deliberate, these are your practical routes — none of which start with a lawyer.
Contact the registrar and hosting provider directly. Both have account-recovery processes, and both will generally cooperate with a company that can produce payment records, GST invoices and incorporation documents proving the account was set up for your business.
Settle the invoice if it's genuinely owed — it's almost always cheaper than the dispute. If the amount is contested, pay the undisputed part and put the rest in writing. Access disputes escalate fast and rarely end well for either side.
You're relying on your payment record. Invoices, bank transfers and email threads showing you commissioned and paid for the work are what establish your claim. Gather them before you make any formal request.
Sometimes it isn't, and rebuilding is faster than fighting. Register a fresh domain, rebuild, and set up 301 redirects if you eventually recover the old one. Painful, but a month of deadlock costs more than a rebuild.
Questions
Dealing with this right now? Send us the situation — we've done this recovery often enough to tell you quickly whether it's a three-email problem or a rebuild.
Start with the registrar and hosting provider directly rather than the developer. Both have account-recovery processes and will generally cooperate with a business that can produce payment records, invoices and incorporation documents. In parallel, send one written email listing every item you need with a clear deadline — written requests create the record you'll rely on if this escalates.
Under Indian copyright law the creator owns the work by default, so with no written assignment the developer may hold copyright in the code and design. However, your payment records, invoices and correspondence establish that the work was commissioned for you, and content you supplied remains yours. In practice most access disputes are resolved through the registrar and host rather than through copyright arguments.
You need either the registrar login, or an authorisation code (EPP code) plus access to the registrant email address. Ask for both. If the developer is unresponsive, contact the registrar's support team with proof that the domain was registered for your business and paid for by you — most registrars have a documented dispute process for exactly this situation.
Eight things: registrar access for the domain, hosting or server credentials, source code or repository access, a full database export, the current DNS record list, owner-level analytics and Search Console access, payment gateway and API key ownership, and design source files. The first four are blocking — without them you cannot move or maintain your site at all.
Take over if the code is reasonably current, dependencies are maintained, and you have the database. Rebuild if it runs on an unsupported framework version, has no backups, or the code quality means every change carries risk. A short technical audit — usually a day or two — answers this properly and costs far less than choosing wrong.
Three rules. Register the domain yourself, in your company name, before the project starts. Insist every account created for your project uses your email as owner. And put a written handover list in the contract as a condition of final payment, with 10% of the fee retained until each item is delivered and you have logged into it yourself.
Tell us what you have and what you're missing. We'll tell you whether it's recoverable, what it takes, and whether rebuilding is honestly the cheaper path — before you commit to anything.
Describe your situation
