Drupal Discovery Workshop

Drupal Migration Services: A Discovery Workshop That Reads the Whole Codebase, Not a Sample of It

The reason Drupal migrations get scoped wrong is not that anybody was careless. It is that reading an entire Drupal estate by hand costs more hours than a discovery budget contains. So a consultant opens the twenty modules that look most likely to matter, forms a reasonable view, and estimates from it. The surprises that blow the budget are in the modules nobody had time to open.

Most Drupal migration services quote off that partial read. A Drupal build scoped on a sample is a six-figure commitment resting on it. This engagement is one to two weeks, fixed fee, and produces a build-ready plan any Drupal migration services team can quote against — ours or somebody else's — and the reason we can audit exhaustively inside that window is that we do not do the reading by hand. We stopped doing it by hand on our own Drupal work first.

Book Your Drupal Discovery Workshop

We run this audit against our own Drupal estate, continuously

Facet has built on Drupal since 2014, and we maintain Drupal sites for clients under a managed web service. Our own engineering — including that maintenance work — runs through Agent Loops under human command, which changed what a technical audit is in a way that is specific to codebases and does not generalize.

A codebase is exhaustively machine-readable in a way a business process is not. The module inventory, the patch state, the deprecated API calls, the contrib-versus-custom split, every call site of every integration, the content type and taxonomy structure, the actual field usage across real content — all of it is literally in the repository and the database. The week a senior engineer used to spend on discovery was never judgment. It was reading, under a time limit, which is why it was a sample.

So three things are true of how we run this, and they are the reason the engagement is shaped the way it is:

The audit pass is routine here, not bespoke. The same inventory, deprecation and dependency checks run continuously across the Drupal sites we maintain. Your discovery is not the first time the checklist gets exercised, and it is not being written for you from scratch while you pay for it.
Exhaustive replaces representative. Every module gets inventoried, every integration call site gets found, every content type gets counted against real usage. The risk register is built from the whole estate rather than from the part somebody had time to look at, which is the difference between a plan and an informed guess.
A named engineer still makes every judgment. Agents produce the inventory and the deprecation findings. A Facet engineer decides what those findings mean, which migration path they argue for, and what goes in the estimate. Nothing in the plan is machine-generated and shipped unread.

The longer account of how the operation works is in We Run Our Own Business on Agents.

Why hire a Drupal discovery partner before you build?

Because Drupal migrations fail at the planning stage far more often than at the implementation stage, and the failures are all the same shape: something in the old build that nobody documented turns out to be load-bearing.

Budget overruns arrive mid-project. The original estimate was built on assumptions. Discovery replaces assumptions with facts, and the gap between the two is where change orders live.
Timeline slips through dependency cascades. Integrations, content migrations and custom module dependencies that were not mapped create rework that spreads. Discovery maps the full chain before anybody commits to a date.
Platform regret is a decade-long mistake. Choosing Drupal, or ruling it out, without a real technical audit is a decision the business lives with for years.
Developers working from a brief solve problems in build time. A question discovery answers in an hour costs a day of project time when it surfaces in sprint four, and it costs it with the whole team waiting.

Build your own version of the number. Count your contributed modules, your custom modules, and your third-party integrations. Then count how many of the custom ones have no test coverage and no original author still at the company. (Illustrative arithmetic on your own inputs, not a benchmark: if your build estimate is $120,000 and three under-documented integrations each turn into a change order worth five percent, that is $18,000 — comfortably more than the discovery that would have found them.) Run it with your own figures; the shape of the answer usually survives.

How could AI agents run your Drupal discovery? Book the Drupal Discovery Workshop — one to two weeks, fixed scope, against your real codebase. You leave with a full technical audit, a risk register, a dependency map, a content migration scope and a grounded effort estimate — and the plan is yours to execute with any partner.

What the loop actually does

The audit passes below are agent-carried for one reason: each is exhaustive, mechanically checkable against a known standard, and finds nothing on most items. That is precisely the work a person does well for two days and then starts sampling.

