How to Choose an Enterprise Drupal Partner in 2026

Choosing an enterprise Drupal partner is a test that agencies pass with ease. A pitch process rewards the skills of pitching: a clean deck, familiar logos, and a case study that sounds close enough to your situation. None of that predicts what happens in month seven of a migration or at 2 a.m. during an incident.

I have been in a lot of these pitches from the agency side. The pattern I keep seeing is that the criteria buyers weigh most heavily are the ones every credible agency has already rehearsed an answer for.

What follows is what I would tell a buyer to look for.

What Separates a Drupal Partner Who Delivers from One Who Presents Well?

A Drupal partner who delivers shows a solution to your problem. A partner who presents well shows capabilities. The difference is visible in the pitch itself, before any contract exists.

Anyone can walk into a room with case studies and logos. In more than 200 launched platforms, we have found that the strongest start is to learn the client's real needs and pain points first, sometimes in advance and sometimes on the call, and then show how we would solve them.

That means real Drupal demos and prototypes built for the pitch. If a client says translation workflow is the problem, the useful answer is not a slide about a multilingual project we delivered for someone else. It is getting under the hood and showing how we would handle their workflow.

The red flag is an agency that spends the pitch on how good the agency is. Capabilities, awards, and client logos can fill an hour without touching your problem. When a vendor does not talk about your pain points and business needs, that tells you something about how the engagement will run.

So push prospective vendors to demonstrate against your requirements. A custom demo that shows exactly how a partner would solve what you need is a signal a case study cannot give you.

What Should a Credible Drupal Migration Plan Include at the Proposal Stage?

A credible Drupal migration plan shows a content mapping model, a redirect strategy, a manual cleanup plan, and realistic resourcing, all before anything is signed. A proposal that promises to move everything one-to-one using a set of APIs is not a plan.

At the proposal stage, expect a partner to be able to show:

• A mapping model. What changes structurally between the old site's content types and the new ones.
• A 301 redirect strategy. A 301 is a permanent redirect that sends an old URL, and the search ranking attached to it, to its new address. Ask specifically how redirect mapping will be handled, not for a note that redirects will be preserved.
• A manual cleanup plan. Where content will not map one-to-one, usually because a component on the new site does not exist on the old one.
• Realistic effort and resourcing. Content discovery, the build, content population resources, and QA, each with the effort behind it stated.
• A client training plan. Who gets trained, on what, and when.
• Content freeze and code freeze procedures. The agreed points at which no new content or code changes are accepted before cutover. Agree them in advance, not during the cutover week.

What you are testing is not migration tooling. It is whether the partner has thought through the phases, where the risk sits in each one, and whether the resourcing behind the timeline is real.

Our own answer to this is the Vardot Delivery System: Align, Blueprint, Accelerate, Assure, Operate. The point is not the names. It is that the phases, the risk in each, and the resourcing behind them exist on paper before you sign.

Where Do Drupal Managed Support Relationships Usually Go Wrong?

Drupal managed support relationships usually go wrong over three things that were agreed in the sales conversation and never defined precisely: scope, staffing, and ownership.

• Scope limited to break-fix. Support is written to cover fixes only, which quietly excludes feature requests, enhancements, and anything discovered along the way. Every request outside that boundary then becomes a negotiation.
• A retainer sold but not staffed. When the agency has not resourced the retainer properly, context has to be rebuilt every time, onboarding repeats, and the relationship churns.
• No named owner for security patching or escalation. Nobody defines who monitors advisories, who applies the patch, and who is called when it goes wrong. That gap only surfaces during an incident.

We went deeper on this in a previous piece, 10 Questions to Ask Before Signing an Enterprise Drupal Support SLA, covering the escalation tree, the scope matrix, and how the weekly Drupal security advisory cycle should be written into an agreement.

How Can You Tell Whether a Partner Will Leave Your Team Able to Run the Platform?

You can tell from three things: the documentation, the contrib-versus-custom decisions, and when training happens. Each is observable during the engagement rather than after it.

• Documentation specific to your implementation. Not generic Drupal documentation, but a written account of how your platform was actually built and why.
• Drupal core and well-maintained contributed modules over custom code. Contributed modules, or contrib, are the community-maintained extensions published on Drupal.org. When an implementation leans on the standard ecosystem, the whole community maintains that surface area, and you own the result. That is the practical case for open source, not the philosophical one. When it leans on a custom one-off, one agency does, and you are tied to them.
• Hands-on training during the build. Documentation is good, and training after handover is good, but co-developing with the client team while the platform is being built is what leaves them able to run it. Training treated as an afterthought at the end tends to stay an afterthought.

What Makes Choosing an Enterprise Drupal Partner Different in 2026?

Two things changed this year that were not decisive two years ago: a fixed Drupal 10 end-of-life date, and an authoring layer being rebuilt around AI. A third thing changed the calendar around both, which is where the EU AI Act comes in.

Image

What Should You Ask About Drupal 10 End of Life?

Ask for the partner's methodology for managing end-of-life versions, their upgrade process, and what is included for future upgrades in the scope of your engagement.

