Who this case is for
If you are changing web developers, or taking over from someone with no details in hand, this case shows how we look after a client from design through to after handover.
Yadalong Property is a pool villa developer in Phuket. We designed and developed its new website.
The design: a site that feels like the homes it sells
Buyers choose villas at this level on feeling as much as on specifications, so the design follows the brand’s identity.
- Color and type: deep green with warm ivory and serif headings, for a calm, refined feel
- Images first: each project tells its story through photos, followed by villa types, areas and details
- 3 separately written languages: English, Chinese and Russian, with no machine translation
- Editable by the team: content, prices and unit counts, with a preview before publishing
- Real brief rounds: photos, figures and project details refined over several rounds on desktop and mobile
When the sales team suggested a construction updates page, we added it in the same design at no extra charge.
After handover: problems we did not leave the client to face alone
Our contact had just taken over from a predecessor, had no logins for the old system, and was not technical. So we explained things in plain language, gave one step at a time, and answered questions until each task was done.
Problem 1: The domain was not in the company’s name
The handover document showed the domain sat in the previous administrator’s account, with that administrator as the registered owner. This is common, because letting the web provider register a domain is convenient at the start.
The risks when a company does not hold its own domain
- If the previous person cannot be reached, you may be unable to move the site, change DNS or get a transfer code
- If a renewal is missed, the website and any email on that domain stop working, possibly without the company being warned
- If a dispute arises, the system treats the listed owner as the person in control, even if the company paid
- If an employee’s personal email is the main account, the company can lose access when that person leaves
So we give every client the same advice: the company holds the domain, and we handle the technical side. That was also what the Yadalong team wanted.
The steps we used
- Open a registrar account in the company’s name, using a company email
- Request the transfer code (EPP / Authorization code) from the previous administrator
- Enter the code in the new account and pay the 1-year renewal that comes with a transfer
- Wait for the transfer to be approved
- Only after it completes, change the registrant to the company
Step 5 matters. Changing the owner details before the transfer finishes can trigger a 60-day lock and delay the work by about two months.
The old site kept running during this time, so we waited for the domain to reach the company’s account before changing the nameservers.
Problem 2: The www everyone assumed was the address
The team asked for the new site to stay at www.yadalongproperty.com, yet the old site’s documents used the version without www as the main link. Most people cannot tell the two apart, because both used to open.
Most new sites choose no www because
- It is shorter to type, say and print in advertising
- It looks cleaner in search results and chat links
- People now remember the domain name and do not need www to know it is a website
But www is not wrong, and Google does not rank either version higher. The real mistake is letting both run separately. A site should have one main address, with the other sending visitors there.
We kept the version without www, matching the old site’s main links, so existing links would not change unnecessarily.
The trap we hit: SSL was issued only for the version without www. After the move, Chrome on our machine opened it fine because it forwarded us to the main domain, so all seemed well. Clean browsers and testing tools reported a certificate mismatch, and the client’s team also saw a risk warning when opening www on phones and computers.
The lesson: never test from one machine only. Check all 4 versions, with and without www, on http and https, across several devices.
Problem 3: The mailbox everyone assumed existed
Before receiving the handover document, we understood that company email sat with the old hosting, so we proposed a plan to preserve it. The document stated clearly that no mailbox had ever been created on this domain. The team had always used Gmail.
That changed the whole plan.
- The good news: moving the site could not damage any mailbox
- What needed doing: a real company email address requires a separate email service, so we gave the team several options to compare
- Website forms: we set them to send through the sales team’s Gmail with an App Password, then tested that messages arrive and that Reply goes to the person who filled in the form
Owning a domain does not mean you have email, and an MX record does not prove a working mailbox exists. If unsure, send and receive a real test message before any move.
What honest care looks like
- Saying so when we were wrong: the email assumption is the clearest example
- Recommending what is good for the client: the domain belongs with the company, even though that means less reliance on us
- Keeping what already existed: old project links go to their matching new pages, and the company’s access to existing systems stayed intact
- Fixing what gets reported: when a new page made the menu overlap, we fixed it and rechecked every page and language
- Not disappearing after payment: the team can still request edits as before, at no extra charge until the end of 2026
Checklist before moving a website
- Is the domain in the company’s account and name?
- Does the domain account use a company email, not an employee’s personal one?
- Have all existing DNS records been noted, especially MX and TXT?
- Does company email really exist and work?
- Have you chosen a main address, with or without www?
- Does SSL cover both versions?
- Does every old link redirect to its matching page?
- Do forms really reach an inbox?
- Have you tested on other phones and computers?
FAQ
Can our web provider register the domain for us? Yes, if it is in the company’s name and account. We recommend the company owns the account and gives the provider technical access.
Will a domain transfer take the site down? Normally not, if DNS stays the same. It is best to treat the domain transfer and the site move as separate steps.
Should we use www? Either works. What matters is choosing one and having the other forward to it, with SSL on both.
Want a designer who stays after handover?
If you want a new website, or have taken over one and do not know where to start, message our freelance team on LINE OA or see our website migration service.