How to Transfer a Website to a New Developer Without Losing Anything

The safe way to transfer a website to a new developer is to move every account into your own business's name first, then hand over access in a fixed order: domain, hosting, CMS admin, and DNS and email last. That order is the whole website handover checklist in one sentence, and it exists because the last step is the one that takes your site and your email offline if the earlier ones were rushed.

Most handovers that go wrong go wrong in a boring way. Nobody wrote down the DNS records before the nameservers changed. The old host got cancelled the same afternoon. A plugin license was on the old agency's account and stopped updating six weeks later, quietly. None of that is hard to avoid, it just has to be done in sequence.

Before anything moves: take an inventory

Spend an hour on this and the rest of the handover gets easy. You are writing down what exists and who holds it, not changing anything yet.

Fill the gaps by hand: which paid plugins or themes are running and whose account holds each license, where the business email is hosted, who is a verified owner in Search Console, and who has admin on analytics. If you do not know where to start, our website ownership checklist is the full list.

What the new developer needs on day one

A good developer will ask for these unprompted. If they do not ask, ask why.

• The domain registrar login, or at minimum confirmation of which registrar holds the domain and when it renews.
• The hosting login, the real one at the hosting company, plus SFTP or SSH details and database access.
• An administrator account on the CMS created in their own name, not a shared password.
• A full backup: the site's file directory and a database dump, dated.
• A current export of the DNS zone, every record, before anything is changed.
• Verified owner access to Search Console and admin on analytics.
• The license keys and receipts for any paid theme, plugin or font.
• A short list of what breaks: the forms that must keep working, the pages that get the most traffic, the integrations nobody remembers setting up.

What to get from the old developer

Ask in writing, in one message, and be specific. Vague requests get vague replies. You want: the files and database, the license keys, an export of the DNS zone, the account emails on every service, and a note of anything running on their own accounts, such as a form service, a chat widget, or a CDN. Then ask the one question people forget: is anything on this site running on infrastructure you own that will stop working when we leave?

On WordPress, be precise about what a backup means. The export file under Tools produces an XML file with your posts, pages, comments, custom fields and users, but it does not include your site options, your uploaded media files, or your theme and plugin files. WordPress's own documentation says a real backup is two parts, the files and the database, and you need both to restore. Ask for both.

The website handover checklist, in order

The DNS and email step is where handovers actually break

Changing nameservers moves your whole zone to a new provider, and only the records that exist at the new provider will answer. If your MX records were never recreated there, incoming mail has nowhere to go the moment the change takes effect. That is the real disaster scenario, and it is entirely preventable.

1. 1Export or screenshot every existing record first. A, CNAME, MX, TXT including SPF, DKIM keys, and anything unusual. Keep it somewhere outside both agencies' accounts.
2. 2Lower your TTLs a day or two ahead. TTL is how long other networks cache your records. Cloudflare's migration guidance is to lower TTLs on critical records at least 24 to 48 hours before the window, down to around 300 seconds, so if something is wrong you can reverse it in minutes rather than waiting out an old cache.
3. 3Recreate every record at the new provider and compare the two lists line by line. Do this before touching nameservers, not after.
4. 4Repoint the nameservers. Google documents that MX changes can take up to 48 hours to propagate, and that during that window mail may still be delivered by the previous provider. Their guidance is that messages are not lost, though some may bounce and need resending, so schedule the cutover for a low-volume hour rather than mid-morning on a Monday.
5. 5Verify from outside. Check that mail arrives, that the contact form sends, and that the site loads on a phone with the office wifi turned off.

Search Console and analytics: verify first, remove second

Google Search Console has two kinds of owner. A verified owner proved control of the site with a token, such as a DNS record or an HTML file. A delegated owner was simply granted the status by a verified owner. The order that matters: have the new developer verify in their own right before you remove the old one. Google warns that if all verified owners are removed, everyone else loses access to the property after a grace period, data keeps collecting, and nobody can see it until someone verifies again.

Removing a verified owner also means removing their verification token from the site, otherwise they can simply verify again. On the analytics side, access is granted at the account level or the property level, and you need the Administrator role to add or change users. Give the new developer their own named access rather than sharing a password, and make sure at least one Administrator is you.

The two weeks of overlap

This is the single cheapest insurance in the whole process and the thing owners cut first. Keep the old hosting account alive and paid for roughly two weeks after the new site goes live. Do not cancel, do not delete, do not let the card expire.

Reasons this pays for itself: a page nobody remembered turns out to have been the one the accountant used; an old form was posting to a script on the old server; a redirect was missing and you can only see the original URL structure on the old install; the media library did not copy cleanly and you need the original uploads folder. Every one of those is a five minute fix while the old server exists and a very bad week after it is gone.

• Keep paying the old host until the new site has been live two full weeks with no surprises.
• Keep one working backup off both servers, dated, in your own storage.
• Watch Search Console for a spike in crawl errors, which is how you find the redirects nobody mapped.
• Leave the old developer's admin account active but downgraded rather than deleted, if the parting was friendly, until the overlap ends.
• Then close things down deliberately, one at a time, with a note of what you cancelled and when.

If you are on the other side of this

If the old developer has stopped replying and the handover is not a handover at all, the sequence is different and you should read what to do when your web developer disappears. If you cannot even work out who is holding what, start with how to find out who manages your website hosting and how to find out who owns a domain name.

And the plain sales note. Taking over a site somebody else built is a normal week for us: our website maintenance plans start at $99 a month and we onboard sites we did not build, running exactly the checklist above and putting the accounts in your name, not ours. If the current hosting is part of the problem, our managed hosting includes the migration. We are in Mill Creek, north of Seattle, and have been doing this since 2011, locally and remotely. If your new developer already has a handover process of their own, use theirs. The point is that somebody follows one.