Unhappy With Your Drupal Agency? Switch Without Rebuilding
Teams stay with agencies they have outgrown because they assume leaving means rebuilding. If you hold your code, database, and infrastructure, it usually does not.
Key Takeaways
- Switching is an access problem, not a code problem. Code, database, and infrastructure decide it.
- With that access, changing agencies is closer to replacing a developer than starting over.
- Access rights are settled in the original contract, long before any unhappiness sets in.
- A rebuild is cheaper only when the version gap is wide, as with Drupal 7 to 11, or most functionality is broken.
Switching your Drupal agency rarely requires rebuilding the site. As long as you hold access to your code, database, and infrastructure, a new agency can take over the existing build, much like replacing one developer with another. A full rebuild becomes the cheaper path only in specific cases, such as migrating a long-unsupported Drupal 7 site to Drupal 11.
What's Really Behind Unhappiness With a Drupal Agency?
Most unhappiness with a Drupal agency traces back to three things: communication, planning, and quality. When any of these slips, everything else tends to follow.
For sites still being built, the friction usually shows up as missed deadlines, weak project planning, a lack of transparency, and a client with no clear view of progress. The work may be underway, but the client has no clear view into it.
For sites that are already live, the trigger is different. The complaints we inherit are about support: slow response times, mishandled requests, and communication that breaks down when something needs fixing.
Across the platforms we've taken over at Vardot as a Drupal Diamond Certified Partner with 200+ launched sites, this pattern is consistent, and the technology is rarely the first thing that pushed the client to leave.
Does Switching Your Drupal Agency Mean Rebuilding From Scratch?
Switching your Drupal agency does not mean rebuilding from scratch in most cases. The client decides the path, and that decision usually falls into one of three patterns.
Some clients arrive wanting a clean rebuild because they're unhappy with the whole site and want a new one. Others are satisfied with where the site is but carry a backlog: new features to add, issues to fix, updates to apply. A third group simply wants dependable support after a bad experience elsewhere.
None of those three requires throwing away the existing build. As long as you hold access to your current site, switching agencies is closer to replacing one developer with another than to starting over.
What Does a Proper Drupal Handover Look Like?
A proper Drupal handover begins with a technical meeting and ends with you holding the codebase, databases, and infrastructure access. Done well, it follows a clear sequence:
- A technical meeting with the outgoing agency, your own technical team, or both.
- A walkthrough of the site and its infrastructure, so the incoming team understands how it's built.
- Transfer of the assets: codebase, databases, and access to the infrastructure and servers.
These assets transfer cleanly when the client already holds the access, which, in practice, comes down to what the original contract allowed. When the access rights are in place, the handover is administrative, not a reconstruction.
What Makes a Drupal Site Easy or Hard to Take Over?
The size and complexity of a site's functionality is what makes a Drupal site easy or hard to take over. Most sites sit on the easier end.
Content-display sites (typical school, university, and organizational sites) are mainly about presenting content rather than running complex operations, so taking them over is usually straightforward. Difficulty climbs with third-party integrations: a site wired into a CRM such as Salesforce, or any external system, takes more care to inherit.
The hardest takeovers are commerce sites, where a transaction layer makes the work critical. Any mistake or misread requirement on a commerce handover carries a direct cost, so every step, requirement, and business rule has to be understood before the transition.
Our View: Switching Agencies Is an Access Problem, Not a Code Problem
Our view at Vardot is that whether you can switch Drupal agencies cleanly is decided by access and contracts, not by your site's code. This is the part teams tend to get backwards.
The instinct is to fear the rebuild: years of content, a working site, and the dread of handing it to strangers who start over. But the actual gating factor is whether you own access to your code, your database, and your server, and that's usually settled at the original contract, long before any unhappiness sets in.
This is the quiet advantage of an open-source platform: the code, the data, and the configuration are yours to take. There's no proprietary lock to negotiate around.
The real risk isn't a rebuild; it's discovering you can't easily retrieve your own assets.
When you do hold that access, the leverage shifts to you. Moving to a new agency becomes the same kind of event as a developer leaving and another taking their seat. It's continuous, not catastrophic.
How to Switch Drupal Agencies Without a Rebuild
To switch Drupal agencies without a rebuild, secure access to three things from your current agency before you leave:
- The source code: your complete codebase.
- The database: the content and configuration that make the site what it is.
- The infrastructure: server access, or a clear path to move the site if it's hosted on the agency's servers.
Once you hold the code, the database, and the server, the site can be moved, maintained, enhanced, or rebuilt anywhere you choose. That access is what turns a feared migration into a routine transfer.
When Does a Rebuild Actually Cost Less Than a Fix?
A rebuild costs less than a fix when the existing site is too outdated or too broken to repair efficiently. In our experience, two situations make rebuilding the cheaper path:
- A long-unsupported version. A site still on Drupal 7, which reached end of life on 5 January 2025 and no longer receives security support, usually costs more to upgrade to Drupal 11 than to rebuild fresh, because the version gap is so wide.
- Mostly broken functionality. When most of a site's features don't work, or don't work as intended, diagnosing someone else's code and tracing every fault costs more than building it correctly from the start.
Takeover vs. rebuild: which path fits your site?
| Take over and patch the existing site | Rebuild from scratch |
|---|---|
| You hold access to code, database, and infrastructure | The site runs a long-unsupported version (e.g., Drupal 7 → Drupal 11) |
| The site is fundamentally sound, with a backlog of fixes or features | Most functionality is broken or doesn't behave as needed |
| The goal is ongoing support, upgrades, and enhancements | The repair or upgrade effort would exceed the cost of building fresh |
What Are Your Options if You're Unhappy With Your Drupal Agency?
Being unhappy with an agency doesn't commit you to the most expensive option on the table. If you want a clean rebuild, that's a plan. If your site is sound and you need a backlog cleared, enhancements made, or steady support with updates and bug fixes, that's a plan too, and it keeps the work you've already paid for.
The first move isn't choosing between them; it's confirming you hold access to your code, database, and infrastructure. From there, every path stays open.
Ready to Switch Drupal Agencies?
Whether your Drupal site needs a backlog cleared, an upgrade, or a fresh build, Vardot can take over the existing site and map the lowest-cost path forward, with no rebuild assumed.
And we'll review your access, your current site, and your options before you commit to anything.
FAQs
Switching Drupal agencies does not mean rebuilding from scratch in most cases. As long as you hold access to your code, database, and infrastructure, a new agency can take over the existing build. A rebuild only becomes the better option in specific cases, such as migrating a long-unsupported version like Drupal 7 to Drupal 11, or when most of the site's functionality is broken.
Before leaving your current Drupal agency, secure access to three things: your source code, your database, and your infrastructure (the servers, or a clear path to move the site if it's hosted by the agency). Whether you can obtain these usually depends on what your original contract allowed. Once you hold all three, the site can be moved, maintained, or rebuilt anywhere.
You will not lose your content when you switch Drupal agencies, provided you have access to the database that stores it. Content and configuration live in the site's database, so transferring database access carries your existing content to the new agency intact. This is why securing database access before you leave is one of the most important steps in a clean switch.
A Drupal site takeover starts with a technical meeting involving the outgoing agency, your technical team, or both, followed by a walkthrough of the site and its infrastructure. The incoming agency then takes the codebase, databases, and infrastructure access. When the client already holds these access rights, the assets transfer cleanly and the handover is administrative rather than a reconstruction.
Rebuilding a Drupal site is cheaper than fixing it when the site is too outdated or too broken to repair efficiently. The clearest case is a site on Drupal 7, which reached end of life on 5 January 2025; upgrading it to Drupal 11 often costs more than a fresh build because the version gap is so wide. A rebuild also wins when most of the site's functionality is broken or doesn't work as intended.