How to Change Web Designers Without Losing Your Website, Domain, Email, or Leads

Changing web designers should be a controlled handoff, not a hostage situation and not a midnight nameserver experiment. The safe version is boring on purpose:

Establish independent control, inventory every dependency, keep recoverable copies, test the replacement, switch one layer at a time, confirm the business still works, and only then cancel the old service.

What makes it hard is that "the website" is rarely one thing. The domain may be registered at one company. DNS may be managed somewhere else. Email may come from Google or Microsoft. The site may run on a hosted platform, a WordPress host, or a custom deployment. Forms, analytics, maps, scheduling, call tracking, fonts, plugins, and image licenses may each live in yet another account. Move the visible pages while losing control of one of those, and you can knock out email, erase your measurement history, strand form submissions, or leave the old provider as the only person who can renew a critical account.

This is not a live DNS tutorial — every setup differs and a careless change causes an outage. It's the owner-level plan I'd want in hand before authorizing the move, including what to do when the current provider won't cooperate.

First, separate the systems people lump together as "the website"

You can't transfer something safely until you know what it is.

Domain registration. The registrar holds the registration; the person or business listed as the registrant holds the rights. ICANN says registrants have a right to information from their registrar about managing, transferring, renewing, and restoring the domain, and that a registrar transfer generally must be initiated by the registrant, an administrative contact, or someone explicitly authorized. Certain conditions can also delay a transfer (see "When the outgoing provider won't cooperate"). So "we'll sort out the domain on launch day" isn't a plan — confirm the registrar, the registrant of record, the recovery email, the renewal state, the lock status, and who at the business is authorized, early.

DNS. DNS tells the internet where to find your site, your email, and other domain-based services, and the DNS host may be the registrar, the web host, a network provider, or someone else. Changing a website can mean changing one web record; changing nameservers can replace the whole authoritative set — not the same action, and email routing usually rides on DNS too. Replacing a zone without a verified inventory can break services that look unrelated to the new site. Don't copy DNS values from a blog or another company; the current records and the relevant provider's own documentation control the plan.

Web hosting or hosted platform. This is where the site actually runs — CMS, code, database, media, redirects, settings, scheduled jobs. A visual export is not the same as a recoverable site: a database without its media is incomplete, source without deployment instructions can be unusable, and a proprietary export may carry content but not design, commerce, forms, or member data. The handoff should state, per item, what transfers, what's merely viewable, what's licensed, and what must be rebuilt.

Business email. Email may share the domain but be a completely separate service — and that separation is the part that bites people. Moving web hosting doesn't necessarily move email, but a DNS or nameserver change can still break mail if the email records aren't preserved. Require an inventory and a send/receive test rather than treating a working homepage as proof the mailbox survived.

Lead capture and integrations. Forms may save records on the site, notify through an email service, create records in a database or CRM, route by service area, or call an automation. A design export can preserve none of that. Pin down, for each one, the source record, the notification path, the destination, the failure behavior, the export method, and who owns the account.

Measurement and business profiles. Google Analytics, Search Console, Tag Manager, Business Profile, Apple Business Connect, call tracking, ad pixels, consent tools, and map keys may all sit in separate accounts — and a developer login is not proof the client owns any of them. Preserve property ownership, historical data where the platform allows it, and account-level access.

Build a dependency register before anyone mentions a launch date

Make one inventory with a row for every system that could affect the transition.

For each row, also record the current owner, administrators, recovery method, billing owner, renewal date, export method, last verified test, and who's responsible after handoff. Don't put passwords in the register — use a credential manager and transfer access through each platform's supported account or role mechanism.

The safe transition, in seven stages

1. Establish authority without changing anything. Confirm the business actually has the contractual and account authority to request access and transfer, and identify who approves the move and who's responsible for each critical account. If ownership is disputed, the first step is contractual, not technical — don't try to seize an account because an invoice was paid. Payment, copyright, account ownership, and permission are related but not interchangeable.

