Sometimes the relationship with a web developer simply runs its course. They may have retired, moved on to other work, become hard to reach, or no longer fit what your business needs.
Whatever the reason, you can change developers without losing your website. What matters is understanding what exists, who controls each part, and what needs to move.
This checklist is written for business owners, not technical specialists. It is general guidance, not legal advice. Your original agreement may include terms about ownership, notice and handover, so read it before you act.
Start with a calm conversation
Most handovers go better when both sides stay polite. The outgoing developer holds information you need, and they are more likely to share it if the conversation is straightforward and professional.
If the relationship has already broken down, collect what you can access yourself first. The inventory below shows where to look.
Step 1: find out what you own and where it lives
A website is not one thing. It is several services that work together, and different parties may control each one.
Fill out this inventory. Answer each row with a name, a company or “not sure”. The “not sure” rows are the ones to chase.
| Item | What it is | Who holds it today | What you need | Done |
|---|---|---|---|---|
| Domain name | Your web address, such as yourbusiness.com.au | To be listed as the registered owner, with access to the account | ||
| DNS | The records that point your domain to your website and email | To know where it is managed and have access | ||
| Hosting | The server where the site files and database live | An account in your business name, or a clear plan to move | ||
| WordPress admin | The login you use to manage the site | Your own administrator account | ||
| Theme | The design framework running the site | The licence, if a paid theme | ||
| Plugins | Extra features such as forms, shop, SEO, security | List of plugins and any paid licences | ||
| Custom code | Anything written specially for your site | A copy and a note on where it lives | ||
| Backups | Copies you can restore from | A recent full copy, and knowledge of where backups are kept | ||
| The service that handles your business email | To know who runs it and how it is billed | |||
| Website email sending | How forms and notifications send mail | The sending service, account owner and settings | ||
| Forms and integrations | CRM, newsletter, payment, booking, feeds | Which accounts they use and who owns them | ||
| Analytics and tags | Google Analytics, Search Console, Tag Manager, pixels | Your own ownership or administrator access | ||
| SSL certificate | The padlock and secure connection | To know who renews it | ||
| Design files and assets | Logo files, source images, design documents | Copies of everything you paid for | ||
| Documentation | Notes, training videos, instructions | Whatever exists |
Step 2: check which accounts are in your name
The most common problem is simple. The developer registered the domain or opened the hosting account using their own details. Everything works until you need to change something.
Look for:
- Who is named as the registrant for your domain. The registrar’s own account shows it. Public lookups may display limited details.
- Whose email address receives renewal notices.
- Whose payment card pays for hosting, licences and services.
- Which accounts require the developer’s approval to make changes.
If something is in the developer’s name, ask them to transfer it to you or add you as the owner. Ask early, because some transfers take time and need confirmations by email.
Step 3: set up your own access, without sharing passwords by email
You need administrator access to the services above. Ask for:
- An administrator login to WordPress created for you, rather than a shared password.
- Ownership or admin access to analytics, Search Console and tag accounts under your own Google account.
- Access to the hosting control panel, or an invitation to a new account.
- Access to the DNS, or a clear explanation of who edits it.
Avoid sending passwords in plain emails or chat messages. Use a password manager’s sharing function or ask each service to send an invitation. Once the handover is finished, change any shared passwords and remove accounts that are no longer needed.
Step 4: take a full backup before anything changes
Before moving or editing anything, have a complete copy of the site: files and database. Ask for it to be stored somewhere you control.
A backup that has never been restored is only a hope. If the new developer can restore the copy onto a test environment, you have real evidence that it works.
Step 5: list integrations and who runs them
Many sites do more than display pages. Forms may send details to a CRM, orders may flow to accounting software, or a booking tool may sit inside a page.
For each connection, write down:
- What it does in plain words.
- Which account it uses, and who owns that account.
- What information moves, and where.
- Who needs to be told if it breaks.
This is where handovers most often go wrong, because the connection is invisible until it stops working. Our guide to testing a website form properly explains how to check these journeys end to end.
Step 6: decide how the move will happen
There are usually three options:
- Stay put and change the people. The site remains where it is, and a new developer gets access and takes over support.
- Move the hosting. The site is copied to new hosting and the domain is pointed to it.
- Rebuild. You start again on a new site, possibly keeping content and addresses.
The right option depends on the site’s condition, how it was built and what you want to achieve. A short assessment by the new provider can settle that. We explain the difference between hosting, maintenance and support in a separate article, which helps when deciding what to buy.
If you move hosting, agree a plan for the day of the switch:
- Who changes the DNS, and when.
- How long the old hosting stays active as a fallback.
- Who checks forms, email and key pages afterwards.
- What happens to email, if your email is connected to your hosting.
Email deserves special attention. Changing DNS or hosting can interrupt business email if email settings are not carried across. Confirm this with whoever manages your email before the change.
Step 7: check before, check after
Make a short list of the journeys that matter to your business, such as:
- Submitting an enquiry form and the right person receiving it.
- Placing a test order, if you sell online.
- Booking an appointment, if you take bookings.
- Logging in to a customer or member area.
- Viewing key pages on a phone.
Test these before the move to learn what normally happens. Test them again afterwards and compare. Use made-up details, not real customers.
Step 8: agree on the ending
Before you part ways, confirm in writing:
- What the outgoing developer has handed over, and what they will do on the transfer day.
- When their access will be removed.
- Whether any final invoices or services remain.
- Who to contact if a question comes up in the following weeks.
If the outgoing developer is no longer reachable, a new provider can often still help, depending on what access you hold. That is why it pays to establish your own ownership early.
How we approach takeovers
We assess sites built elsewhere for free, and we do not turn a site away because another developer built it. The assessment looks at how the site is set up, how it is hosted and what condition it is in, so you know what you have before you decide. Our WordPress support page has the details.
If you decide to move your hosting to us, our managed hosting and maintenance includes Melbourne-based hosting, updates, security monitoring, daily backups, performance optimisation, uptime monitoring, troubleshooting and direct support.
A sensible next step
Start with the inventory table. Even if you stay with your current developer, knowing who holds each piece is good practice, and it takes less than an hour.
If you are weighing a change and would like a second opinion on what you have, ask for a free assessment. You do not need to commit to anything to find out where things stand.
