Enterprise Drupal Managed Services: Built for Complex Sites

By the time a complex Drupal site reaches my team, it almost always works. It loads, it demos well, and the content team can publish. That is usually the problem.

Many enterprise Drupal projects we take on are inherited. So the first job in an enterprise Drupal-managed services engagement is not development. It is finding out what "working" is hiding, because the decisions that put a complex site at risk tend to be invisible at the level most stakeholders see.

What follows is how I think about that complexity, the architectural mistakes I see most often, and what a CTO should weigh before handing a Drupal estate to any vendor, including us.

What Actually Makes a Drupal Environment "Complex"

The signals I look for are about how far an environment has moved from Drupal out of the box.

A few patterns reliably point to a complex project:

• Heavy customization. The further a build sits from standard Drupal and contributed modules, the more it costs to keep running.
• High traffic and the infrastructure decisions that have to come with it.
• A large number of user roles and editorial workflows.
• Drupal Commerce in the mix.
• A multisite architecture and content sharing mechanisms.
• AI features and integrations, which add new categories of governance, data, and oversight requirements.
• Heavy Integration with External Systems.

Image

Then there is integration, which is where most enterprise complexity actually concentrates. Large projects rarely stand alone. They connect to external systems, and the two that come up most often in our work are Salesforce, usually as the CRM, and ERP platforms. Front-end integration, where Drupal serves a separate presentation layer, adds its own category of difficulty.

The Architectural Mistakes That an Audit Surfaces

When we take over a project, we start with a full site audit. An audit of the things that do not show up in a functioning website: security posture, performance under load, SEO health, and whether the architecture can carry the growth the business is planning. We treat these as non-functional requirements, and they are part of a build most likely to have been skipped.

The most common mistake is also the most generic: too much custom code for problems that did not need it. A small tweak gets written as a bespoke module instead of a configuration change or a contributed module. Each of those decisions is defensible on its own. Together they produce an estate that is expensive to maintain and that nobody but the original developer fully understands.

The fix is rarely more custom code. It relies on community-contributed modules wherever they can do the job. When a module is maintained by the wider Drupal community, its bug fixes and security support come with it, and the maintenance load sits with the community rather than with your team alone. Bespoke code is where that load quietly builds up, which is why we treat it as the exception rather than the default.

The bigger mistake is treating non-functional requirements as launch-day concerns. Scalability, security, and performance are architecture decisions. If they are not designed in from the start, retrofitting them once the site is live is slow and expensive. Most of the instability we find traces back to an architect who underestimated growth: more traffic than planned, more features than scoped.

Why a Site That "works" Can Still Be the Wrong Site

Here is where I land, and it is not a comfortable position to sell.

A site that functions is not the same as a sound site. The two get confused constantly, because functioning is visible and soundness is not. A stakeholder sees the pages load and concludes the build is fine. An audit sees a multilingual homepage that cannot actually be translated, or an architecture that will not hold up as traffic grows. None of that shows up from the front end.

Image

That is why I do not treat the audit as a formality. Its entire purpose is to surface what "working" hides, before that gap becomes a production incident.

One project makes the point. An enterprise client came to us late, close to launch, expecting a review and a green light. The honest finding was harder than that: fixing the existing build would have taken longer than rebuilding it. We could have run the narrow audit, signed off, and let them launch on schedule. That would have met the deadline and put an unstable, unscalable site into production.

We rebuilt it instead, from scratch, under the original deadline, using a phased launch: an MVP covering the core menu pages first, then the rest. And it worked. The site launched, the client met their marketing goals, and the relationship continued into ongoing support.

The lesson is not that rebuilds are good. The lesson is that the build-or-rebuild decision should be driven by what an audit finds, not by what a launch date wants to hear. Letting an unstable site go live to protect a deadline is not a standard we are willing to work to.

Choosing an Enterprise Drupal Managed Services Partner

Two questions sit underneath this decision: whether to run a complex Drupal estate in-house or with a partner, and how to choose that partner.

Build vs. Buy

Build versus buy is usually framed as a cost comparison, and that framing is incomplete. The hard part of running a complex Drupal estate in-house is not headcount. It is that the work needs a multidisciplinary team, and assembling the team is the easy half. Building a repeatable process around it, for releases, security response, and ongoing support, is the half that takes years.

Finding the talent is its own constraint. ManpowerGroup's annual Talent Shortage survey has put the share of IT employers struggling to fill skilled roles at roughly three in four. In-house can look cheaper in the short term. Across a multi-year support horizon, a partner that already has the team and the process is usually the more sustainable choice.

I run an agency, not an enterprise IT department, so treat the in-house side of this as an outside read. If Drupal is core to your product and you can fund a standing team and the process around it, keeping it in-house is a defensible call.

Evaluating a Provider

If you are hiring a managed services partner, here is what I would weigh hardest, roughly in order:

• Proof of work. A portfolio that shows the industries and the type of complexity the vendor has actually handled, not just a wall of logos.
• Development Process and Standards
• DevOps and CI/CD Maturity.
• The team's CVs. As a technical buyer, I want to see who will do the work, not only who sells it.
• Financial stability. You are entering a multi-year relationship. The vendor still needs to be there for it.
• Drupal.org presence. Contributions and certifications are a visible signal that the team works inside the Drupal community rather than around it.
• Documented security standards. Adherence should be written down and demonstrable, not asserted in a sales call.

None of this requires hiring an agency. A CTO with the right team and a real process can run a complex Drupal estate well. But if you are inheriting an environment you did not build, or weighing whether to keep one in-house, the most useful first step is the same one we start with: an honest audit of what the site is hiding. That is where the real decision becomes visible.

Jose Bajawi is a System Architect at Vardot with over 15 years of experience building enterprise-grade web applications on Drupal. He specializes in designing scalable, high-performance architectures that power complex digital ecosystems across non-profit, corporate, and e-commerce sectors. At Vardot, Jose leads technical strategy and infrastructure planning, ensuring robust security, seamless integrations, and optimized delivery workflows. A regular contributor to the Drupal community, he believes in open-source innovation and maintainable code.