How to switch web design agencies without losing your site

Switching web design agencies sounds straightforward until your old designer stops replying, your new one discovers proprietary code, or your SEO rankings mysteriously drop mid-transition. Here's how to move your website to a new agency without losing months or money in the process.

Decide whether you actually need to switch

Before you go through the friction of switching web designers, be honest about whether the problem is worth it. A lot of small-business owners blame their designer when the real issue is lack of strategy, outdated copy, or poor promotion.

Common fixable problems that don't require switching:

• Your site "doesn't get leads." That's usually a content problem, not a design problem. If your page doesn't explain what you do or who you help, no designer can fix that with CSS alone.
• Your designer is slow to respond. Send them a formal email outlining what you need and a deadline. Many friction points dissolve once expectations are explicit.
• Your site doesn't rank in search. If you've never done keyword research, built internal links, or written for your audience, replacing the designer won't help. That's an SEO strategy gap.
• "It looks dated." Aesthetics are subjective. If the site still converts customers, a redesign is a want, not a need. Budget for it, but don't rush.

If instead you're experiencing any of these, switching is probably the right call:

• Your designer has gone out of business or is completely unreachable after multiple attempts over weeks.
• You want to move from a proprietary builder (Wix, Squarespace, Weebly) to custom code and can't do it without a new team.
• Your current designer refuses to transfer code ownership or domain access.
• Your site uses integrations or databases that are locked in a vendor platform with no export path.
• You need ongoing CMS editing and your designer charges hundreds per change.

The gap between "slow response" and "gone silent for two months" matters enormously. Only cross to switching web designers territory when the relationship is genuinely broken.

Get your legal house in order first

Before you even approach a new agency, lock down ownership of the assets that actually matter.

