Drupal 7 died in January 2025. Joomla 3 in 2023. TYPO3 charges for old-version support. Staying put is now the expensive option
The strategic read for teams still running Drupal, Joomla, or TYPO3 in 2026: what modernising to Astro or Next.js actually costs, what it saves over ten years, and the honest cases where upgrading in place beats re-platforming. Your rankings survive the move; the redirect-map discipline is the whole point.
START A PROJECT SEE THE MIGRATION SERVICE12,000+ sites shipped at Seahawk Media Astro + Next.js operated daily, from 3,100 to 91,000 pages Build-time SEO linter on every migration
The 2026 read on legacy platforms
These platforms were the right call when you picked them. Drupal ran embassies, universities, and every second government portal for a decade. Joomla put real publishing in the hands of teams that could not afford bespoke builds. TYPO3 still runs a serious share of the corporate web in Germany and beyond. The software did its job. Full stop.
What changed is the ecosystem around the software. Drupal 7 reached end of life on 5 January 2025, after three extensions. Sites still on it run without security patches. Joomla 3 support ended in August 2023. TYPO3 gives each LTS release three years of free support, after that you are paying for ELTS contracts to stay patched. None of this makes the platforms bad. It makes standing still expensive: senior Drupal and TYPO3 developers get scarcer and dearer every quarter, agencies quote a legacy premium for the work, extension debt compounds, and every year on an unsupported major makes the eventual jump bigger (the kind of compounding nobody budgets for in year one). Quietly brutal, that last part.
So the real decision is not "should we migrate". It is "which of the three routes out do we take, and when".
Three routes out, and who should take which
Route one, modernise to Astro or Next.js. Right for marketing sites, publishing operations, documentation, multi-brand estates, anything whose job is putting content in front of readers. You get static or hybrid rendering (pages served as plain HTML, nothing to patch on a Tuesday night), hosting bills that drop to almost nothing, and a front-end any JavaScript developer can work on. Hiring stops being an archaeology project. Genuinely.
Route two, upgrade in place. Drupal 10 and 11 are genuinely good software, and TYPO3 v13 is a real platform. If you have an in-house team that lives in Drupal, heavy editorial workflow (multi-stage moderation, hundreds of editors, per-field permissions), and deep module investment that maps cleanly onto the new major, upgrading can beat re-platforming. I do not sell that route. I will still tell you when it wins.
Route three, move to WordPress. For smaller marketing sites where a non-technical team wants familiar editing above all else, Drupal to WordPress is often the pragmatic landing. Different destination, same discipline on redirects and metadata.
So before we go further: do you actually know which route fits your site right now, or are you still deciding?
Astro or Next.js, decided by one question
Does the site do anything per visitor? Logins, dashboards, personalised pricing, live data, carts: Next.js. Content in front of readers: Astro, and it is not close. Astro ships plain HTML with almost no JavaScript, which is why it wins Core Web Vitals without heroics.
I run both in production, daily. This site is Astro plus Supabase, 3,100+ URLs in 8 languages, published from a custom admin. Deluxe Astrology runs 91,000+ pages in 30 languages on Next.js. HostList runs a 25,000-company hosting directory on Next.js plus Supabase. The recommendation you get on the call comes from operating these stacks, not from reading about them (there is a difference, and it shows in the advice). There is a longer comparison at Astro vs Next.js if you want the detail first.
Where your editors write afterwards
A legacy CMS bundles authoring, templates, and serving into one PHP application. That is exactly why upgrades hurt. The modern build splits them apart. Your editors write in a headless CMS, Sanity, Payload, Storyblok, or headless WordPress if the team wants wp-admin, or in a custom admin on Supabase like the one behind this site: inline editing, auto-save, no plugin updates ever. The front-end reads that content at build time or on demand.
The content model translates more cleanly than teams expect (most are pleasantly surprised, honestly). Drupal content types, fields, and taxonomies map one-to-one onto structured content schemas. Joomla articles and categories are simpler still. TYPO3 takes the most archaeology, pages, tt_content, and whatever TypoScript accumulated since 2011, which is why the audit phase exists.
What actually transfers
Content comes out via JSON:API or straight from MySQL for Drupal, from the com_content tables for Joomla, from pages and tt_content for TYPO3. Scripted, re-runnable importers. Never hand copy-paste. Media gets re-hosted and re-encoded to WebP, and most estates shrink dramatically in the process. Every URL Google knows about, Search Console, Ahrefs, the old sitemap, Drupal pathauto aliases, goes into a redirect map that ships as server-level 301s on cutover day. Metadata moves byte-identical: titles, descriptions, canonicals, schema. A build-time SEO linter then fails any deploy that regresses metadata, H1s, or structured data. That linter runs on this site on every build, and yours gets the same treatment.
Are you confident your current platform could even produce a clean URL export today? Worth knowing before the conversation.
The migration plan, in six phases
1. Audit + inventory (1-2 weeks, 4,000-8,000 USD, credited against the build)
Content types, the modules and extensions actually in use, the full URL corpus, every integration. Output: a written spec, a functionality map, redirect map v1, and a fixed price.
2. Content model + stack decision (1 week)
Astro or Next.js, which CMS, and what dies. Every legacy estate carries a surprising share of content nobody will miss, and deciding that now keeps the migration honest.
3. Build (3-8 weeks)
Design refresh or faithful rebuild, component system, templates, performance budget.
4. Content migration (1-4 weeks)
Scripted and re-runnable, with QA on a representative sample before the bulk run.
5. SEO transport + QA (1-2 weeks)
Redirect map finalised, metadata verified byte-identical, the SEO linter wired into CI.
6. Cutover + 90-day watch
Documented rollback, Search Console resubmission, indexation and Core Web Vitals monitored weekly until the curves settle.
When this is the wrong call
Three honest cases. You are on Drupal 10 or 11 with an in-house Drupal team and workflow depth the modern stack would have to rebuild from scratch: upgrade in place. Your site is 15 pages and earns nothing: rebuild small on anything, this engagement is a programme and you need a fortnight. And if nobody on your side will own a JavaScript stack and there is no budget for a retainer, an unmaintained modern stack is just next decade's legacy system. Fix ownership first, then migrate.
Is any of that your situation? Worth checking before we spend 30 minutes on a call.
Frequently asked questions
How much does a Drupal, Joomla, or TYPO3 migration to Astro or Next.js cost?
Under 200 pages with stock content types: 9,000-25,000 USD. 500-5,000 pages with custom fields and a design refresh: 25,000-75,000 USD. Enterprise estates, multisite, integrations, 10,000+ pages: 75,000-250,000 USD. Discovery runs 4,000-8,000 USD and is credited against the build. The variable that moves price most is custom functionality (Views-heavy Drupal builds, bespoke TYPO3 extensions), not page count.
How long does the migration take?
Small sites: 6-10 weeks end to end. Mid-size: 10-16 weeks. Enterprise: 16-24 weeks plus a parallel-run period. Timelines stretch with custom-functionality reproduction and content quality at source (messy taxonomies add weeks, page count adds days).
Will our rankings survive?
Yes, when the boring work gets done. A complete redirect map, every URL, no exceptions, byte-identical metadata transport, schema preserved, then 90 days of Search Console monitoring after cutover. The migrations that lose 30% of their traffic for six months are the ones that treated redirects as a launch-week afterthought.
What happens to Views, Webforms, and our multilingual setup?
Each gets an explicit line in the functionality map from phase one. Drupal Views become build-time queries against the new content store. Webforms become modern form handling with spam protection. Multilingual moves to proper i18n routing with hreflang done correctly (this site runs 8 languages that way, and Deluxe Astrology runs 30). Anything that cannot be reproduced gets flagged in discovery with an alternative, before you sign, not after.
Should we just upgrade Drupal 7 to Drupal 10 or 11 instead?
Honest answer: Drupal 7 to 10 is itself a migration. The content model and theme layer changed enough that you are rebuilding either way. So compare rebuild-into-Drupal against rebuild-into-modern on ten-year cost: hosting, patching, developer availability, editor happiness. Teams with Drupal-native staff often should stay. Teams without usually should not.
Astro or Next.js for our site?
One question decides it: does the site do things per visitor, accounts, dashboards, live data? Then Next.js. Is it content in front of readers? Astro. On the call I will commit to one, in writing, with reasons.
What to bring to the call
Four things. Your CMS and version. A rough page count (a sitemap URL or database export works). A 90-day Search Console screenshot. And a list of everything the site does beyond publishing: forms, search, logins, commerce, feeds. Thirty minutes later you will have a recommended route, a realistic timeline, and a price band, whether or not we end up working together.