In the DACH region (Germany, Austria and Switzerland), TYPO3 was never a random choice. Public authorities, universities, industrial companies with multi-domain setups and large associations have picked it since the early 2000s, because it solved exactly what classic WordPress could not do for a long time: clean multilingual support, granular permissions, multi-site and multi-tree out of the box. In 2026 the market looks different. This article is an honest look at when migrating from TYPO3 to WordPress makes economic and editorial sense, and when it does not. It is not neutral. It is polemical in the best sense, with a clear position and verifiable facts.
TL;DR
- TYPO3 12 LTS has been available since 4 October 2023, TYPO3 13 is the active development line, and the project is alive.
- WordPress 6.7 and later is the reference for 2026 and, according to W3Techs, powers around 43 percent of all websites worldwide.
- The WordPress block editor has existed since WordPress 5.0 in December 2018, the REST API since WordPress 4.7 in December 2016.
- Multi-site, multi-domain and multilingual support are core features in TYPO3, while in WordPress they are a matter of Multisite plus Polylang or WPML.
- Migration does not pay off across the board. It pays off when talent availability, editorial comfort and frontend speed outweigh TYPO3’s technical profile.
What is TYPO3 better at than WordPress?
TYPO3 grew big in Germany, Austria and Switzerland for three reasons. First, it shipped a multilingual model early on that needed no plugin. One page, several language versions, clear translation relations: in 2010 that was unrealistic in WordPress. Second, TYPO3 covers multi-site and multi-domain in its core. One installation, several page trees, several domains, separate editorial teams with separate permissions. Third, its rights and roles system is fine-grained enough to model internal approval processes at public authorities, universities and industrial groups, including workspaces for unpublished versions.
These are exactly the segments where TYPO3 grew big in the DACH region. Universities with faculty areas, municipal administrations with citizen portals, industrial groups with a corporate portal plus subsidiaries, German federal states with their ministries. The TYPO3 Association, based in Switzerland, has pooled this market since 2004 and provides the stability that matters to public-sector clients. Anyone digitising a German district office in 2010 could hardly avoid TYPO3.
This historical strength is real, and no honest discussion brushes it aside. It is, however, not the whole story for 2026.
How has WordPress changed since Gutenberg and the REST API?
In December 2018, WordPress 5.0 shipped with the block editor, known internally as Gutenberg. This was not a cosmetic change but a shift in the editorial model. Pages have been assembled from blocks ever since, block patterns allow reusable layouts, and full site editing, available since WordPress 5.9 in January 2022, extends the concept to templates, headers and footers. The effect is measurable: editorial teams without a developer background now publish complex layouts on their own.
Two years earlier, in December 2016, WordPress 4.7 had brought the REST API into core. Since then, WordPress has been a fully fledged headless CMS. Astro frontends, Next.js apps and native mobile applications all pull their content through the same API. TYPO3 has a comparable story with Headless TYPO3, but the ecosystem of frontend frameworks that talk to WordPress out of the box is orders of magnitude wider.
In parallel, market penetration has kept moving in WordPress’s favour. The frequently quoted figure of around 43 percent of all websites worldwide comes from W3Techs and is confirmed by Automattic in official materials. This figure is not just a statistic, it is a talent indicator. In Berlin, Munich, Vienna, Zurich, Hamburg and Cologne, every TYPO3 job ad is matched by several WordPress applicants. Anyone looking for a senior TYPO3 developer in 2026 has to search longer, pay more and accept longer notice periods than with WordPress. That is not a judgement on quality, it is a question of market availability.
Then there is the speed at which the WordPress ecosystem reacts to new standards. WCAG 2.2, BFSG, NIS2, DORA, Core Web Vitals: in recent years all of these have produced plugins, themes and best practice templates that do exist in TYPO3, but rarely at the same maturity. Examples include how widespread WCAG 2.2 ready themes are, or the depth of Cloudflare Workers integrations. For a closer look at the edge layer, see our article on Cloudflare Workers for WordPress and WooCommerce.
When does migrating from TYPO3 to WordPress pay off?
A migration from TYPO3 to WordPress should not follow a trend. It should follow a decision rule. At WPPoland we apply five criteria. If three or more are met, migration is the economically sensible answer.
First, the editorial team is not close to development. If content currently ends up as tickets at the agency because TypoScript changes are needed, that costs speed and money. WordPress with the block editor and well-configured block patterns reduces this dependency significantly.
Second, the site lives on content marketing. Blog, knowledge base, whitepapers, webinars, case studies: WordPress produces all of this at a higher frequency. Anyone publishing more than two substantial pieces a week benefits from WordPress in daily work.
Third, frontend performance is under pressure. Core Web Vitals are a ranking factor, and the WordPress ecosystem has built the largest stack of edge, caching and build solutions. If you are aiming for 100 out of 100, you will find more ready-made building blocks in the WordPress universe than in TYPO3.
Fourth, talent availability limits the project. If finding senior TYPO3 profiles takes several months and hourly rates sit well above the WordPress average, that is an economic signal. An honest view of nearshore standards for DACH projects is in our article on senior engineers from Poland.
Fifth, the target architecture is headless. If you are moving to a modern frontend in Astro or Next.js anyway, the WordPress ecosystem offers more and more mature bridges. Our pillar article on headless WordPress as a service describes the model in detail.
When should you stay on TYPO3?
Polemic without a counter-position is marketing, not advice. There are four clear cases where TYPO3 remains the right choice and a migration project would be disproportionate.
First, the site was fixed in a public procurement procedure that explicitly requires TYPO3, for example in framework contracts of German federal states. Demanding a migration against the contractual position is unsound business practice.
Second, the internal team is deeply trained in the TYPO3 universe, has workspaces, workflows and multi-tree setups firmly under control and works at a good pace with them. In that case a migration burns internal knowledge for unclear added value.
Third, the multilingual setup is very complex, for example eight or more languages, shared content between languages, regional variants and a multi-tenant setup across domains. WordPress can handle this with Polylang or WPML, but the complexity will not disappear, it will only move.
Fourth, custom Extbase logic is deeply intertwined with business processes, for example in university portals with module handbooks or in public authority systems with case processing. Rebuilding this logic in WordPress can cost more than continuing to maintain TYPO3.
If none of these cases applies and the migration criteria prevail, the question becomes the path.
How to migrate TYPO3 to WordPress in four phases
We split TYPO3 to WordPress migrations into four phases. They take different amounts of time, but all of them have to happen, otherwise you get the mistakes described in the next section.
Phase one is the audit. Here the existing TYPO3 setup is fully mapped. Which page trees, which domains, which language versions, which extensions, which TypoScript configurations, which workflows, which roles, which external connections. The audit produces an inventory with URLs, metadata, language relations and custom data models. Without this inventory, everything that follows is guesswork.
Phase two is content model mapping. WordPress thinks in posts, pages, custom post types and taxonomies. TYPO3 thinks in page trees, content elements and records. The mapping decides which TYPO3 content elements become Gutenberg blocks, which become reusable blocks and block patterns, which become ACF fields and which become custom post types. A typical mapping in DACH projects covers news, press releases, job ads, locations, events and staff. This phase is the most intellectually demanding, because it restructures editorial thinking.
Phase three is the actual technical migration. Scripts read the TYPO3 databases, transform the content and write it into WordPress structures. We usually combine direct database access via read-only replicas with WP-CLI importers. Images are carried over with their renditions, and multilingual support is built with Polylang or WPML, depending on the target profile. The scripts are idempotent, which means they can run several times without creating duplicates.
Phase four is SEO and the redirect strategy. Here we make sure every old URL returns a 301 response leading to an equivalent new URL. Structured data is rebuilt, hreflang tags are fully mapped and XML sitemaps are regenerated. This phase is neither optional nor an afterthought: it is prepared in parallel with phase three. For a deeper look at SEO patterns in a headless setup, see our article on SEO patterns for headless WordPress.
Common mistakes in a TYPO3 migration
Over the past years we have seen enough TYPO3 to WordPress projects to name the five most common mistakes. All of them are avoidable if the audit is honest.
First, URL preservation is underestimated. TYPO3 generates URLs from page tree paths, often with German special characters, often with long hierarchies. If you flatten the URL structure during the switch without a redirect map, you lose rankings for months. The fix is a complete URL list before cutover, with a clear source and target per entry, delivered through the web server configuration or Cloudflare Page Rules.
Second, mapping multi-tree to categories is thought through too naively. A page tree in TYPO3 is not the same as a WordPress category. Page trees contain hierarchies, permissions, language variants and content elements. A category is a taxonomy. Mapping one to one loses information. The clean solution is a mix of custom post types, taxonomies and pages with parent relations.
Third, multilingual fragments get forgotten. TYPO3 allows language overlays for individual content elements without duplicating the whole page. WordPress localisation via Polylang or WPML duplicates the page by default. If the mapping does not model this difference, translations suddenly go missing for header, footer or teaser blocks, because they were maintained as global snippets in TYPO3.
Fourth, custom Extbase data models are translated too late. If you built your own TYPO3 extension for, say, events with early-bird logic, seat capacities and waiting lists, you cannot pull it through a generic importer. The logic has to be translated into a custom post type plus REST endpoints, ideally with its own validation rules. If you discover this in the last two weeks before cutover, the launch date moves.
Fifth, image renditions get forgotten. TYPO3 generates renditions for different sizes and crops through its File Abstraction Layer. WordPress has its own image sizes system. If the migration transfers only the originals and the renditions are regenerated at runtime on first request, the site looks slow for days after cutover. The fix is to pre-generate the sizes with WP-CLI right after the import.
TYPO3 to WordPress migration agency
For years we have supported DACH companies and public sector organisations in TYPO3 to WordPress migrations, with a particular focus on headless architectures. Our model separates editorial work from frontend delivery. WordPress remains the editorial system, and the frontend runs on Astro or Next.js, delivered through Cloudflare Workers. This gives public authorities and mid-sized companies the speed they need for Core Web Vitals without giving up the editorial comfort of WordPress.
Our project teams speak German, Polish and English, we document architectures so that compliance teams can review them, and we deliver WCAG 2.2 and BFSG ready templates. Concrete prices depend on the profile, from the inventory to the multi-site effort. If you want to know how our service model works in practice, the overview is on our page about headless WordPress as a service, and you can talk to the team directly.
WordPress and TYPO3 meetups in the DACH region
Public community directories and meetup links. We do not run our own offline or event landing pages: these lists point to existing DACH communities.
WordPress communities and directories
External community links (Meetup, WordCamp, national associations). No offline or event landing pages of WPPoland’s own.
- DACH Meetup-Verzeichnis (de.wordpress.org)
- WordPress Meetup Pro (global)
- WordCamp Central
- WP Switzerland
- WordPress Meetup Berlin
- WordPress Meetup München
- WordPress Meetup Hamburg
- WordPress Meetup Köln
- WordPress Meetup Leipzig
- WordPress Meetup Dortmund
- Düsseldorf WooCommerce Meetup
- Vienna WordPress Meetup
- WordPress Zurich
- WordPress Bern
TYPO3 communities and directories
Official TYPO3 calendars, user groups and barcamps in the DACH region, again third-party sources only.
- TYPO3 Events Calendar
- TUG Directory (User Groups)
- TYPO3camp München
- TYPO3camp RheinRuhr
- TYPO3camp Berlin
- TYPO3camp Mitteldeutschland
- TYPO3camp Stuttgart
- TYPO3camp Vienna
- TYPO3camp Schweiz
- TUGA (Austria)
- TUG München (T3MUC)
- TUG Berlin (T3B)
- TUG Schweiz
Further reading on WordPress migration and headless
This article is not a standalone piece but part of a DACH cluster on WordPress migrations and performance. If you started here, you will find the follow-up pieces in the texts below.
The methodical case study with a redirect map and content model checklists is at confidential TYPO3 to WordPress migration. The two CSV templates are available for download there as well. For the architecture after the migration, headless WordPress as a service is the pillar. For technical delivery via the edge layer, read Cloudflare Workers for WordPress and WooCommerce. For public sector requirements, WCAG, BFSG and EAA stays relevant. For talent questions, our piece on senior engineers from Poland gives the nearshore context.
Deeper reading for CTOs and technical leads is in Headless WordPress: Next.js vs Astro, in the economics of headless WordPress and in SEO patterns for headless WordPress. For the author’s personal position on a DACH WordPress strategy, see the profile of Mariusz Szatkowski.
TYPO3 has a home in DACH, that is a fact. In 2026 WordPress has the greater reach, the bigger talent pool and the broader ecosystem, and that is a fact too. Migration is not a creed. It is a calculation with five variables. If you do the maths honestly, you get a clear answer.
How to migrate TYPO3 tt_content to Gutenberg blocks
Migrating a complex TYPO3 enterprise instance to WordPress requires a deep understanding of both data models:
- Resolving TypoScript and content elements: In TYPO3, content is often organised granularly in nested
tt_contenttables. Converting it into semantic Gutenberg blocks requires custom migration scripts (WP-CLI) that clean up HTML structures and map modular components cleanly. - Multilingual support and fallback hierarchies: TYPO3 manages languages through complex localisation trees with inheritance logic. When moving to WordPress solutions such as Polylang Pro or WPML, language IDs, menu hierarchies and relational links have to be migrated precisely to avoid duplicates and routing conflicts.
- Securing assets and media paths: TYPO3 storage paths (
fileadmin/) differ fundamentally from the WordPress media library. A careful import process updates image references, generates responsive WebP images and prevents broken image links. - A comprehensive 301 redirect strategy: Because TYPO3 websites have often been established online for decades, complete mapping of old URL structures via Nginx rewrites is essential to keep organic rankings.
Testing and editor training after the WordPress relaunch
Successfully closing a migration project requires a structured handover:
- Comprehensive automated regression tests: Before the final DNS switch, automated test runs check that all content is equivalent, that contact forms work and that accessibility meets WCAG 2.2.
- Editor training for the Gutenberg ecosystem: Editors who have worked in the TYPO3 interface for years appreciate how intuitive modern WordPress block themes are. Targeted training workshops and modular block pattern libraries speed up editorial work considerably.
- Monitoring crawl errors in Google Search Console: In the first months after the relaunch, 404 error rates and indexing reports have to be checked daily, so that broken URLs are caught quickly with targeted 301 redirects. A carefully orchestrated switch from TYPO3 to WordPress secures your company’s digital future and significantly reduces long-term maintenance costs.
What advantages does WordPress have over TYPO3 for companies?
The strategic switch to WordPress offers clear business advantages:
- More developer availability and a more flexible choice of partners: While specialists for outdated TYPO3 versions are scarce and very expensive, the global WordPress ecosystem gives access to thousands of highly qualified developers and agencies worldwide.
- Faster time to market for new marketing campaigns: Thanks to the modular Gutenberg editor, marketing teams can create and publish new landing pages and high-converting content on their own, without external developer support.
- Conclusion: Modernising the CMS infrastructure removes technical ballast, noticeably lowers running costs and prepares your digital business model for the requirements of the coming years.
Professional, forward-looking support for the CMS migration ensures a smooth transition without losing visibility in Google and gives your company a lasting competitive edge in a dynamic online market. Quality always wins in the market.