2. Get independent business access. The business should have its own named access to the critical systems — domain and DNS, email admin, the website host, analytics and Search Console, form records and integrations, billing and recovery contacts — rather than borrowing a shared vendor login. Use least-privilege roles where sensible, but make sure at least one business-controlled account can recover ownership if the provider relationship ends. Don't remove the outgoing provider yet; pulling access before the inventory and copies are done turns a manageable move into an avoidable outage.

3. Preserve recoverable copies and evidence. Capture what exists before touching it: a current page/URL and redirect inventory; content, media, database, and source exports where available; the current DNS record set; form definitions and synthetic submission results; analytics, Search Console, and tracking configuration; third-party connections and license dependencies; screenshots of critical states; and current ownership and billing evidence. A backup only earns confidence if someone can say how it would be restored — an unfamiliar file in a downloads folder is not yet a recovery plan.

4. Decide what transfers and what gets rebuilt. Don't promise a "migration" before checking portability and rights. Some things transfer as-is, some export only as content, some licenses stay with the former agency, some custom features depend on private services, and some fonts and images are licensed to a specific vendor or use. Write the disposition for each material item — transfer as-is, export/import, recreate with permission, replace with a supported alternative, retire on purpose, or unresolved pending evidence. This is also where the new designer flags the URLs and content that must be preserved for users and search.

5. Build and test without disturbing the live site. Prepare the replacement in a controlled environment, using synthetic data rather than copied customer records. Test the paths that matter: high-value pages and downloads; mobile navigation and calls; forms with their source records, notifications, and fallbacks; booking or payment connections; analytics and consent behavior; accessibility at the contact path; redirects and error pages; backups and restore; monitoring and alerts. Google's site-move guidance is the reference for the search side — prepare and test the new site, map old URLs to new ones, use permanent server-side redirects where appropriate, keep them in place for a good while, verify Search Console, and monitor the move — and Google's own advice to change one major thing at a time is just as sensible commercially. Changing domain, CMS, layout, email, analytics, and provider all at once makes any failure much harder to isolate. (For the search side in depth, see How to Redesign a Website Without Losing the Search Visibility You Already Have.)

6. Run a controlled cutover with rollback criteria. Before the switch, write down who can approve it, the exact change, what must stay untouched, when it happens, who's watching, the acceptance tests, the failure threshold, who can restore the previous state, and how long the old service stays available. The owner doesn't need to do the DNS work personally — the owner does need to know the person doing it has inspected the real setup, preserved the records, and can reverse the change if acceptance fails.

7. Verify before canceling the old service. Open the live site on real devices and networks. Run synthetic submissions and confirm the source records exist and the notifications arrive. Test business email by sending and receiving through the right accounts. Check analytics and Search Console verification, redirects, maps, phone links, schedulers, payments, and critical downloads. Then watch long enough to catch delayed or intermittent failures. Only once the evidence is good should the business cancel old hosting, licenses, or vendor services — a launch that looks fine is not permission to erase the rollback path the same day.

When the outgoing provider won't cooperate

This is the fear the word "losing" is really about, and most guides skip it. Here's the part that changes your leverage: being the registrant is not the same as holding the login, and neither is the same as having built the site. Sort out which of the three you have before you assume you're stuck.

• If the business is the registered name holder (the registrant of record for the domain), you have real authority even without the designer's help. Under ICANN's Transfer Policy, the registered name holder is the only party that can approve or deny a transfer. You can go to the registrar directly, prove who you are, and recover account access through the registrar's process. You can then request the domain's transfer authorization code (also called the auth code, EPP code, or AuthInfo code) and ask the registrar to remove ClientTransferProhibited. When the registrar does not provide a self-service way to retrieve the code and remove the lock, the current policy gives it five calendar days to do so after the holder's request. The designer's cooperation makes this smoother; it is not strictly required to move a domain you already hold.
• If the designer registered the domain in their own name, that's the real exposure, and it's a contractual and registrar-dispute question, not a technical one. Don't try to seize it. Check the agreement for who was supposed to own the domain, then work the registrar's and (if needed) ICANN's dispute channels. This is exactly the scenario a good contract prevents — see What a Website Design Contract Should Say About Ownership, Access, and Exit.

