Switching Web Development Agencies: A Handover Checklist That Protects Your Site

Most businesses do not switch web development agencies on a whim. They switch because releases keep slipping, invoices keep growing while the backlog does not shrink, the original developer has moved on, or every small change to the site seems to break something else. By the time the decision is made, the relationship is often strained, and that is exactly when a handover is most likely to go wrong.

The short answer to the question most people are searching for: yes, you can change web development agencies without losing your site, your rankings or your data, but only if you secure access and ownership first, take a full inventory before notice is given, run a short technical audit with the new team, and plan a transition period instead of a hard cut-over. Done in that order, a switch is a managed project rather than an emergency.

This guide walks through that process step by step, with checklists you can use directly, typical timelines and cost ranges, and the warning signs that tell you whether a switch is the right call at all. It applies whether your site runs on WordPress, WooCommerce, Laravel or a custom stack, and whether you are a business owner or an agency replacing a subcontractor.

First, decide whether switching is actually the fix

Changing partners has a real cost: onboarding time, a learning curve on your codebase, and some risk during the transition. Before you start, separate problems caused by the agency from problems caused by the setup around it. A new team will not fix a vague brief, an unowned backlog or a budget that funds two days a month for a site that needs ten.

Signs that the partner is the problem, rather than the process:

Estimates are consistently wrong in one direction and nobody can explain why, even after you have tightened requirements.
You cannot get straight answers about where code lives, how deployments work or who has access to production.
Quality issues repeat. The same categories of bugs return after every release, and there is no testing or staging process to catch them.
Key people have left and the remaining team is learning your project on your time.
The technology no longer fits. Your needs have moved from a brochure site to a store, a portal or a SaaS product, and the agency does not have that depth.
Ownership is unclear or withheld. Accounts are registered in the agency's name, or source code is treated as theirs.

Signs that a reset conversation might be enough:

The issues started after a scope or budget change that was never formally agreed.
Requests reach the agency from several people with conflicting priorities.
Nobody on your side reviews work or answers questions within a reasonable time.

If you recognise the second list, try one structured review meeting first: agree the top five priorities, a single point of contact on each side, and a delivery rhythm for the next six weeks. If things do not improve, you will switch with better documentation of what you need, which helps the next partner too.

The risks of a badly handled switch

It is worth naming what can actually go wrong, because each risk maps to a step in the checklist below.

Lost access. Domain, DNS, hosting or code repositories registered under the outgoing agency's account, leaving you unable to make changes or, in the worst case, unable to keep the site online.
Missing or outdated code. The repository does not match what is running in production because changes were made directly on the server.
Broken integrations. Payment gateways, CRMs, ERPs, email services and webhooks that depend on API keys stored in someone's personal account.
SEO damage. Accidental noindex tags, lost redirects or changed URLs during a rushed rebuild or re-platform.
Data exposure. Former contractors who still hold admin passwords, SSH keys or database credentials months after the relationship ended.

None of these are rare. It is common to find at least one critical account that is not owned by the client, and that is usually fixable in an afternoon if it is discovered early rather than after notice has been served.

Step 1: Read your contract before you say anything

Start with the paperwork. You need to know what you own, what notice you owe and what the outgoing agency is obliged to hand over. Look for:

Intellectual property clauses. Does ownership of code and designs transfer to you on payment, or does the agency retain rights and license them to you? Are there pre-existing components the agency keeps?
Notice period and termination terms. Retainers commonly carry 30 to 90 days' notice. Fixed-price projects may have milestone-based exit terms.
Handover or transition obligations. Some contracts require the agency to provide documentation and a set number of transition hours; many say nothing at all.
Outstanding invoices. Disputes over unpaid work are the most common reason an agency becomes slow to hand over. Settle or formally document anything outstanding.
Confidentiality and non-solicitation clauses that might affect hiring individual developers from the outgoing team.

If the IP position is unclear or the contract is silent on handover, it is worth a short review by a lawyer before you give notice. This guide is practical advice, not legal advice, and the stakes are higher if your site generates most of your revenue.

Step 2: Secure access and ownership while the relationship is still working

This is the single most important step, and it should happen quietly before notice is given. Your goal is that every critical account is owned by a company email address you control, with the agency added as a user rather than the other way round.

Access and ownership checklist

