First, the reassurance that makes the rest of this readable: your website is not inside your developer. It is a set of assets — a domain, a hosting account, files, maybe a database — that exist independently of whoever built them. "Taking over" a website means finding out which of those assets you control, recovering the ones you can, and putting a responsible name on all of it going forward. The order matters, because exactly one of those assets is on a timer.
Today: find the date that kills everything.
A website survives an absent developer indefinitely — hosting keeps serving, the site keeps working. What it does not survive is a domain expiry. When the domain lapses, the site goes dark and the email on that domain stops arriving, silently, everywhere at once — and after a grace period, the name can be bought by anyone. If the renewal reminders have been going to the developer's inbox, you will get no warning at all.
So before anything else: run your domain through a WHOIS lookup (any registrar's site
offers one; for .my domains, MYNIC's own search). Two facts come back that
decide everything else. The expiry date — if it is inside a couple of
months, renewing is now the most urgent task your company has this week. And
the registrant — whether the domain is registered to your company, or
to the developer. If it is not yours, see the first question at the end of this article;
recovery is usually possible, but start it now, not at expiry.
This week: the dependency map.
Next, work out what you actually hold. Ten things, five groups — for each one the question is the same: do we have the login, does someone else, or does nobody?
Domain and DNS
The registrar account (where the domain renews) and the DNS records (which point the name at the site and the mail). These are the crown jewels — with them, everything else can be rebuilt around you; without them, everything else is negotiating.
Hosting
Which company the site physically lives at, who pays the bill, and when it renews. The invoice trail in your own accounts department often answers this when nobody else can.
Administrative access
The CMS login (WordPress admin or equivalent), and the hosting control panel behind it. This is what lets a new caretaker actually work on the site rather than around it.
A copy of the site
Files, database, backups, a code repository if one exists. If none of these are reachable, note that the visible content can still be recovered from the live site — imperfect, but far from nothing.
The quiet dependencies
The three that get forgotten until they break: where your email actually runs, where the contact form sends its submissions, and who holds the analytics. Any of them may be wired through the developer's own accounts.
One of those deserves its own alarm: email. In many Malaysian SMEs the company mail rides on the same hosting account as the website — which means a lapsed hosting bill, or a rash decision to cancel it, takes down not just the site but every inbox on the domain. Before touching anything, confirm where the mail lives. It changes what "just let the hosting expire" would actually cost.
When access is incomplete — which is normal.
Most takeovers start with partial access: the hosting login but not the registrar, the CMS password but no backups. That is workable, and the honest review states which of three positions you are in. Recoverable — enough access exists to take full control; the work is administrative. Rebuildable — access is gone but the content survives on the live site; the visible pages can be reconstructed, though anything behind a login (orders, member data, custom systems) may not be. Negotiable — someone unresponsive still holds a key asset; most such cases resolve with a polite, documented request and settlement of any outstanding invoices, because holding a client's domain hostage is a reputation risk few developers actually want. Escalation paths exist — registrars and MYNIC will act on evidence — but they are the last resort, not the plan.
Then — and only then — decide what the site needs.
The temptation, mid-frustration, is to commission a rebuild — partly to solve the problem, partly as revenge on the old site. Resist it until the mapping is done. A site whose developer vanished is not necessarily a bad site; sometimes it needs nothing but a responsible caretaker and a renewed domain in the right name. The decision — keep and stabilise, repair, move, or genuinely rebuild — deserves a written review that is allowed to conclude the site is fine, made after the access map, not before.
And once the dust settles, run the ownership audit we publish separately so this article never applies to you twice.
Declared interest, as always: takeover is one of the two doors into our custody arrangement, and it has a service of its own — the mapping above, run for you, with the recovery position in writing. The reason this checklist exists is that we run it at every intake. The ownership rules that prevent a repeat are part of the same arrangement, in writing: the domain registered to your company and billed at cost, your content and data yours on exit, and the full boundary published for anyone to read — including the next provider you might ever move to. The test of a trustworthy caretaker is simple, and it is the one your last developer failed: could you leave them without an article like this?
Retrieved from https://amkatechnologies.com/insights/website-takeover-checklist
Published 30 July 2026. AMKA Technologies Sdn Bhd, SSM 202301041763 (1535682-T).