You need a digital partner that champions your goals and goes beyond ticket-based managed services.

Drupal is the open-source content management system; Acquia is a commercial digital experience platform built on top of it. Drupal itself carries no licence fee. Acquia sells the managed platform and the products around the CMS — Cloud Platform, Site Factory, Site Studio, DAM, CDP, Personalization, Campaign Studio, and web governance.

Most enterprise teams buy Acquia for the hosting posture and the DXP layer, then still need someone to own the Drupal application running on it. CXOntology works across both layers — the Drupal application and the Acquia products around it — which is why our engagements start at that boundary rather than at the ticket queue.

Drupal 10 reaches end of life on 9 December 2026. Drupal 10.6 is the last minor release; after that date no further Drupal 10 releases are published, including security releases.

Drupal 12.0.0 and Drupal 11.5.0 are scheduled for the week of 7 December 2026. For reference, Drupal 7 reached end of life on 5 January 2025 and Drupal 9 on 1 November 2023. Dates come from the Drupal core release schedule and can move.

CXOntology plans Drupal 10 to 11 moves as a managed roadmap — contributed-module audit, custom-code remediation, staged release — rather than a single cutover close to the deadline.

For most teams on Drupal 10, moving to Drupal 11 first is the lower-risk path. The two-year major cycle is designed so that 11 → 12 behaves closer to a minor upgrade than a migration.

Waiting means doing both steps at once, under end-of-life pressure, while contributed modules are still catching up. The variable that sets your timeline is contrib and custom-module compatibility — rarely core itself.

CXOntology starts with a compatibility audit across every contributed and custom module, so the upgrade window is set by evidence rather than by the calendar.

No. Drupal runs on Acquia, Pantheon, Upsun, AWS, Azure, and self-managed infrastructure. Acquia is chosen for the managed Drupal platform, its compliance posture, and the DXP products that sit around the CMS.

The hosting choice does change who absorbs platform risk — which in turn changes what a support agreement needs to cover. CXOntology supports Drupal on Acquia and on other platforms, and scopes the support model to the risk the hosting layer leaves behind.

Acquia Source is Acquia’s unified workspace for content, digital asset management, web governance, and AI agents. Acquia announced its next evolution — and launched Acquia AI inside it — at Acquia Engage Denver on 28 April 2026.

Acquia AI lets teams build and deploy purpose-built agents from a browser without code. Acquia has said MCP-compatible agents, including Claude, Cursor, and GitHub Copilot, will integrate with Source in a future release.

CXOntology’s AI and agentic practice helps teams decide which of these capabilities earn their place in the operating model, then engineers the workflows and governance around the ones that do.

Our Drupal and Acquia managed services cover core and module updates, security patching, release management, Acquia Cloud coordination, performance tuning, monitoring, accessibility remediation, integrations, and ongoing enhancement work.

The dividing line worth checking in any proposal: does the plan only keep the site online, or does it also move the backlog forward?

CXOntology scopes both. A pod carries engineering, front-end, DevOps, data, and QA as one unit, so run work and growth work are delivered by the same team against one backlog rather than handed between them.

Acquia supports the platform and hosting layer. The Drupal application on top of it is not covered by platform support.

That means custom modules, front-end code, the content model, integrations, the release workflow, and the business outcomes sit outside Acquia’s remit.

That gap is what CXOntology owns. We hold the application layer, coordinate with Acquia on the platform layer, and make the seam between them explicit in the delivery governance rather than discovering it during an incident.

Yes, and it is how most CXOntology engagements start. We begin with an audit of the codebase, contributed modules, environments, deployment process, security posture, analytics, and backlog.

From there we stabilise the estate first, then publish a practical roadmap separating run, fix, and growth work. Inheriting an unfamiliar codebase is a normal condition of managed services, not an exception to price around.

CXOntology works across Drupal and the Acquia ecosystem: Cloud Platform, Site Factory, Site Studio, Acquia DAM, CDP, Personalization, Campaign Studio, Campaign Factory, Cloud IDE, and the DevOps and analytics workflows around them.

Because our pod also carries MarTech and analytics skills, the products that generate customer data are supported by the same team that maintains the platform producing it.

Drupal core publishes security releases in a window on the third Wednesday of most months; contributed modules issue advisories on their own cadence. CXOntology assesses each advisory against your actual configuration rather than patching indiscriminately.

Before a production deployment we review update impact, dependency conflicts, custom-module risk, test coverage, and release timing. Larger version moves are planned as a managed roadmap, not a one-off patch event.

CXOntology is a digital experience, go-to-market, and AI consultancy. We engineer and run digital platforms, improve conversion and discoverability, and activate AI and agentic capability across digital operations.

Our Drupal and Acquia practice delivers managed services through the pod delivery model: a dedicated, multi-skilled team — engineering, front-end, DevOps, data, and QA — led by a named Pod Leader accountable for the engagement, staffed globally on blended rates.

Senior practitioners run the work end to end — the people who assess your estate are the people who run it. More on how we deliver.

A CXOntology pod is a dedicated, multi-skilled team that owns your digital operations end to end, rather than a queue of tickets worked by whoever is free. Three design choices define it.