Domain registrar. The domain should be registered to your company, with your contact details and a login you hold. Enable registrar lock and two-factor authentication.
DNS provider. Often separate from the registrar (for example a CDN or DNS service). Export the full zone file as a backup.
Hosting or cloud account. Server, managed WordPress host or cloud provider billing account in your name, with the agency as a team member.
Code repository. The GitHub, GitLab or Bitbucket organisation should belong to you. If the code sits in the agency's organisation, ask them to transfer the repository or grant you owner access and push a full mirror with all branches and tags.
CMS admin. At least one administrator account for your company in WordPress, WooCommerce or your custom admin panel.
Third-party services. Payment gateways, transactional email, analytics, Search Console, tag manager, CRM, marketing automation, maps and other API providers.
Licences. Premium themes, plugins, Composer or npm packages, fonts and stock assets, ideally re-licensed or transferred to your account.
Backups. Confirm where backups are stored, how often they run, and that you can download one yourself today.

Once ownership is in your hands, download a full backup of files and database and store it somewhere the outgoing agency cannot touch. That copy is your insurance policy for everything that follows.

Step 3: Take a complete inventory of what you have

Access tells you where things are. An inventory tells you what they are and how they connect. Ask the outgoing agency for as much of this as they have, and fill the gaps yourself or with the incoming partner.

Technical inventory checklist

Environments: production, staging and any development servers, with URLs and hosting details.
Stack: CMS or framework and version, PHP or Node version, database engine, caching layers, CDN and search services.
Deployment: how code reaches production, whether there is a CI/CD pipeline, and who can trigger it.
Custom code: themes, plugins, modules or packages written specifically for you, and where their source lives.
Third-party plugins and packages: names, versions, licence holders and why each one is installed.
Integrations: every external system the site talks to, which direction data flows, and where credentials are stored.
Scheduled jobs: cron tasks, queue workers, imports, exports and automated emails.
Known issues: open bugs, technical debt the agency is aware of, and anything they would warn a successor about.

Step 4: Run a technical audit with the incoming partner

At SquartUp, every takeover starts this way. A good incoming agency will not quote for ongoing work, a redesign or a list of features until they have looked at the codebase. Treat the audit as its own small, paid engagement with a fixed scope and a written deliverable. It protects you from a partner who promises the world without understanding what they are inheriting, and it gives the new team a realistic starting point.

A useful handover audit typically covers:

Code and production parity. Does the repository match what is live, or have changes been made directly on the server?
Security posture. Outdated core, plugins or packages, exposed credentials in code, weak admin practices, and missing security headers.
Performance baseline. Core Web Vitals, server response times, page weight and obvious bottlenecks such as unindexed database queries.
Maintainability. Code structure, test coverage, use of version control, and how hard routine changes will be.
SEO foundations. Indexation, sitemap, robots rules, redirects, canonical tags and structured data, recorded so they can be protected later.
Risk register. The top issues ranked by impact, with a recommended order of work.

For a typical WordPress or WooCommerce site, an audit like this usually takes one to two weeks and often falls in the range of USD 800 to 3,000. For a custom Laravel application or a store with several integrations, two to four weeks and USD 2,000 to 6,000 is a more common range. The exact figure depends on codebase size and how much documentation exists. If you want a rough sense of what follow-on work might cost, our project cost estimator gives a quick range before you speak to anyone.

Step 5: Give notice and agree a transition plan

With access secured, an inventory in hand and an incoming partner lined up, you can give notice from a position of control. Keep the message professional and specific: when the engagement ends, what you need handed over, and how many transition hours you expect to pay for.

What to request from the outgoing agency

Transfer or confirmation of all accounts listed in Step 2.
A final push of all code, including unmerged branches and any work in progress.
Database and media exports from production and staging.
A list of credentials they hold, so you can rotate them after handover.
A written summary of open tasks, known bugs and anything unusual about the setup.
One or two recorded walkthrough calls with the developer who knows the codebase best.

Paying for a small block of transition time, typically 5 to 20 hours, is usually money well spent. It turns a reluctant handover into a paid deliverable and gives the outgoing developer a reason to answer the incoming team's questions properly.

Step 6: Run a parallel period, then cut over

Avoid a hard switch where one team stops on Friday and the other starts on Monday. A short overlap lets the incoming team ask questions while answers are still available, and lets you verify that nothing depends on knowledge only the old team had.

A practical transition sequence looks like this:

Set up the new team's environment. The incoming partner clones the repository, restores a database copy and gets a local and staging environment running from your backups, not from the old agency's servers.
Freeze non-urgent changes. For one to two weeks, only critical fixes go to production, which makes it easy to spot anything that breaks.
Ship one small, low-risk change. A copy edit or minor bug fix, deployed by the new team through the new process. This proves the full pipeline works end to end.
Move hosting if needed. If you are changing hosts, migrate to a staging copy first, test thoroughly, lower DNS TTL in advance and switch during a quiet traffic window.
Rotate every credential. Admin passwords, SSH keys, API keys, database users and deploy tokens. Remove the outgoing agency from every account once the overlap ends.

Protecting SEO and revenue during the switch

