Replatform Drupal to Astro
Drupal 10 reaches end of life on 9 December 2026. You are funding a project either way.
Drupal 10 reaches end of life on 9 December 2026, and on that date the security fixes stop. Moving to Drupal 11 is a real project — contributed-module compatibility, a PHP version, APIs that have been removed — so the work gets funded whichever direction you choose. We re-platform the front end to a static Astro build on Cloudflare: the same content, the same URLs, served from the edge. Editors can keep Drupal and author exactly as they do now, or the platform can be retired altogether.
Drupal 
Astro
Cloudflare 
Sanity, if you edit What actually changes
Your design is carried across exactly as it is. A redesign is a separate project, quoted separately, and only if you want one.
Website replatforming
Off Drupal. Onto Astro, served from Cloudflare's edge.
Drupal AstroCloudflare Sanity, if you edit An ageing content management system costs you three ways at once: maintenance and licences you keep paying, a break-in risk you carry, and slow pages that lose the visitors your ads and search already paid for. Replatforming removes all three, keeps your design, content and addresses, and leaves a site ready for what comes next.
Why replatformWhat staying on Drupal costs you
The valueWhat replatforming returns
Module risk you carry
Your site depends on contributed modules that are not held to core's standard, and each one runs with full reach into your database. One unmaintained module is the way in.
Attack surface removed
No modules. No database. No code running on request. The category of exposure disappears instead of being patched.
Every major version a rebuild
Contributed modules reach each new major version late or never, so upgrading means rebuilding. Sites end up stranded on a version that no longer receives fixes.
Nothing to port
Content, design and web addresses come across. The major-version treadmill stops, and there are no modules to wait on.
Specialist rates to stand still
Drupal needs a specialist. A developer day rate and recurring dependency work is what it costs to keep the site patched and standing still.
Maintenance cost removed
No modules. No dependency tree. No specialist retainer to stand still. Static hosting that does not climb with traffic.
Speed depends on server load
Pages are assembled on request, with caching stacked on top to hide it. What the visitor gets depends on how loaded the server is when they arrive.
Measurably faster pages
Pages are pre-built and served from the edge, so speed stops depending on server load. At least a 20 per cent improvement where there is room for it, measured on the same test.
No single record of the live site
Configuration lives partly in the database and partly in code. Nothing shows in one place what the live site is, and recovery depends on who was last in it.
Versioned, with one-step rollback
Every change versioned, reviewed and tested before release. Rollback to any previous version in one step. Recovery in minutes.
AI cannot reach your content
Your content is locked in a database behind a login, and pages rendered on request give an agent nothing stable to read.
AI and agentic foundations
Content becomes machine-readable and deployment becomes something software can run. Module 01 of the roadmap below, and the prerequisite for every module after it.
Our own site runs on it. Every page sits in Google’s “good” band for speed, on mobile and desktop, measured 17 September 2026.
How we replatform
01
Discovery
We map the current site, its content, integrations and traffic, and agree what must be preserved.
02
Plan
A written migration plan: scope, page-by-page mapping, redirects, risks, and the measured baseline.
03
Approval
You approve the plan and the agreed targets. No build starts without it.
04
Replatform
Build, test and launch, then re-run the same tests and hand you the before-and-after.
Typical outcome: at least a 20 per cent improvement in measured performance where the current measurement leaves room for it, and the plugin and theme attack surface removed entirely. Measured on the same test, before and after.
Where this sits — the nine-module Growth Engine
- 01Websites
- 02Discovery
- 03Digital funnel
- 04Market sizing
- 05Data & KPIs
- 06Digital voice
- 07Automation & Integration
- 08AI
- 09SAOS
Replatforming is module 01, deliberately first: a fast, secure, agent-readable website is the asset every later module reads from and acts on. Each module stands alone, and there is no obligation to take the next.
What Replatform Drupal to Astro delivers
Editors can keep Drupal
Drupal's JSON:API module exposes nodes, fields, taxonomy and menus. Astro reads that and builds the pages, so the authoring experience your team already knows is untouched.
Faithful re-platform
Content, structure, URLs and redirects carried across, so rankings and inbound links survive the cutover.
Nothing left to patch
Edge-served on Cloudflare — no PHP process, no per-request database, and no module update sitting in the request path.
We name what is rebuilt
Views, Webform, Panels, Layout Builder and anything a contributed module renders at request time are rebuilt, not converted. You get that list before you commit, not after.
Primary tools
DrupalAstroSanityCloudflareSecondary tools
Sentry.io
Playwright
GitHub
Infisical
Looker
OpenAI
Anthropic Claude
n8n
ResendOne data layer · measured & owned
Every service creates data that is captured, measured and owned.
Replatform Drupal to Astro doesn’t just run. It generates signal. We land that data in one warehouse and turn it into live KPIs tied to a named owner, so performance is attributable and acted on, never trapped inside a single tool.
Data warehouse
Supabase
Snowflake
Keboola
BigQuery KPIs, dashboards & apps
Plotly
Retool
Apache Superset Platform-agnostic: we connect what you already use and add a warehouse only where it earns its place.
Version support — the published end-of-life dates
What is still supported, and what has already stopped.
Unsupported. No security fixes have been issued since end of life.
End of life: 5 January 2025
Released 19 November 2015. Unsupported.
End of life: 17 November 2021
Released 3 June 2020. Unsupported.
End of life: 1 November 2023
Released 15 December 2022. Supported today — this is the version with the deadline.
End of life: 9 December 2026
Released 2 August 2024. Supported.
End of life: Not yet published by Drupal
Scheduled for release the week of 7 December 2026.
End of life: Not yet published by Drupal
Every date above is published by Drupal on its core release schedule. Drupal 12 arrives the same week Drupal 10 support ends. Drupal has not published an end-of-life date for Drupal 11 or Drupal 12, so none is stated here.
Capability Maturity — we walk you up the five levels
Operated at Level 4 · Quantitatively Managed — measured, predictable and owned. We track this rank and raise it over time. See the five levels →
Why this matters
Functional value, value-stream value, and why it can't be ignored.
Re-platforms a Drupal site to a static Astro front end on Cloudflare — either headless, with Drupal kept as the editing system and read through its JSON:API module, or fully extracted so the platform is retired. Content, structure, URLs and redirects are carried across.
It creates a publishing path with no server in it: every page is built once and served from the edge. It enhances what the business already owns — the content model, the URLs and the search positions come across intact. And it protects the site on the day Drupal 10 support ends, because a static build has no PHP process, no database and no contributed modules facing the internet.
Nothing breaks on 9 December 2026, and that is the difficulty — the site keeps serving, so nobody raises it. What stops is the supply of security fixes: from that date Drupal issues no further security advisories or patches for Drupal 10. Every flaw found after that is published in the open, and on your site it stays open. The consequences then arrive from outside engineering — a penetration test that records unsupported software as a finding, a procurement questionnaire that asks which version you run, an insurer at renewal asking whether your software is still supported and patched. Waiting defers none of it, and there is no version of this where the project goes unfunded: Drupal 10 to Drupal 11 is contributed-module compatibility, a PHP version and removed APIs — the same discovery work as moving the front end to Astro. The only real choice is what you own at the end of it: another supported version with the next end-of-life date already in the diary, or a front end with nothing left to patch.
How we select technology
We choose technology last, for the outcomes it has to earn.
Never tech for its own sake. A tool joins the stack only where it measurably protects value, cuts cost or speeds delivery. It must fit a designed system, be owned where it counts, and be measurable from day one. How we select technology →
Speed
Modern, edge-served stacks are sub-second. Slow surfaces cost conversion and SEO every single day.
Cost
Cut licence, hosting and per-task SaaS fees. Pay for capability, not lock-in or idle enterprise tiers.
Security
Flat, edge architecture with almost nothing left to attack: fewer moving parts, smaller surface.
Ownership & no lock-in
Composable and self-hosted where it counts, so you own the system, not rent someone else’s.
Measurability
Clean data and KPIs built in. You cannot improve, automate or apply AI to what you cannot measure.
Fit to process
The right tool for a designed system, selected against process readiness, so it amplifies, not adds friction.
How we deliver · DMAIC
Every Replatform Drupal to Astro engagement runs on DMAIC.
Define the goal and its value, measure the baseline, analyse the real constraint, improve with a controlled build, then control the gains, so results are predictable, repeatable and defensible, not down to luck.
Agree the goal, value, budget & timescale up front.
Baseline the KPIs above: current state, not guesswork.
Diagnose the real constraint and the solution needed.
Build the chosen solution; prove the uplift.
Lock in the gains; monitor and sustain them.
FAQ
Common questions
What is Replatform Drupal to Astro?
Drupal 10 reaches end of life on 9 December 2026, and on that date the security fixes stop. Moving to Drupal 11 is a real project — contributed-module compatibility, a PHP version, APIs that have been removed — so the work gets funded whichever direction you choose. We re-platform the front end to a static Astro build on Cloudflare: the same content, the same URLs, served from the edge. Editors can keep Drupal and author exactly as they do now, or the platform can be retired altogether.
Why does Replatform Drupal to Astro matter?
Nothing breaks on 9 December 2026, and that is the difficulty — the site keeps serving, so nobody raises it. What stops is the supply of security fixes: from that date Drupal issues no further security advisories or patches for Drupal 10. Every flaw found after that is published in the open, and on your site it stays open. The consequences then arrive from outside engineering — a penetration test that records unsupported software as a finding, a procurement questionnaire that asks which version you run, an insurer at renewal asking whether your software is still supported and patched. Waiting defers none of it, and there is no version of this where the project goes unfunded: Drupal 10 to Drupal 11 is contributed-module compatibility, a PHP version and removed APIs — the same discovery work as moving the front end to Astro. The only real choice is what you own at the end of it: another supported version with the next end-of-life date already in the diary, or a front end with nothing left to patch.
How does Sentry deliver Replatform Drupal to Astro?
Re-platforms a Drupal site to a static Astro front end on Cloudflare — either headless, with Drupal kept as the editing system and read through its JSON:API module, or fully extracted so the platform is retired. Content, structure, URLs and redirects are carried across.
What do I get with Replatform Drupal to Astro?
Editors can keep Drupal: Drupal's JSON:API module exposes nodes, fields, taxonomy and menus. Astro reads that and builds the pages, so the authoring experience your team already knows is untouched. Faithful re-platform: Content, structure, URLs and redirects carried across, so rankings and inbound links survive the cutover. Nothing left to patch: Edge-served on Cloudflare — no PHP process, no per-request database, and no module update sitting in the request path. We name what is rebuilt: Views, Webform, Panels, Layout Builder and anything a contributed module renders at request time are rebuilt, not converted. You get that list before you commit, not after.
Free migration quote
Get a quote for your Drupal to Astro migration
Tell us where your site is and when you need it moved. A person reviews every request and replies within one working day. You and our team both get a copy by email.
Start here · the free first step
Replatform Drupal to Astro starts the same way every engagement does: with Discovery.
Two distinct moves. A free, no-obligation Discovery Session to frame your biggest measurable constraint and what it may be worth, with a one-page written summary afterwards. Then, where the evidence warrants it, the paid Discovery & Blueprint: 14 written outputs (value model, roadmap and business case) before a pound of delivery is committed.
Engaged alone or as one engine