Domain name. This is the single most valuable thing you own. If it's registered in your designer's account, request that it be transferred to your registrar immediately, or better, register it yourself on a fresh account at Namecheap, GoDaddy, or a UK provider. You should always retain registrar ownership of your own domain; no designer should control it. (This is non-negotiable, and it's easy to check: log in to your registrar account and see whose name is on the WHOIS record.)

Site source code and database backups. Ask your current designer for a complete export: the code repository (or full file system), database dumps if applicable, and any third-party API credentials (Stripe, Mailchimp, Calendly keys). Get it in writing. If they refuse, and the site was built on a custom platform you paid for, that's a red flag. If it's proprietary builder software (Wix, Squarespace), export what you can, usually content via their backup tools, and accept that some migration friction is unavoidable.

Hosting credentials. You should have account access to wherever the site is currently hosted. If your designer set it up in their account, request admin credentials or a full handover. If they've truly vanished, you might need to request a password reset from the host directly (most will honour a request from the domain owner).

Legal agreement language. Going forward, ensure any new contract includes:

• Your ownership of the final code and design files
• A clause that promises code/domain access if the relationship ends
• An export or handover timeline (suggest 7 to 14 days)
• Clear terms on what "minor edits" or "support" means and what they cost

Sitewright's client terms spell all of this out plainly, so you know where you stand before you start.

Plan the migration timeline and downtime window

Switching web designers takes longer than most people assume, and pretending it won't isn't a plan.

Best-case timeline (for a simple brochure site):

• Week 1: Brief the new designer, hand over assets, new team sets up hosting and development environment.
• Week 2: New team builds the new site (or migrates content to a new platform).
• Week 3: Testing, revisions, final checks.
• Week 4: DNS cutover, go live. Downtime: 5 minutes to 2 hours depending on complexity.

Realistic timeline (most small-business sites):

• Weeks 1 to 2: Gather all assets, sort out missing passwords, negotiate with old designer if they're still semi-responsive.
• Weeks 2 to 4: New designer audits what you have, plans the migration strategy, builds the new site or migrates content.
• Weeks 4 to 5: Testing, broken-link hunting, checking forms and integrations.
• Week 5 to 6: SEO pre-flight checks, 301 redirects set up, database migration if needed.
• Week 6: Go-live window, usually off-hours (weeknight or weekend) to minimise impact on customers.

For complex sites (e-commerce, membership platforms, heavy integrations):

• Plan 6 to 8 weeks minimum.
• Run parallel environments so the old site keeps working while the new one is tested.
• Schedule a soft launch to staff first, then a full launch to the public after 48 to 72 hours of monitoring.

Do not optimistically assume you'll do it in two weeks unless your site is under five pages with no custom integrations. Pressure to rush is how critical elements get skipped, and that's how you lose SEO.

Protect your SEO during the switch

This is where a lot of migrations fail silently. Your site might go live fine, but your search rankings tank because nobody mapped the old URLs to the new ones.

Before the cutover:

• Export a list of every page URL from your old site (use Screaming Frog or a similar crawl tool, most offer free trials).
• Audit your current search visibility: use Google Search Console to see which pages rank, for which keywords, and what their current position is. Screenshot it.
• List every page that currently gets traffic or is indexed in Google.

During the build:

• Ensure your new designer knows which URLs are changing and which ones should stay the same.
• Every old URL that will have a new path needs a 301 redirect (permanent redirect). This tells Google: "We moved this page; update your index." Without it, you lose the ranking authority that page has built up.
• If you're changing platforms entirely (e.g., Squarespace to custom code), the redirect layer is usually the new designer's responsibility, but confirm it upfront.

After launch:

• Submit a sitemap to Google Search Console within 24 hours of going live.
• Check that the top 20 pages from your old site are reachable on the new site (follow the redirect chain).
• Monitor Google Search Console for 4 to 6 weeks: you'll see a small dip in impressions (expected), but it should stabilise within 3 to 4 weeks. If rankings are still dropping after six weeks, something went wrong with redirects or content.
• Check Google Analytics or your preferred analytics platform (you should have one set up beforehand) to spot any traffic anomalies.

Most of the SERP coverage online glosses over redirects or mentions them in passing. They're not optional if you care about search traffic.

Budget for hidden costs and unexpected discoveries

Switching web designers costs more than the new site build alone because legacy systems almost always harbour surprises.

What to budget for:

• Asset extraction fees: If your old designer charges to export your content, database, or code, budget £200, £800 depending on site complexity. Some will do it free as a professional courtesy; others won't.
• Platform migration costs: Moving from Wix to custom code or Squarespace to WordPress involves rebuilding or reimporting most of the site. Budget an extra 20 to 30% on top of your new designer's quote.
• Integration re-plumbing: If your old site has Stripe, Mailchimp, Calendly, or other third-party tools hooked up, the new designer needs to reconnect them. Usually included, but confirm it's in scope before signing.
• Content rewriting: You might discover your old site has inconsistent metadata, missing alt text on images, or weak page copy. Budget for a one-off content audit or rewrite (usually £300, £1,500 depending on depth).
• Downtime impact: If you go down for an afternoon during a migration, you lose potential sales that day. Calculate your average daily revenue and budget a contingency. (This is why migrations usually happen off-hours.)
• Domain transfer fees: Usually free, but some registrars charge £5, £15 to move a domain. Negligible but worth knowing.

For an e-commerce store or membership site with custom databases or recurring payment systems, budget 30 to 50% more because the testing window is longer and any data loss is catastrophic.

Know your options for different platform types

The complexity of switching web designers varies wildly depending on what platform your site currently lives on.

From Wix, Squarespace, or another closed proprietary builder: Your old site is like a locked room. You can export your content (text, images, files), but the design, structure, and integrations don't come with you. Switching means rebuilding from scratch. Budget for a full new build, not a migration. The upside: this is often the cleanest break, and there's no complex technical debt to inherit.

From WordPress: Easier to migrate. WordPress sites are portable: your posts, pages, and plugins can often move to a new host or a new WordPress setup. If your new designer uses WordPress, the migration is straightforward, backup, restore, update plugins. If you're switching to custom code (like Next.js), content needs to be extracted and reimported manually or via API. Plan 2 to 3 weeks extra.

From custom code or a bespoke build: This is where switching gets intricate. If your old site is built in Next.js, Django, or Shopify, every integration, custom feature, and database schema needs to be audited. Your new designer needs to understand what the old one built. Ask for code documentation. If there isn't any, budget an extra 1 to 2 weeks for reverse-engineering. This is also where escrow or source-code access becomes critical, if you don't have the code, you're stuck renting.

Execute the handover and monitor post-launch

The actual moment of switching web designers is usually anticlimactic if you've prepared properly.

One week before go-live:

• Confirm all redirects are set up and tested.
• Run a full broken-link check on the new site.
• Test all forms, payment buttons, and integrations on staging (not production).
• Brief your team on what's changing and where to find things in the new site.

On go-live day:

• Update your DNS to point to the new hosting provider. (This usually propagates within minutes to 2 hours globally.)
• Monitor uptime and page load times for the first hour.
• Check that contact forms are working and emails are reaching you.
• Spot-check key pages in an incognito browser to confirm the old cache isn't serving the old site.

Week 1 to 2 post-launch:

• Check Google Search Console daily for crawl errors or indexation issues.
• Verify your top-traffic pages are still getting traffic in Google Analytics.
• Monitor customer feedback, are people confused by the new layout or broken links?
• If you spot issues, your new designer should be covering bug fixes as part of the handover (most reputable agencies guarantee 30 days of post-launch support).

Weeks 2 to 6 post-launch:

• Continue monitoring search console. Rankings might drop 10 to 20% temporarily; that's normal and usually recovers.
• Update any internal documentation or training your team uses to reference the site.
• Once you're confident the new site is stable, formally close the project with your new designer.

The most common failure is not monitoring the first two weeks carefully enough. Most silent problems (redirects not working, a form that emails to the wrong address) show up in those early days and are easy to fix if you catch them.

The key to switching web designers without losing your site is treating it like a proper project: plan the timeline, secure your assets upfront, protect your SEO, and monitor the handover closely, not something to rush through in a week or hope someone else is handling.