Changing who maintains a site should not, on its own, affect search rankings. Rankings drop when the switch is combined with a rushed rebuild, a re-platform or careless server changes. Keep the two decisions separate where you can: stabilise first, then improve.

Record a baseline before anything changes: top landing pages, ranking keywords, organic traffic by page and conversion rates.
Crawl the live site and save the full URL list, titles, meta descriptions and canonical tags.
Export the existing redirect rules from the server, CMS plugin or CDN.
For stores, place test orders through every payment method and shipping option after any infrastructure change.
Monitor Search Console and analytics daily for the first two weeks after cut-over.

If a redesign or re-platform is part of the plan, we cover that process in detail in our guide to protecting SEO rankings during a website redesign.

Typical timelines and costs

Every handover is different, but these ranges reflect what is common for small and mid-size businesses. They assume the outgoing agency is at least moderately cooperative; an uncooperative exit can add several weeks.

Site type	Typical transition time	Typical handover cost range	Main risk areas
Brochure or marketing WordPress site	1 to 3 weeks	USD 500 to 2,500	Account ownership, plugin licences, redirects
WooCommerce store	3 to 6 weeks	USD 1,500 to 6,000	Payment and shipping integrations, order data, performance
Custom Laravel application or SaaS product	4 to 8 weeks	USD 3,000 to 12,000	Undocumented business logic, queues and jobs, test coverage
Site with ERP, CRM or marketplace integrations	6 to 10 weeks	USD 5,000 to 15,000	Data sync, API credentials, scheduled imports

These figures cover the audit, environment setup, transition hours and stabilisation work. They do not include new features, a redesign or remediation of serious problems the audit uncovers. Budget a contingency of around 15 to 25 percent for surprises, because inherited codebases almost always contain a few.

How to choose the right incoming partner

The agency you switch to should be comfortable inheriting someone else's work. Many teams prefer greenfield projects and quietly push for a rebuild because it is easier for them, not because it is better for you. Ask direct questions:

How often do you take over existing codebases? Look for a clear onboarding process, not enthusiasm alone.
What does your audit deliver? You want a written report with prioritised risks, not a sales call.
When would you recommend a rebuild versus incremental improvement? A thoughtful answer weighs cost, risk and business goals rather than defaulting to "start again".
How do you document your work? Ask to see a sample README or handover document from a past project, with client details removed.
What happens if we part ways with you later? A partner who has a ready answer to this question is one that respects your ownership.

Our broader guides on how to choose a web development agency and questions to ask before hiring a software agency go deeper on evaluation criteria if you are still shortlisting.

A note for agencies replacing a white-label subcontractor

If you run a design or marketing agency and the partner you are replacing is a behind-the-scenes development subcontractor, the same steps apply with two additions. First, your end client must not notice the switch, so the transition plan needs a communication buffer: keep client-facing timelines conservative during the overlap. Second, check that client accounts were never created under the subcontractor's details, because your client may have no idea who the real account holder is.

The incoming partner should work under your brand from day one, use your project management tools, and follow your client communication rules. This is the model we use for our white-label WordPress and WooCommerce development work, where agencies keep the client relationship while we handle engineering and maintenance.

Frequently asked questions

Can a web agency refuse to hand over my website?

It depends on your contract and on who registered the accounts. If you own the domain, hosting and repository, an agency has little practical leverage. If accounts are in their name or invoices are disputed, a handover can stall. Securing ownership early avoids most of these situations; where there is a genuine dispute, get legal advice.

h3>Should we rebuild the site when we switch?

Usually not immediately. Most sites can be stabilised and improved incrementally, which is cheaper and lower risk. A rebuild makes sense when the audit shows the platform cannot support your goals, security issues are structural, or maintenance costs exceed what a rebuild would cost over two to three years.

h3>What if the original developer has disappeared completely?

It is still recoverable. Start with whatever accounts you can access, usually the domain registrar and hosting through your billing details, then take a full server backup. An experienced team can reconstruct a working repository and development environment from a production copy, although it adds time to the audit.

Switching agencies is a project, so run it like one

A smooth handover comes down to sequence: read the contract, secure ownership, inventory everything, audit with the new team, agree a paid transition, run a short overlap and then rotate every credential. Skip the order and you risk downtime, lost data or a stand-off over access. Follow it and most switches are uneventful, which is exactly what you want.

SquartUp takes over existing WordPress, WooCommerce and Laravel projects for businesses and agencies, starting with a fixed-scope audit so you know what you are inheriting before committing to anything larger. We have delivered 50+ projects for 25+ clients across 12+ countries. Browse our services to see how we work, or tell us about your current setup and we will outline what a safe transition would look like for your site.

Start a project with SquartUp Back to blog