Two timing facts to plan around. First, transfers can be blocked for 60 days after a domain is first registered, after a prior transfer, and — under current policy — for 60 days after a change of registrant, so if you've just registered or just changed the registrant, budget for the wait rather than being surprised by it. Second, DNS and email can keep working for a while on the old provider's settings even after a relationship sours, which buys you time to inventory and copy before you change anything — use it. Keep everything about the request factual and documented; you want a clean handoff, not an argument about taste. (ICANN has an open proposal that would change some of these lock rules, so re-confirm the current locks before you rely on the exact 60-day figures.)

What to ask the outgoing designer

Keep it specific:

• the list of services and accounts used for the site;
• the platform, hosting, domain, and DNS arrangement;
• which ownership or role transfers the platforms support;
• the content, media, database, source, and design deliverables the agreement requires;
• third-party licenses and whether they transfer;
• form, email-sending, analytics, and integration details;
• known issues and current monitoring;
• backup format and restore procedure;
• recurring charges and what cancellation breaks;
• an agreed access-removal date after acceptance.

Don't ask them to email a spreadsheet of passwords. Ask for named accounts, supported transfers, and secure credential delivery where a direct transfer isn't possible.

What to ask the incoming designer

For a switch specifically (general "how to hire" questions live in Questions to Ask a Web Designer Before You Hire Them), the replacement should be able to explain:

• what can be preserved and what must be rebuilt, and why;
• how email and other DNS-dependent services are protected during the move;
• how URLs and redirects are handled so search and bookmarks survive;
• how forms and lead records are accepted, and where each submission is first saved;
• what exactly changes at cutover, and what rollback means in this setup;
• and — the tell — what the business receives and controls if this new relationship also ends someday.

A confident answer isn't a complete one. Look for an inventory, a sequence, a responsibility map, and receipts.

Red flags that deserve a pause

Pause the transition if nobody can name the registrar or DNS host; if the only recovery email belongs to the outgoing vendor; if the plan starts by changing nameservers before records are inventoried; if the old site will be canceled before the new one is accepted; if "backup" can't be described or restored; if the provider can't explain what happens to business email; if every old URL will redirect to the homepage; if a form is called "tested" because a success message showed up once; if analytics and Search Console will just be "set up again" with no ownership review; if paid licenses are assumed to transfer without checking; if the incoming provider wants one shared master password for everything; or if the move bundles a domain change, redesign, platform move, email move, and tracking rewrite for no stated reason. None of these proves misconduct on its own. Each means the plan is leaning on hope where evidence is available.

The recommendation

Do the switch in the boring order: control, inventory, copies, test, one layer at a time, verify, then cancel. Sort out registrant vs. login vs. builder before you assume the domain is out of reach. And judge the new relationship by the same standard you're using to leave the old one — a good provider hands you a documented path to independence, not a dependency you'll have to fight your way out of later.

That last standard is one a buyer can hold any vendor to, RP included. I hate cancellation games. A provider should not need custody of your domain, DNS, analytics, business profile, or data to keep you as a customer. Those accounts should be yours, and ending the relationship should end the billing instead of opening a scavenger hunt for access. RP's published terms make cancellation one message and return backups and a lead export; I will also work reasonably with a replacement agency, employee, or marketing manager to make the handoff orderly.

The boundary still matters. RP builds custom SvelteKit sites with custom lead handling. Client ownership of the domain, accounts, content, data, analytics, profile, and backups does not mean the assembled implementation can be imported into Wix, Squarespace, WordPress, or another builder. A replacement provider may reuse the portable assets and data, continue operating the custom build if technically able, or rebuild elsewhere. RP owes a clean handoff, not a custom compatibility bridge into somebody else's platform, and migration labor beyond that handoff is separately scoped. Your email hosting and domain registration also remain separate client-controlled accounts; RP operates the site's infrastructure, not your mailbox or registrar login.