Drupal 10 reaches end of life on December 9, 2026, the same week Drupal 12 is scheduled to ship, per the Drupal core release schedule. Major versions cannot be skipped, so a Drupal 10 site has to move to Drupal 11 first. Drupal has not yet published the minimum Drupal 11 version required for the jump to 12, but the upgrade documentation notes that core update paths before 11.3.0 have been removed in Drupal 12, so treat 11.3 as the practical floor when you plan.

An upgrade planned a year out, and an upgrade forced by an expiring security window are different projects with different budgets. Which one you end up running is decided at scoping.

What Counts as Evidence of Real AI Capability in Drupal?

Concrete implementations count. Theory does not.

Drupal Canvas, built under the working name Experience Builder, is now a stable contributed module bringing drag-and-drop page building and AI-assisted authoring into Drupal. Its current stable release requires Drupal 11.3 or higher.

That version requirement ties the upgrade question to the AI question. A site still on Drupal 10 cannot run any of this until the upgrade is done, which makes a partner's upgrade methodology and their AI roadmap the same conversation rather than two.

So ask a prospective partner how they are using AI integrated with Drupal to improve content creation, development, and delivery. Then ask for client examples where they have actually implemented it. Innovation you can point at is different from innovation you can describe, and this is where Drupal is going.

Applied to us, the same standard: the Gold Sponsor listing in the Drupal AI Initiative is a credential, which by the argument above is the cheap part. The part you can inspect is Varbase AI, the editor assistant and AI agent tooling we build and publish on Drupal.org.

Where Does AI Governance Fit into Partner Selection?

AI governance belongs in the conversation, and a partner should be able to work alongside you on governance, compliance, and policy. It is also the part of the answer that is least likely to distinguish one agency from another.

The regulatory picture moved twice inside a week, which is worth knowing before you weigh anyone's claims. The EU AI Act's Article 50 transparency obligations became enforceable on August 2, 2026, covering disclosure that a user is interacting with an AI system and machine-readable marking of AI-generated content. The high-risk obligations did not arrive alongside them: the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force six days earlier on July 27, 2026, and moved standalone Annex III high-risk requirements out to December 2, 2027. Annex III is the AI Act's list of high-risk use cases in areas such as employment, education, and access to essential services.

For a Drupal platform running a chatbot or AI-assisted authoring, Article 50 is the live question. Which obligations attach to your organization depends on whether it counts as a provider of the system, meaning you developed or branded it, or a deployer, meaning you operate it under your own authority. The timing splits too: systems placed on the market on or after August 2, 2026 are covered from that date, while systems already on the market before it have until December 2, 2026 to meet the content-marking duty under Article 50(2).

None of that is legal advice, and your counsel owns the classification. But a partner who can work through which obligations land on your deployment, and who carries them, is telling you something a policy document cannot.

The Questions Every Agency Answers Well Are the Ones That Tell You Least

Here is where we land after a lot of these processes. The fluency of an agency's answer tends to run opposite to how much that answer tells you.

Every credible partner has a ready response to "do you document your work," "do you follow Drupal best practice," and "do you have an AI governance policy." Those questions are necessary. They are also the cheapest things on the list to claim, which means the shortlist arrives at the final round undifferentiated on exactly the criteria that were supposed to differentiate it.

The criteria that actually separate partners are the ones that cannot be settled with a sentence. A mapping model is a document, or it is not. A named security-patching owner exists in a scope matrix or does not. A client example of AI running in production is either something a partner can walk you through or something they change the subject about.

So the evaluation only works if you convert each criterion from a question into a request for an artifact. That conversion is the whole method.

Which Three Questions Should You Put in a Drupal RFP?

Three questions tend to produce answers that most agencies struggle with, which is what makes them useful.

1. Describe a project where your technical approach went wrong. How did you find out, and how did you course-correct? A real answer indicates honesty and technical depth rather than sales polish. The willingness to name a project that went off the rails is itself the signal.
2. Where would you refuse to design or build something, and why? This tells you whether a partner will push back on requirements that are not right, or build whatever is specified and invoice for it.
3. If we ended this engagement, would we be able to stand on our own feet without you? This forces real answers about implementation quality, documentation, and knowledge transfer. You want a long-term partnership, but budgets change, and agencies get acquired. You need the ability to pivot.

The red flag, on the first question especially, is a vendor who talks around it or will not give you an example. Either they are not being fully honest, or the problems are real, and they have no good way to fix them. I have seen the second one.

How Should You Score a Drupal Partner?

Score a Drupal partner by what they can put in front of you, not by what they confirm. The table below converts the standard evaluation questions into artifact requests.

Enterprise Drupal partner evaluation: question versus artifact

Anything a vendor cannot produce during the evaluation is unlikely to appear later under delivery pressure.

Run Your Shortlist Through This

If you are building a shortlist of enterprise Drupal partners, put the three RFP questions to every agency on it, and ask each one for the artifacts in the table above rather than the assurances. And ask each one for the mapping model, the scope matrix, the documentation sample, and the production AI example.

And if you want the standard applied to us: send us the problem you are actually trying to solve, and we will build the demo against that instead of sending a capability deck.