How to switch web design agency without breaking your website

How to switch web design agency without breaking your website comes down to ownership, access and timing. Before you give notice, confirm you own the code, content, domain and hosting accounts, and that you have working credentials for each. The transfer itself is then a project management exercise, not a technical rescue.

Clients who come to us mid-switch are rarely there because the new agency is bad. They’re there because the old one held more of the website than anyone realised. A clean switch starts months before the conversation about leaving does.

Why do agency switches go wrong?

Most painful agency switches fail for one reason: nobody documented the build, nobody handed over credentials properly when the relationship started, and the institutional knowledge lives in one developer’s head at the outgoing agency. When the relationship sours, that knowledge stops flowing.

We’ve taken on many inherited builds, and the patterns repeat. Hosting account is in the agency’s name and on their payment card. DNS is parked on someone’s Cloudflare. The Stripe webhook points at a service nobody can find documentation for. The CMS has been extended with plugins, some of which aren’t on the public WordPress repository, and at least one of which is a paid licence registered to an email address that nobody can access.

None of that is unusual. It’s the default state of a website that’s been maintained by one agency for several years. Nobody set out to lock the client in. They just never thought about offboarding.

Even a friendly transition has friction. Plan for it.

What should you check before giving notice?

Audit your access before you start any conversation about leaving. Log in to every account yourself, today, with credentials in your own name. Once an agency knows you’re going, cooperation often slows, and you lose the room to push for access you should have had from day one.

The audit covers seven areas:

• Domain registrar. You should hold the login for whoever registered your domain (Cloudflare Registrar, Namecheap, GoDaddy, etc.) and the domain should be in your organisation’s name, not the agency’s.
• DNS provider. Often the same as the registrar, often not. Cloudflare is common.
• Hosting account. Whether it’s a shared host, a managed WordPress host or a VPS, you should be the account holder or have access to the control panel.
• CMS super-admin. You should have full administrator access to WordPress, CraftCMS, BigCommerce, Shopify or whatever the site runs on, or be able to easily obtain it.
• Code repository. GitHub, GitLab, Bitbucket. Ideally, you should have access to the repository that holds your site’s source code.
• Email and DNS records. If your business email runs off the same domain, the MX, SPF, DKIM and DMARC records all need to be visible and changeable from your DNS dashboard.
• Third-party services. Stripe, Chargebee, Mailchimp, Klaviyo, Google Analytics, Google Search Console, Tag Manager, CDN, error monitoring, uptime monitoring. If any of these are connected to the agency’s account rather than yours, that’s a gap to close.

Who owns your website code and assets?

Under UK law, copyright in commissioned work belongs to the creator unless the contract assigns it to the client. The Copyright, Designs and Patents Act 1988 sets that default, and most agency contracts modify it, though not all of them do it cleanly. Depending on the wording, you may have a perpetual licence to use the site without the right to take the code and modify it elsewhere.

Pull out the contract. Look for three things.

First, IP assignment. A good contract says the client owns the bespoke work outright on payment of all fees. A weaker contract grants a perpetual licence to use but keeps copyright with the agency. A bad contract is silent, in which case the statutory default applies, and the agency holds the rights.

Second, source code delivery. Some agencies treat source code as a deliverable; others treat the compiled, deployed site as the deliverable and keep the source in their own repository. The latter could be a problem if you want to leave.

Third, third-party components. Some builds rely on commercial plugins, themes or frameworks with licences that are non-transferable, or that the agency holds on behalf of multiple clients. You may need to buy your own licences as part of the move.

If ownership is ambiguous, request a written assignment as part of offboarding. Many agencies will sign one in exchange for clearing any outstanding invoices. This is a normal commercial conversation, not a confrontation.

What should be in the handover pack?

A complete handover pack is a list of specific artefacts, not a list of promises. Get the list in writing and confirm receipt of each item before the final invoice is paid.

A workable handover pack covers:

• Full source code repository with the complete commit history, transferred to a repository under your account
• Latest production database export, plus a copy of the staging database if there is one
• Documentation of the build covering architecture, any custom modules or plugins, and any non-obvious decisions
• Every third-party service the site depends on, with credentials transferred to accounts in your name
• DNS records exported, with notes against any non-obvious entries
• SSL certificate details (provider, expiry, auto-renewal status)
• The deployment process written down, even if it’s a one-line ‘git pull on the production server’
• All scheduled tasks: cron jobs, background workers, queue processors
• Licence keys for any commercial plugins, themes or modules, and confirmation that licences are transferable

The deployment documentation is the item most often missing. A site that ‘just works’ until someone needs to deploy a change is a site with hidden complexity, and that complexity will surface at the worst possible moment.

For larger builds, ask for a 30-minute video walkthrough of the architecture from the lead developer at the outgoing agency. That single call can save your new team days of code archaeology, and it’s a small ask for the outgoing agency once invoices are settled.

How do you transfer hosting and the domain?

This is where the technical risk sits, and where calm sequencing makes the difference between an invisible cutover and a weekend of downtime. The pattern is the same on most platforms: stand the site up on new hosting first, test against staging, then point DNS at the new server during a quiet window. The steps, in order:

1. Your new agency stands up the site on the new hosting at a staging URL. The site is fully working there, with a copy of the production database, before anything else changes.
2. You test everything. Forms, payment, search, login, account areas, third-party integrations, transactional email, anything that touches an external service. Don’t skip the unglamorous things like password reset emails. They’re the ones that get missed.
3. You schedule a low-traffic cutover window. For a B2B site, that’s usually a weekend morning. For an ecommerce site, it’s whenever your data says is quietest, and never during a campaign or seasonal peak.
4. The day before cutover, lower DNS TTLs on the records you’re going to change. This means the change propagates faster when you flip it.
5. At cutover, you update the relevant DNS records (typically A or CNAME for the apex and www) to point at the new hosting. Force a sync of the live database one last time if there’s been activity on the old site.
6. You monitor for 48 to 72 hours. Real-user monitoring, error logs, transactional email deliverability, payment success rates. Then put TTLs back to normal.

A separate point on the domain itself: don’t transfer the registrar at the same time as the hosting if you can avoid it. For .com and other ICANN-governed domains, a recent registrar transfer or registrant change can trigger a 60-day transfer restriction under ICANN’s Transfer Policy. Some registrars allow an opt-out before a registrant change; others do not. If you do need to combine moves, lower DNS TTLs in advance and stage everything so the worst case is recoverable.

For .uk domains (including .co.uk), the process sits under Nominet rather than ICANN. Check your registrar’s Transfer Authorisation Code process and any registrar-set lock before you schedule the move.

When is the right time to switch?

Pick a quiet commercial window and budget two to four weeks of overlap where both agencies are still being paid. The overlap fee is cheaper than a failed cutover.

Quiet looks different by sector. Ecommerce: avoid Q4, Black Friday, January sales and any product launch window. Schools: avoid August, term-start week and admissions deadlines. Charities: avoid major appeal periods and your peak fundraising months. Professional services: avoid year-end and the run-up to your busiest billing month.

Don’t try to save the last month of retainer at the cost of a botched migration. The maths is bad. A retainer is a few hundred to a few thousand pounds; a weekend of downtime on a transacting site could be materially more, and a slow handover that drags out for three months costs more again in management time.

What about your maintenance and hosting retainer?

Maintenance retainers usually have a notice period; 30 to 90 days is a common range, but check yours before serving notice because the specifics matter. Make sure your new arrangement is in place before the old one ends. A gap of even a fortnight in security patching, plugin updates and uptime monitoring can be enough for something to break.

Audit what your current retainer actually covers. Some are ‘hours-only’ arrangements where the agency does dev work on request and nothing else. Others are full-stack: hosting, security patching, plugin and core updates, daily backups, uptime monitoring, performance work, and a guaranteed response time for incidents. Whatever yours includes, your new maintenance and support retainer needs to cover the same surface area or you’ll find the gap the first time something breaks.

The other useful exercise: pull out the last 12 months of support tickets or change requests. The pattern in there tells you what your real workload is, which tells you what shape your new retainer should take.

What are the red flags during the transition?

A clean handover follows a predictable pattern. If your outgoing agency behaves outside that pattern, take it seriously and start documenting in writing.

Specific things to watch for:

• A refusal to hand over credentials, framed as a security concern. Security is a reason to hand credentials over carefully, not to keep them.
• ‘We can give you the code but not the database’, or any version of separating the two. Code and data go together. A site is not a site without both.
• New invoices appearing for services not previously discussed. Anything outside the existing contract is open to negotiation, not a fait accompli.
• Insisting that your incoming agency contact them via formal legal channels for normal technical detail. This is sometimes used to slow the process down.
• Offers to extend the contract on materially worse terms in exchange for cooperating with the handover. Decline politely and continue with the handover regardless.

If any of these appear, write everything down. Send confirmations of conversations by email afterwards. Before paying any agreed final offboarding invoice, have your incoming agency confirm the handover pack is complete. If there is a dispute, follow the contract and take legal advice before withholding payment. If you have a solicitor or in-house legal, copy them in early. Most of the time the situation resolves quickly once it’s clear you’re keeping a paper trail.

What does a broken agency switch actually look like?

The worst outcomes from a botched switch aren’t dramatic; they’re slow. The signs are forms that started failing six weeks ago and nobody noticed, a drop in organic traffic because redirects were missed, payment receipts that stopped going out, or an accessibility regression that surfaces in a complaint three months later.

This is the case for taking the move slowly, paying for overlap, and doing the boring testing work properly. A migration that nobody noticed is a successful migration. A migration that looks impressive but loses organic search visibility is not.

If your switch is also a rebuild rather than just a relocation, our piece on how ecommerce website costs break down in the UK is a useful reference point for budgeting.

Want a second pair of eyes before you sign anything off?

We’re Parrot Creative, and we take on inherited builds regularly. Schools, ecommerce stores, B2B platforms, sites where the previous agency has gone quiet, and the documentation is whatever happened to be in the website folder structure. If you’re considering a switch and want a second opinion on the handover pack before final invoices are paid, get in touch. A short call before you serve notice is usually the cheapest part of the whole project.