--- title: "The platform is rarely the risk. Adoption is." url: https://www.axelerant.com/blog/drupal-adoption-onboarding-marketing-teams published: 2026-09-01T20:10:30.527Z author: "Hetal Mistry, Director Of Global Delivery" (hetal@axelerant.com) lenses: activation source: Axelerant Thinking --- # The platform is rarely the risk. Adoption is. > How we onboard non-Drupal marketing teams: split training by audience, recorded sessions, manuals and runbooks, module inventory, and a structured first four weeks. You chose the platform on architecture. You will be judged on whether the marketing team can publish on it Monday morning. That gap is where most replatforming projects quietly lose their return. The build lands on time, the architecture holds, the Lighthouse scores are good, and then the content team goes quiet. Routine edits start queuing behind engineering again. Six months later somebody asks whether the CMS was the right choice, when the platform was never the thing that failed. Here is the question worth sitting with before you sign anything: if your two most confident editors left next quarter, would publishing stop? ## Where adoption actually fails We have onboarded marketing teams who had never touched Drupal, and teams who had used it for years and lost the people who knew how. The failure patterns are the same in both cases, and none of them are technical. **Rigid templating that keeps engineering in the loop.** One organization we worked with, a national safety association, was running on a legacy CMS with a portal front end bolted to it. Their marketing team could not manage pages with speed or confidence, because a rigid templating system made routine content changes developer-dependent. Every small edit became a ticket. That is not a training problem, it is a content-model problem, and no amount of enablement fixes it after the fact. **A component set named in developer language.** If the editor interface offers "Paragraph type: promo_teaser_variant_b," the team will not use it. They will use the one component they understand and pack everything into it. Structured content only pays off when the structure is legible to the person filling it in. **Training delivered once, live, and never recorded.** Somebody is on vacation. Somebody joins in month four. The person who took the notes changes jobs. A single live session is a decaying asset. **No owner for the publishing process itself.** Teams appoint an owner for the site and forget to appoint an owner for how work moves through it: who drafts, who reviews, who has permission to push live, what happens when the reviewer is out. We watched one prospect, a large community college, reach the point where this becomes existential. They had lost their in-house Drupal engineers and their content team in the same period. The remaining marketing staff were seriously evaluating whether to abandon a perfectly good platform for something easier, not because the technology had failed them, but because the knowledge had walked out of the building and nobody had left anything behind. ## The sequence we run None of this is exotic. It is a sequence, and the discipline is doing all of it rather than the convenient half. **Split training by audience, not by feature.** On the safety association engagement, the commitment was a hybrid training model: separate two-hour sessions, one for the content team, one for the technical team. Same platform, entirely different questions. Content people want to know how to build a landing page and get it approved. Technical people want to know how the deployment works and what happens when a module needs updating. Put them in one room and both groups get a diluted session. **Record everything, then attach it where the work lives.** For that engagement, two sessions ran a few months apart: a portal training and a content authoring and editing session. Both were recorded, and the recordings were attached to the project ticket, not sent as a link in a message that scrolls away. When the fifth editor joins, they watch the same session the first four did. **Write a manual per surface, plus short walkthroughs per module.** We produced two user manuals, one for the public-facing site and one for the member portal, alongside short Loom recordings covering individual areas. Long documents get skimmed once. Three-minute videos get rewatched at the moment of need. You want both, because they serve different moments. **Publish the module inventory.** We prepared a reviewed inventory of every contributed and custom Drupal module in the build, so nothing about the platform is a black box the client cannot inspect. This sounds like paperwork. It is actually what stops the next agency, or the client's own next hire, from treating the site as unknowable and quoting a rebuild. **Walk the technical team through the deployment.** After launch, we hand over the website technical architecture document and take the client's technical team through the deployment process step by step. If the only people who can safely ship are ours, the client does not own the platform yet. **Run administrator workshops separately.** Site administrators have their own job: users and permissions, installing and updating modules, managing data. We run workshops for exactly that group, and follow them with an administrator guide as a standing reference. **Name the follow-up channel before you need it.** Coming out of the workshops, we establish an explicit process for follow-up questions by phone, screen share, or email. "Reach out any time" is not a channel. A named route with a named person is. **Structure acceptance as enablement.** Our better engagements use the same ladder for user acceptance testing that we use for teaching: an async walkthrough video per module, then written questions and feedback from the client team, then a joint working session on that feedback, then a review cycle, then sign-off, then hypercare. Async first, sync where it earns its keep. The useful side effect is that by the time the client signs off, they have already used the thing several times without us driving. ## The first four weeks, shaped This is how we structure the window after go-live. It is a shape, not a guarantee, and we set it with the client rather than presenting it. **Week one, orientation on the content model.** Not a feature tour. A walkthrough of what the content types are, why they exist, and which one to reach for. The vocabulary lesson. **Week two, supervised authoring on real pages.** Not a sandbox. Actual pages the team needs anyway, with us alongside. Sandboxes teach clicking. Real work teaches judgment. **Week three, they publish and we review.** The team ships, we review afterward and feed back. The point of week three is that the client's hands are on the controls and ours are not. **Week four, runbook handover and exit criteria.** The publishing runbook gets finalized with their names in it, and we agree what "done with hypercare" means, so the support window has an actual end rather than fading into a retainer nobody planned. ## What this is worth The business case is unglamorous and easy to verify inside your own organization: routine updates stop queuing behind engineering. When we consolidated more than ten campaign and resource sites for the American Medical Association onto a single governed Drupal 11 platform, editor training, operational runbooks, and a structured hypercare period were part of the delivery, not an afterthought. The reported effects were faster and safer publishing through structured content and reusable components, consistent governance across the properties, and reduced dependency on external agencies for routine updates. Alongside that, desktop Lighthouse scores reached 98 to 100, mobile improved from a 24 to 54 range into 80 to 86, accessibility landed between 95 and 100, and SEO scores stabilized between 92 and 100. There is a personal case too, and it usually matters more to the person reading this. If you are the marketing owner, adoption is the difference between being the person everyone escalates to and being the person whose team simply ships. A platform your team cannot operate makes you a bottleneck, whatever the architecture diagram says. ## Who needs to be in the room Three people, minimum, and we ask for them by role rather than by title. The content owner, because they decide what "good" looks like and they will inherit the runbook. One administrator, because permissions and module updates need a home. One engineer from the client side, because someone on your payroll should be able to read the deployment. If you can name those three, adoption is a plan. If you cannot, adoption is a hope, and the platform decision is riskier than it looks on paper. ## Talk it through If you are planning a move onto Drupal, or you are already on it and the publishing has slowed to the pace of your engineering backlog, we are happy to look at the estate with you and say plainly where the dependency sits. That conversation goes better before the build than after it. If that is where you are, [get in touch](/contact). If your situation is a set of divergent sites rather than a single one, the same adoption question applies at a larger scale, and we wrote about the architecture side of it on our [multisite consolidation](/multisite-drupal-consolidation) page. --- Read on the web: https://www.axelerant.com/blog/drupal-adoption-onboarding-marketing-teams