Inventory every module and its state. Contrib versus custom, version, patch status, abandoned upstream projects, and which ones are actually enabled on production rather than merely installed.
Find every deprecated API call. Across custom modules and themes, mapped to the Drupal version you are targeting, so the refactoring work is a list rather than an estimate.
Trace every integration to its call sites. SSO, CRM hooks, payment gateways, marketing platforms, webhooks and scheduled jobs — located in code rather than reconstructed from memory in a stakeholder interview.
Profile the content against its structure. Content types, fields and taxonomies counted against real usage, so the fields nobody has populated since 2019 are visible before somebody scopes migrating them.
Map the redirect surface. Every published URL, its traffic, and what it would become under each candidate architecture.
Check the infrastructure assumptions baked into the old build. File paths, cron dependencies, PHP version constraints and hosting-specific behaviour that will not follow the site to a new environment.

What a person still decides

The audit produces facts. Every decision that follows from them is made by a Facet engineer with your team in the room.

Which migration path the findings actually argue for. In-place upgrade, rebuild, headless or hybrid is a judgment weighing your technical constraints against your timeline, your editorial team's habits and what you intend to build next. It is not a score.
What moves, what gets restructured, and what finally gets retired. A migration is the only realistic opportunity to stop carrying something. Using it is a business decision about content and features, and it is worth more than most of the technical scope.
What the estimate says. Effort and timeline come from an engineer reading the audit, not from a model extrapolating line counts. A number nobody is willing to defend in a room is not an estimate.
Which risks are worth mitigating and which are worth accepting. Every risk register contains items that are cheaper to live with. Saying which is the experienced part of the job.

What you get from the workshop

A structured, time-boxed engagement — typically one to two weeks of focused work — producing a build-ready migration plan. Not a proposal. Not a discovery process that runs for months. A document your team can execute against.

Full Drupal technical audit. Current version, module inventory, custom code, content architecture, database structure, integrations and hosting, documented as they actually are rather than as a generic estimate would assume.
Risk register. Every identified risk with likelihood, impact and a mitigation path, so you know what is complex before you are paying to untangle it.
Dependency map. Everything the Drupal environment touches, mapped, so nothing is scoped as "TBD".
Content migration scope. Volume, structure, taxonomies, media, redirects — what moves, what gets restructured, what gets retired.
Hosting and infrastructure recommendation. Where the new environment lives, how it is architected for performance and reliability, and what the operational overhead looks like at scale.
Effort and timeline estimate. Grounded in the technical assessment rather than a templated range.
Agentic operating model blueprint (optional). If you want the site to run as Agent Loops after launch — automated content workflows, continuous performance monitoring, proactive maintenance — the second week includes an initial blueprint for how that would be structured. The architectural decisions that make it possible are cheapest to make now and expensive to retrofit, which is the only reason it belongs in a discovery deliverable at all.

What a replatform costs marketing, and where that gets scoped

The risks a marketing leader owns in a Drupal migration are different from the ones the engineering team is worried about, and they are routinely scoped last — which is how a technically successful launch turns into a quarter of explaining a traffic drop.

The redirect map is the whole ballgame for organic traffic. Every URL that changes needs a rule, and the ones that matter most are usually old pages with durable rankings that nobody on the project remembers. The audit produces that list from the actual URL inventory and its traffic, rather than from the site map somebody drew in a workshop.
Measurement continuity breaks quietly. Analytics tags, event tracking, conversion goals and CRM form handoffs are typically reimplemented during a rebuild, and a subtly different implementation produces a discontinuity in your reporting that looks exactly like a performance change. Scoping it as migration work rather than post-launch cleanup is the difference.
Content architecture decides what marketing can do afterwards. The content types and taxonomies chosen during migration set what is possible to publish, filter and personalize for the next several years. That is a marketing decision being made inside a technical document, and discovery is when it should be argued about.
Editorial workflow is a requirement, not a preference. If the new build makes publishing slower than the old one, it will be worked around, and the workaround becomes the architecture. We interview the people who publish, not only the people who build.

