When you are changing web developers, secure four things before anyone touches the design: the domain name registered to your business, the hosting account in your name, your own administrator login for the website, and the Google accounts that hold your search and analytics history. Then ask for a full backup and have it restored somewhere to prove it works. With those in hand, the next developer works for you and the last one cannot hold the site up. xCreative™ is a Melbourne creative agency based in Chadstone that has built and maintained websites since 2016, and we regularly take over sites that other people built. The checks below are the ones we run in the first week of every takeover.
Most handovers go smoothly. The ones that go badly tend to fail on something nobody wrote down: a domain renewing on the old developer’s credit card, a plugin licence sitting in their account, a scheduled backup that turns out to be empty. A week of checking at the start costs far less than discovering any of these during an outage.
Start with the domain name
For a .com.au address, the business is meant to be the registrant. auDA, which administers the .au namespace, says a developer may register or renew a name on your behalf, but you or your organisation must be listed as the registrant, not the developer. If the record shows the developer’s company, auDA says a correction can be requested. Look the name up in the .au WHOIS, then confirm three things with the registrar: the account login is yours, renewal notices go to an inbox your business controls, and the renewal is not tied to a card belonging to someone who is leaving.
DNS settings deserve the same attention. These records point your email and website, plus any booking or payment tools, at the right servers. Before anyone edits them, we export the full list of records, so the old setup can be put back in minutes if a change stops email arriving.
Your name on the hosting and every login
Hosting is where the site actually lives. Ask for the hosting account itself, not a sub-login inside the developer’s own account. If the developer runs dozens of clients on one server, leaving may mean a migration rather than a password change, and that work should be scoped before the old agreement ends.
Inside WordPress you need an Administrator account under your own email address. A shared login called “admin” is a security risk and makes it impossible to tell who changed what. Once the handover is complete, the previous developer’s accounts should be removed or downgraded. The Australian Signals Directorate’s small business cyber security guide asks website owners to protect the login with multi-factor authentication, keep the content management system and plugins updated, and back the site up so it can be restored after an attack. Those three lines are a fair summary of what a handover should leave in place.
Premium themes, page builders and form plugins are often licensed through the developer’s account. When that account lapses, updates stop, and a plugin that never gets updated is one of the most common ways a small business site is broken into. List every paid plugin, whose account holds it and when it renews, then move each licence across or buy your own.
Google Search Console, Google Analytics, your Google Business Profile and any ad accounts work the same way. Your business should be the owner and the developer should be an added user. Years of search data are hard to rebuild if the only owner walks away.
The backup test most inherited sites fail
Ask for a complete backup of the files and the database, then have someone restore it on a server other than the live one. Until it has been restored once, nobody knows whether it works. We have taken over sites where the scheduled backup had been failing quietly for months, and others relying on hosting backups that kept only a few days of history.
We also look for the opposite problem: full-site backup archives left inside the public web folder. Anyone who guesses the file name can download one, and it usually holds the database, past enquiries and the site’s configuration. On inherited sites we have found archives from several hundred megabytes up to several gigabytes sitting where the public could reach them. Removing them is the first fix we make.
What we check before changing anything
- One address only. Many inherited sites load at both the www and non-www versions, sometimes with each version telling Google it is the main one. Google’s advice on consolidating duplicate URLs is to choose one preferred address and redirect the others to it.
- Sitemap and robots file. Both should point to pages that exist. A sitemap address that returns an error gives search engines nothing to work with.
- Pages hidden by accident. A single setting can keep pages out of Google. It happened to our own case studies this year, and it took a check in Search Console to find it, not a look at the site.
- Leftover demo content. Themes ship with sample posts and FAQs, and they often stay published for years.
- Certificate renewal. Free security certificates expire every few months. When automatic renewal fails silently, visitors eventually get a browser warning instead of your home page.
- Traces of old servers. After one earlier migration we found the old server’s IP address written into the site’s content more than a thousand times.
- Plugin and PHP versions. Some plugin updates will not install on an older version of PHP, which can decide whether the hosting needs to change as well.
None of this needs a redesign. The result is a list of risks in plain English that we hand the owner along with a quote to stabilise the site, and it is where our website maintenance service begins for any site we did not build.
If the old developer will not hand over
Most developers hand over without fuss once the request is in writing and lists exactly what is needed. If yours does not, start with the contract, which usually says who owns the design, the code and the content. The domain is your strongest position, because auDA’s rules already say who should hold a .com.au name. Public pages and images can be copied from the live site if it comes to that, which is why we save everything at the start of a takeover rather than the end. For disputes about code ownership or unpaid invoices, speak to a lawyer before escalating.
If a redesign is also planned, finish the handover first. Changing the host and the design in the same week makes any drop in enquiries impossible to diagnose; our rebranding checklist sets out the order we follow. When you choose the next developer, ask on day one whose name the domain and hosting will be registered in. A good answer is a short one, and our guide to choosing a website designer for a small business covers the other questions worth asking.
We build most new sites on WordPress and look after many of them for years. Liquid R is one example: we designed the brand and the website and still run its search work. If you are partway through a handover and want a second opinion, contact our Chadstone studio.
Frequently asked questions
Can my web developer keep my domain name?
For a .com.au name, auDA’s rules say the business, not the developer, should be listed as the registrant, and a name registered to the wrong party can be corrected. A .com address follows the registrar’s own terms, so your invoices and contract carry more weight there.
How long does it take to change web developers?
Collecting the accounts and testing a backup usually takes one to two weeks when the old developer cooperates. Moving to new hosting adds time and is best scheduled outside your busiest trading period.
Should I redesign the website at the same time?
Not in the same week. Stabilise the current site first, confirm enquiries are steady, then start the redesign. Keeping the two changes apart shows you which one caused any change in traffic.