A named Pod Leader. One senior lead owns the commitments, estimates, quality, and outcomes for your engagement — a single point of accountability. Multi-skilled, not siloed. Engineering, front-end, DevOps, data, and QA work as one unit, so the capability your next sprint needs is already on the team. Aware of the whole stack. Each member understands how their piece connects to the rest of your Drupal and Acquia ecosystem, so risks and dependencies surface in planning rather than after release.

Pods are staffed through our global delivery model, with blended rates and follow-the-sun coverage. More on how we deliver.

Yes. CXOntology runs transitions in phases: a technical assessment, knowledge capture, access and environment handover, then a parallel period where monitoring and deployment continue uninterrupted before we assume full operational control under the agreed SLA.

The risk in a vendor change is rarely the code. It is undocumented decisions and release tribal knowledge — which is exactly what the assessment phase exists to surface, before anyone hands over a key.

For urgent situations CXOntology starts with triage and stabilisation rather than onboarding: production issue review, access and environment checks, release-risk review, an incident backlog, and a short-term action plan.

Moving into a longer managed-services model happens once the estate is stable, not before. A rescue engagement and a run engagement are different jobs, and we scope them as such.

Ask for the things that survive contact with an incident: named senior engineers on your account rather than a pooled queue, response and resolution targets by severity, a written escalation path, and a scope matrix saying which custom modules and integrations are covered.

Then ask two questions that separate proposals quickly. How does the skill mix change when the backlog changes? And who do you speak to when a release goes wrong?

CXOntology answers those with a multi-skilled pod, a named Pod Leader accountable for the engagement, published delivery governance, and severity tiers written into the agreement. Read more about us.

CXOntology offers three: Essential for break-fix support, security patching and monitoring; Growth for teams needing ongoing enhancements alongside support; and Enterprise for outcome-driven partnership across analytics, SEO, MarTech, and AI-enabled delivery.

Which one fits depends on traffic, release frequency, compliance obligations, stakeholder coverage, backlog size, and how much proactive improvement you want — not on site count alone.

Three models dominate the market. Hourly and ad-hoc billing suits occasional needs but makes cost unpredictable. A monthly retainer buys pre-allocated engineering capacity and suits teams doing regular enhancement work alongside maintenance. A fixed-fee managed plan with an SLA suits mission-critical platforms.

CXOntology scopes from your ticket history, release cadence, and backlog rather than from an hourly rate card, because hours bought are not the same as outcomes delivered.

Separate response and resolution targets for each severity level — not one blended number. Beyond that: an agreed severity-classification process, a named escalation path, a scope matrix covering custom modules and integrations, an explicit exclusions list, written incident reports, and exit rights.

An agreement that states availability but no resolution targets by severity is a best-effort retainer, not an SLA.

CXOntology puts severity tiers, escalation owners, and the scope matrix in the agreement, so the boundary is settled before an incident rather than during one.

CXOntology supports three engagement models. Block of Hours suits occasional or unpredictable work: buy expert hours upfront and draw them down for fixes, upgrades, advisory, or specialist support. Monthly Retainer reserves recurring capacity across engineering, QA, DevOps, UX, analytics, SEO, and MarTech. Dedicated Staffing assigns people or a pod for continuity, platform knowledge, sprint velocity, and deeper ownership.

We recommend the right model based on backlog, urgency, continuity, and ownership needs.

Yes, if the plan is scoped to do more than keep the site online. That work includes Core Web Vitals, accessibility remediation, structured content, schema, technical SEO, analytics quality, and content patterns that hold up in both search engines and answer engines.

These are engineering outcomes as much as marketing ones. CXOntology’s pod carries SEO, analytics, and MarTech alongside the engineers, which is why discoverability sits inside the support model rather than beside it as a separate retainer.

SEO gets you into the candidate set. Answer Engine Optimization (AEO) is structuring content so an answer engine selects it as the answer. Generative Engine Optimization (GEO) is optimising to be cited inside an AI-generated response.

The terms overlap and are often used interchangeably. The practical shift is the same: from ranking in a list to being the synthesised answer.

CXOntology treats AEO and GEO as engineering work rather than copywriting — content model, rendering, structured data, and crawler access all decide whether an answer can be lifted at all.

Not on its own. Google stopped showing FAQ rich results on 7 May 2026, and its AI-features guidance states that no special markup is required for AI Overviews or AI Mode.

FAQPage markup remains a valid schema.org type and is still parsed by other search engines and AI crawlers, so it is worth keeping where it accurately describes visible content. The load-bearing work is the content itself: a question people actually ask, a direct answer in the first sentence, short paragraphs, and specifics a model can lift.

CXOntology builds FAQ patterns where the schema is generated from the same source as the visible copy, so the two cannot drift apart. This page is built that way.

Server-rendered HTML, AI user agents unblocked in robots.txt, structured data that matches the visible text, a clean heading hierarchy, and answers that are not locked behind interactions, logins, or client-side rendering.

On Acquia, Acquia Source structures content for LLM readability as a platform feature. On any stack the same principles apply — and they are testable.

CXOntology audits crawler access, rendering, and schema-to-content parity as part of the support model. A digital assessment is usually where we start.

Yes. CXOntology’s AI and agentic practice designs the workflows first, then engineers the skills and integrations against your existing content model, MarTech stack, and governance rules.

Agents that act without the same roles, permissions, and review gates as a human teammate create risk faster than they create value, so we scope governance alongside the capability rather than after it.