AI-First Drupal Managed Services: The First 90 Days
Hamza Al Jundi
June 11, 2026
Updated on:
June 11, 2026
The first 90 days of AI-First Drupal Managed Services are diagnostic, not feature-building. Vardot audits the codebase, hosting, CI/CD, and accessibility in roughly the first week, stabilizes the site before adding features, and uses AI to structure content under human governance. By day 90, success means regression-free deployment cycles and no single-person dependencies.
When a Drupal site is handed to us on day one, the first thing we do is not fix anything. We diagnose. That surprises most clients, and it is where the first 90 days of an AI-First Drupal Managed Services engagement quietly decide everything that follows.
This is the window where the project is understood, the real risks surface, and the plan to fix them is set. For a VP of Technology evaluating a managed services partner, knowing what it actually contains is the difference between realistic expectations and disappointment by week three.
The first 90 days of AI-First Drupal Managed Services are diagnostic, not feature-building. Vardot spends roughly the first week auditing the codebase, hosting, CI/CD, and accessibility, then stabilizes the site before adding features. AI structures content under human governance. By day 90, success means steady, regression-free deployment cycles and no single-person dependencies.
What Day One Of A Drupal Managed Services Handover Actually Looks Like
On day one, we don't test or fix. We establish what we are dealing with. Before building any test environment or writing a single test case, we check:
Accessibility, and whether the staging and production environments are functioning properly
What the codebase was built on, whether Drupal or another CMS
The hosting setup
Whether the site is connected to a CI/CD pipeline
The sitemap
Only once that picture is complete does the testing and fixing work begin. Skipping it means making decisions blindly, and on an inherited system, that is where the expensive mistakes come from.
The Biggest Misconception Clients Have About A Site Takeover
The most common misconception, when a partner like Vardot takes over a site, is that improvements should appear immediately. They can't. Before we change anything, we have to understand the business, its users, and whether the existing documentation matches both our understanding of the site and what is actually running in production.
Stability comes before features. If a site crashes every ten minutes, there is no value in building a new feature, however useful it would be for the business, until the crashing is resolved. We stabilize first. In practice, the first visible results of managed services tend to arrive two or three releases later, after those underlying issues are addressed.
The initial audit takes roughly a week, after which we prepare an initial report and share it with the client. Some fixes need the client's approval and support before we can proceed, which can extend the timeline. From our side, though, one week is enough to kick off the work.
Image
How We Introduce An AI-First Methodology To A Site That Wasn't Built For It
The friction here almost always comes from content structure. AI works best with structured, clear, and stable content. Most legacy websites were not built for the AI era, or for what real users now expect.
When we take over a site like that, we lean on the structural strength of Drupal, and in Varbase, our enterprise Drupal distribution, that structure is built in from the start. We take the existing data, analyze it, and map how it is interconnected. Then we begin the AI work, using AI to help build better-structured content for the site.
As a Drupal AI Initiative Gold Sponsor, we take a structured approach to AI adoption in managed services. Our methodology is AI-first but human-governed, meaning AI is used to assist decision-making rather than operate independently. In practice, we use a multi-agent workflow where one model analyzes and interprets a project’s codebase to produce structured context, and a second model uses that output to support downstream tasks such as documentation, planning, or content structuring. This orchestration improves onboarding speed for unfamiliar systems and reduces the risk of incorrect assumptions, while maintaining human oversight at every stage.
Image
What Success Looks Like On Day 90
Resolved tickets and a functioning website are part of success, but they are not the measure of it. By day 90, success looks like:
Steady deployment cycles at fixed intervals, whether weekly, twice weekly, or biweekly, with no regressions
Regressions from the start of the project are automated away, so they cannot quietly return
No dependency on any single person, with the whole team able to carry out any related task
A clear, documented workflow stable enough that AI can be brought in to help plan the next cycle of work
As a Drupal Diamond Certified Partner, with 200+ launched platforms, this is the standard we hold ourselves to.
Closing tickets is the floor. A predictable, regression-free delivery rhythm that no longer depends on one individual is the actual goal.
Where The First 90 Days Most Often Go Sideways, And What Recovery Looks Like
This usually happens in week two or three. By then, we know where the dependencies are, what integrations exist, and where those integrations are weak. We also know what the stakeholders are expecting, and that is often where expectations and reality collide.
A common example: a client expects a feature delivered by week three, but in week two, we discover the foundation it would sit on is not stable. Rather than build on it anyway, we prepared a demo for the client showing the weakness and the impact it would have going forward.
Another recurring problem is undocumented integrations. When existing integrations have no documentation, we read the code line by line to understand what is happening, and we make assumptions that may turn out right or wrong. That keeps the picture uncertain until around week five or six, because recovering and understanding the existing system matters more than anything else at that stage.
One case makes the point. We took over a site whose most important content type appeared to be working, but not properly. It behaved the way the client had asked it to. The engagement was a short-term project to add new features, but after auditing and testing, we found that this content type would break the new features being requested. We didn't sweep that under the rug. We shared the facts with the client and ended up rebuilding the content type properly.
What A VP Of Technology Should Know Before Buying AI-First Drupal Managed Services
If you are evaluating an AI-First Drupal Managed Services partner, three things are worth understanding before you sign:
The start will be slower than you expect. We need to analyze the site thoroughly: how it was functioning, what the business needs are, the state of the code handed to us, and your expectations and aspirations for the site.
The value: Better decisions, fewer surprises, and a roadmap based on evidence rather than assumptions.
The most consequential risks are usually hidden. They have to be found and fixed before optimizing for anything else.
The value: Reduced operational risk, improved stability, and lower long-term maintenance costs.
Collaboration at the start matters more than most teams assume. Your speed of response after the first meeting and the initial report sets the speed of our development. The faster you respond to an identified risk, the faster we can fix it.
The value: Faster issue resolution, shorter delivery cycles, and quicker realization of business value.
None of this is the exciting part of a managed services engagement. It is the part that determines whether everything after it holds.
If you are inheriting a Drupal site or rethinking who maintains yours, the first 90 days set the trajectory for everything that follows.
Hamza Al-Jundi is QA Technical Lead at Vardot, with 8 years in software quality and manual testing and 10 years in automation engineering across commercial enterprises and non-profits. He holds a Master's from Middle East University, where his research applied machine learning to bug severity detection. His automation work spans Selenium, Appium, Cypress, and Playwright, backed by ISTQB certifications including CTFL, Agile, Mobile, CTAL-TAE, and CTAL-TM (ASTQB certified). Hamza is the creator of two open-source tools for the Drupal ecosystem: Varbase Test Recorder, which generates Playwright test specs from browser interactions, and Drupal Documentation Writer, which auto-generates user manuals from a project's configuration. Connect with Hamza on Linkedin
The first week is an audit, not a fixing phase. Before building test environments or writing test cases, the incoming team assesses the codebase, hosting setup, CI/CD pipeline status, accessibility, sitemap, and whether staging and production environments function properly. An initial report is then shared with the client, since some fixes require client approval before work can proceed.
Typically two to three release cycles. The most common client misconception is that improvements appear immediately after handover. In practice, the vendor must first understand the business, verify that documentation matches what is running in production, and resolve stability issues. A site that crashes regularly gains nothing from new features, so stabilization precedes feature work.
The main friction is content structure, since AI performs best with structured, stable content most legacy sites lack. The approach maps how existing data is interconnected, then uses AI to help build better-structured content. Vardot applies a multi-agent workflow where one model analyzes the codebase to produce structured context and a second model supports documentation, planning, or content structuring, with human oversight at every stage.
By day 90, success means steady deployment cycles at fixed intervals with no regressions, early regressions automated away so they cannot return, no dependency on any single team member, and a documented workflow stable enough for AI-assisted planning of the next work cycle. Closing tickets is the floor, not the goal; a predictable, regression-free delivery rhythm is the actual measure.