How the workshop runs

Week one — assessment and stakeholder alignment

The technical picture and the business requirements are built simultaneously, because each one changes what matters in the other.

Codebase and content audit. The automated passes run across the full installation while Facet engineers review the findings and pursue what looks unusual.
Stakeholder interviews. Content editors, developers, marketing leads and operations — the requirements that do not live in code, including the exceptions that exist in one person's head.
Migration path analysis. Available approaches evaluated against your technical constraints, timeline and business requirements, with a recommendation and the reasoning behind it.
Integration mapping. Every external system that touches Drupal: APIs, webhooks, data flows, authentication, and the migration sequence each one requires.

Week two — plan delivery and review

Build-ready migration plan. Recommended path, work breakdown, sequenced phases, content migration approach and infrastructure specification.
Risk register and mitigation playbook. Categorized, quantified where honestly possible, each paired with a mitigation.
Effort and timeline estimate. Derived from the assessment, defensible line by line.
Live walkthrough. We present to your technical and business stakeholders, take the arguments, and revise before the plan is finalized.

Where the Drupal discovery workshop goes next

A ladder, not a bundle. A discovery that produces a plan you execute elsewhere is a complete outcome.

Drupal Development — the build itself, if you want Facet to execute the plan. Discovery is credited against the project cost when we do.
Web MSP — the managed run layer after launch: maintenance, security patching, performance and content operations.
Discovery Workshop and Requirements Engineering & Discovery — the broader versions, for initiatives that are not Drupal-specific or where the ambiguity is about the process rather than the platform.
Agentic Engineering and AI Managed Services — the rungs above, for when the site is a surface for agents doing operational work rather than an asset to be maintained. That is what the optional blueprint is scoping toward, and the Agentic Operating System explainer covers the shape while those service pages are in production.

Why Facet

Facet Interactive has been a boutique systems integrator since 2014, and Drupal has been one of our core platforms for that entire time, alongside WordPress and Laravel. CIOReview named us a Top 10 Digital Transformation Services Company in 2021. Our 40-person team across 9 timezones and 6 continents, plus a network of 500+ open-source specialists, includes engineers who have run Drupal builds, major version migrations and custom module development across professional services, healthcare-adjacent verticals, law firms and non-profits.

We are open-source centric by design. Drupal is not a platform we pull out occasionally — it is one we maintain in production, which is why the audit checklist exists before your project does.

Start with a Drupal discovery workshop

How could AI agents run your Drupal discovery? Book the workshop — one to two weeks, fixed scope, against your real codebase. You leave with the technical audit, the risk register, the dependency map, the content migration scope, the infrastructure recommendation and a grounded estimate. Priced as a fixed-scope project; Facet's project range starts at $6,000 and a discovery for a mid-complexity environment sits at the low end of it. For Facet-led migrations the discovery fee is credited against the build.

Sometimes the audit argues against the migration. If the findings show your current Drupal installation is healthier than you think — that the problem is three specific modules and an editorial workflow rather than the platform — the plan will say so, and the recommendation will be a much smaller piece of work than the one you came in asking to scope. That answer costs us a migration. It is also the one that most often turns out to be right when a site "feels" like it needs replacing.

The only line on a build budget that pays off if you never hire us

Everything else you are about to buy is contingent. The build only has value if the builder is competent and stays engaged. The hosting only has value while you are hosting there. The support retainer is worth exactly what it is worth in the month you are paying for it.

A discovery deliverable is not like that, and it is the only part of the project that is not. The audit of your own codebase, the dependency map, the risk register and the redirect inventory are facts about your estate. They are true whoever executes the build, they survive you changing your mind about the platform, and they remain useful if you shelve the project for a year and pick it up with a different team. That is why we hand the plan over unconditionally rather than gating it behind the build — the deliverable is not a sales instrument, and pretending otherwise would make it a worse document.

Which gives you an unusually clean test to run on any discovery engagement you are considering, ours included: ask whether the output is yours to take elsewhere. A partner who hesitates is selling you a proposal with an audit attached.