How to switch web developers without losing your site

To switch web developers without losing your site, take control before you change anything. List every account and DNS record the site depends on, get the domain and those accounts into your business's name, back up the site and its form data, and only then move the website, one piece at a time, while leaving your email records alone. Most takeovers that go wrong skip the first two steps.

This is the checklist we use when we take over a site. It's how we handled Elume Medspa in Fairfax, Virginia, where we replaced the previous agency as web vendor on September 20, 2026, including the problems that turned up after everyone thought the handover was complete.

Step 1: Inventory everything before anyone touches anything

Your website is several services from different companies sharing one domain name: registrar, DNS host, web host, email and booking can all be different companies. A developer who only knows about the website can break the other four in one click. Before we take over or rebuild any site, we fill in a "current setup" table like this one. Most of it can be checked from outside, without logging in.

When we build these tables, the same surprises keep coming up. The registrar of record is a company the owner has never heard of, because the domain was bought through the website builder. DNS lives somewhere other than the registrar. The only analytics tag is Universal Analytics, which Google stopped processing in 2023. And the main Book button points at a 404.

Step 2: Get ownership into the business's name

Do this while the relationship is still friendly, and before launch day. Ask for everything on one written list.

The domain

Two things decide who controls a domain: the registrant on record (the legal holder) and the account it sits in. Both should be your business, with renewal on your card.

You usually don't need to move to a new registrar. If the domain sits in your developer's account, the fastest fix is an account-to-account move at the same registrar. At GoDaddy, for example, the developer starts a transfer to another GoDaddy account, and you have 10 days to accept it. The DNS settings come with the domain, but connected products like hosting or email don't, so check those separately.

If you do move registrars, that's an inter-registrar transfer under ICANN's Transfer Policy. As of October 2026, these are the rules in force, per ICANN's FAQ for domain holders:

• The registrar lock must be off, and you need the domain's authorization code (also called an auth code or EPP code). Your registrar must give you the code within five calendar days of your request.
• A domain can't move registrars within 60 days of being registered, or within 60 days of its last transfer.
• Changing the registrant's name, organization or email triggers a 60-day transfer lock. Some registrars let you opt out before you make the change.

ICANN's policy council approved recommendations in 2025 to shorten some of these locks to 30 days and drop the change-of-registrant lock. They weren't in force when we checked, and your registrar applies whatever is in force on the day you act, so ask them.

The practical order: get the domain into your account first, confirm auto-renew and the expiry date, and only change registrar later if you have a reason to. A lapsed domain is the worst outcome of a messy handover. In a hand-checked list of 100 med spa websites from our scans, 5 had lapsed domains and 3 had been hijacked by gambling or spam redirects. One of the lapsed ones belonged to a business with more than 200 Google reviews.

Everything else

• Hosting. Ideally the account is in your name and the developer is a user on it. If they host you on their own server, you'll take a full export instead (step 3).
• Google Business Profile. You should be the primary owner. Google makes a new owner wait 7 days before they can transfer primary ownership or remove other owners, so start this early.
• Search Console. Add yourself as an owner. When you later remove the old developer, also delete their verification token (an HTML file, meta tag or DNS record). Google's permissions help warns that a removed owner can re-verify if the token is still there.
• Google Analytics and Google Ads. Your own login should have Administrator or Admin access.
• Meta. Meta doesn't let you move an ad account from one business portfolio to another. If your ad account lives in the agency's portfolio, the long-term fix is a new ad account in yours, with the agency added as a partner.
• Email admin. The Microsoft 365 or Google Workspace admin should be an owner, not the developer.

Step 3: Back up what you can't recreate

What you can take depends on the platform:

• WordPress and other self-hosted sites: a full copy of the files and a database export. That's a complete, restorable site.
• Hosted builders: they don't hand you a portable copy. Wix, for example, says plainly that a Wix site can't be hosted elsewhere. If you're staying on the builder, ask the developer to transfer the site into your own account. If you're leaving, save every page's text and every original image yourself.
• Form entries: export them. A contact or booking form that's been running for years is a lead list. At Elume, the site's booking request form held 1,897 entries from 1,331 people going back to 2018, and those leads had never been emailed until the move to a new email platform.
• The DNS zone: export or screenshot every record at the DNS host. This is the one people skip, and it's the one that saves your email in step 5.
• The URL list: download the sitemap and export your top pages from Search Console.

Store backups somewhere the business owns, not on the web server. A database export holds password hashes and customer records, and a copy left in a public folder is a liability.

Step 4: Keep your old URLs

Google ranks pages, not websites. If /botox/ ranks today and the new site moves it to /treatments/botox/ with no redirect, that ranking is gone. Keep every URL you can. Where one must change, 301-redirect it in one hop to the matching new page, not the homepage.

Build the list from the sitemap, the Pages report in Search Console and your analytics landing pages. Then add URLs that live outside the site: your Google Business Profile, printed cards, old emails and ads.

If the switch includes a domain change, keep the old domain registered forever. Weeks after the Elume store move, 70 of its 71 referring domains still linked to the old address. Those links only count as long as the old domain keeps redirecting.

Step 5: Change DNS without email downtime

Launching a new site usually means changing two DNS records: the A record for the root domain (@) and the CNAME for www. That's it. Everything else in the zone belongs to other services and stays exactly as it is:

• MX records route your incoming email. For Google Workspace the value is now smtp.google.com, though Google says the older aspmx values still work.
• SPF (a TXT record), DKIM (at selector._domainkey) and DMARC (at _dmarc) authenticate your outgoing mail.
• Verification TXT records for Google, Microsoft, Meta and others.

The nameserver trap

The most common way a website switch breaks email is a nameserver change. Point your nameservers at a new DNS host and the new zone replaces the old one entirely. Any MX, SPF or DKIM record that wasn't copied across first stops existing, and mail bounces. If you must change DNS hosts, recreate every record from your step 3 export first, compare them line by line, then switch. Otherwise, leave DNS where it is.

If the new setup adds an email tool, put it on a subdomain so the root SPF record stays untouched. When we moved Elume's marketing email to Klaviyo, we put the sending domain on send.elumemedspa.com and added a DMARC record, because there wasn't one. The first live send passed SPF, DKIM and DMARC and landed in the inbox.

Step 6: Verify after the switch, then close the doors

Check the live site the way a customer sees it, not the developer's preview. Within the first day:

1. Load the root domain and www over https and confirm the certificate is valid on both.
2. Crawl the URL list from step 4. Every page should return 200, and every old URL should redirect once.
3. Submit every form and confirm the message reaches the right inbox.
4. Click every Book and Buy button and confirm it opens the right service.
5. Send an email to your business address from an outside Gmail account and reply to it. Check the headers for spf=pass and dkim=pass.
6. Open your analytics real-time report and confirm visits and conversions are recorded.
7. Check that the new site isn't set to noindex, then submit the sitemap in Search Console.

Then remove old access everywhere (site admins, hosting, DNS, Search Console tokens, analytics, ads, Business Profile) and change shared passwords. Cancel old hosting only after a couple of weeks of clean checks.

Printable website takeover checklist

Print this and tick it off in order.

When you don't need help with this

If your site is on Squarespace or Wix in your own account, your domain is in your own name, and the developer is only a contributor, switching developers is mostly removing their access and adding the new one. You can do that yourself in an afternoon.

It gets harder when the developer owns the accounts, the site is self-hosted with years of plugins, nobody has documented the DNS zone, or ads and booking are tied into the site. That's the work we take on in our digital management service. If the question is really who owns what, start with our guide to who owns your website, domain and accounts.

Frequently asked questions