If you've spent any significant time working with TYPO3, you know it's a beast. Not in a bad way -- it's incredibly powerful, especially for large European enterprise sites with complex content structures, multi-language setups, and granular permissions. But there's a growing realization among teams running TYPO3 installations: the monolithic architecture is holding them back. Frontend developers want to use React or Vue. Marketing teams want omnichannel content delivery. DevOps wants simpler deployments. And everyone wants better performance.

That's where headless CMS migration comes in. I've been through this process multiple times -- taking organizations from TYPO3 to headless architectures -- and I'll be honest: it's never as simple as the vendor marketing pages suggest. But it's absolutely worth doing when the conditions are right. This guide covers the real decisions, pitfalls, and strategies involved in migrating from TYPO3 to a headless CMS.

Table of Contents

TYPO3 to Headless CMS Migration: A Practical Developer Guide

Why Teams Leave TYPO3

Let me be clear: TYPO3 isn't bad software. It's mature, well-maintained, and has a dedicated community, particularly in Germany, Austria, and Switzerland. But it carries certain architectural constraints that become painful at scale.

Developer Experience Friction

TYPO3's templating system (Fluid) is powerful but niche. Finding developers who know Fluid, TypoScript, and Extbase/TYPO3's extension framework is increasingly difficult. The learning curve is steep, and younger developers overwhelmingly prefer working with JavaScript frameworks. I've seen hiring timelines double because teams couldn't find TYPO3-proficient developers.

Performance Limitations

TYPO3 renders pages server-side through PHP. While caching helps, you're fundamentally limited by the monolithic request cycle. Static site generation and edge rendering -- the stuff modern frameworks do well -- aren't native to TYPO3's architecture. The TYPO3 Headless extension (EXT:headless) exists and turns TYPO3 into an API, but at that point you're maintaining a PHP backend that's doing less and less of the actual work.

Content Reuse Challenges

TYPO3's content model is page-centric. Content elements live on pages. If you need to deliver content to a mobile app, a digital kiosk, an email system, and a website simultaneously, TYPO3's model fights you at every step. Headless CMS platforms treat content as structured data from the start, making multi-channel delivery natural rather than bolted on.

Total Cost of Ownership

Running TYPO3 means maintaining PHP servers, managing TYPO3 core updates (which can be non-trivial between major versions), and keeping extensions compatible. A headless SaaS CMS eliminates most infrastructure overhead. Even self-hosted headless options like Strapi or Directus typically require less operational effort.

When Migration Actually Makes Sense

Not every TYPO3 site needs to go headless. Here's my honest assessment:

Scenario Migrate? Why
Simple brochure site, 50 pages, one language Probably not Overkill. TYPO3 works fine here.
Multi-language enterprise site with mobile apps Yes Headless shines for omnichannel delivery
E-commerce with complex product data Yes Better frontend flexibility, API-first integrations
Site with heavy TYPO3 extensions (news, events, forms) Maybe Audit extension dependencies first
Internal portal with TYPO3 backend workflows Careful You may lose workflow features that are hard to replace
Team can't hire TYPO3 developers Yes Sustainability matters more than features

The migration makes the most sense when you're already planning a redesign or platform upgrade. Migrating purely for technical reasons -- without a business trigger -- often struggles to get budget approval.

Choosing Your Headless CMS

This is where teams get stuck. There are dozens of headless CMS options, and the right choice depends heavily on your specific situation.

Enterprise-Grade Options

Contentful remains the market leader for enterprise headless CMS. Pricing starts around $300/month for the Team plan and scales to custom enterprise pricing (typically $2,000-$10,000+/month depending on usage). It's mature, well-documented, and has excellent SDKs. The content modeling is flexible, and the Compose feature handles page-building use cases that TYPO3 editors are accustomed to.

Sanity is my personal favorite for developer experience. The pricing model is generous -- the free tier handles many small projects, and the Team plan at $15/user/month is reasonable. Sanity Studio is fully customizable with React, so you can build editorial experiences that match or exceed what TYPO3's backend offers. The GROQ query language takes some getting used to, but it's incredibly powerful once you do.

Storyblok deserves special attention for TYPO3 migrations because it offers a visual editor that feels familiar to TYPO3 backend users. Pricing starts at €99/month for the Entry plan. It's particularly popular in the DACH region, which overlaps heavily with TYPO3's user base.

Open-Source Alternatives

Strapi (v5 released in 2024) is the leading open-source option. You can self-host it or use Strapi Cloud (starting at $29/month per seat). It's Node.js-based, uses a PostgreSQL or MySQL database, and offers a plugin ecosystem that's growing quickly.

Directus wraps any SQL database with an API and admin panel. It's a great choice if you want to keep your existing database structure and gradually migrate. The open-source version is fully featured; the cloud version starts at $99/month.

Comparison Table: Headless CMS Options for TYPO3 Migration

Feature Contentful Sanity Storyblok Strapi Directus
Hosting Model SaaS SaaS + Self-host SaaS Self-host + Cloud Self-host + Cloud
Visual Editor Compose (add-on) Customizable Built-in Plugin Limited
Multi-language Excellent Good Excellent Good Good
Starting Price $300/mo Free tier €99/mo Free (OSS) Free (OSS)
TYPO3 Editor Familiarity Medium Low High Medium Medium
Content Modeling Flexible Very Flexible Component-based Flexible Database-driven
Webhooks/Workflows Yes Yes Yes Yes Yes

We work with most of these platforms through our headless CMS development services. The choice often comes down to whether your editors need a visual editing experience (Storyblok, Contentful Compose) or whether developer flexibility is the priority (Sanity, Strapi).

TYPO3 to Headless CMS Migration: A Practical Developer Guide - architecture

Content Modeling: The Hard Part

Here's where most migrations go sideways. TYPO3's content model is fundamentally different from headless CMS content models, and you can't just map one to the other.

Understanding TYPO3's Content Structure

In TYPO3, content is organized as:

  • Pages (the page tree) with properties and metadata
  • Content elements (tt_content) positioned in columns on pages
  • Extensions that add custom record types (news, events, etc.)
  • Categories and file references linked through the sys_file_reference table
  • TypoScript configuration that affects rendering and data flow

This is a page-first model. Content exists in the context of a page.

Headless Content Modeling

Headless CMS platforms use a content-first model. You define content types (like Article, Author, Product) with fields, and then compose pages from references to those content items. The page itself is often just another content type.

The translation work looks something like this:

TYPO3 Page Tree          →  Page content type with slug/hierarchy fields
tt_content (text)        →  Rich text component/block
tt_content (image)       →  Media component with asset references
tx_news_domain_model_news →  Article/News content type
Categories (sys_category) →  Tags/Categories content type
File references          →  Asset management (DAM)

Practical Advice

Don't try to replicate TYPO3's content model in your headless CMS. This is a chance to rethink and improve your content architecture. Start by auditing:

  1. What content types exist? Export your tt_content CTypes and list all extension record types.
  2. What fields actually get used? TYPO3 tables have dozens of fields. Most content only uses a handful.
  3. What are the relationships? Map out how content references other content.
  4. What's the translation setup? TYPO3 supports connected and free translation modes -- your headless CMS needs to handle whichever you use.
-- Useful TYPO3 audit queries
-- Count content elements by type
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Count pages by doktype
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- Find all languages in use
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Data Migration Strategies

Once your content model is defined in the target CMS, you need to actually move the data. There are three main approaches.

Approach 1: Script-Based Export/Import

Write scripts that query TYPO3's database directly, transform the data, and push it into the headless CMS via its management API. This is the most common approach and gives you the most control.

// Example: Migrating TYPO3 news records to Contentful
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`Migrated: ${row.title}`);
  }
}

The convertRteToRichText function is where things get messy. TYPO3's RTE output is HTML (often with custom tags like <link> for internal links). Converting this to structured rich text formats varies by CMS -- Contentful uses its own rich text JSON, Sanity uses Portable Text, etc.

Approach 2: TYPO3 Headless Extension as Bridge

Install the EXT:headless extension on your existing TYPO3 instance. This turns TYPO3 into a JSON API, which you can then consume from migration scripts or even use temporarily as your headless backend while you build the new frontend.

This approach has a nice advantage: you can run the new frontend against TYPO3's headless API first, then switch the backend to a proper headless CMS later. It breaks the migration into two phases.

Approach 3: Manual Recreation

For smaller sites (under 100 pages), sometimes it's faster to just recreate content manually in the new CMS. Especially if you're also restructuring and rewriting content -- which you probably should be.

Frontend Architecture Decisions

With a headless CMS, you need a separate frontend. This is where the real performance gains happen.

Next.js

The most popular choice. Server-side rendering, static generation, incremental static regeneration -- Next.js handles all the rendering strategies you might need. The App Router (stable since Next.js 13.4) with React Server Components is particularly well-suited for content-heavy sites. We do a lot of this work through our Next.js development practice.

Astro

For content-heavy sites that don't need much interactivity, Astro is phenomenal. It ships zero JavaScript by default and supports partial hydration through its Islands Architecture. We've seen Lighthouse scores consistently hit 95+ with Astro builds, which is a dramatic improvement over typical TYPO3 frontend performance. Check out our Astro development services if this interests you.

Nuxt

If your team prefers Vue over React, Nuxt 3 is the equivalent of Next.js. Solid choice, great DX, good ecosystem.

Framework Best For JS Shipped Learning Curve CMS Integrations
Next.js Dynamic apps, e-commerce, dashboards Medium-High Medium Excellent
Astro Content sites, blogs, marketing Minimal Low Excellent
Nuxt 3 Vue teams, content + apps Medium Medium Good
SvelteKit Small teams wanting simplicity Low Low-Medium Growing

Handling TYPO3-Specific Features

Some TYPO3 features don't have direct equivalents in the headless world. Here's how to handle the common ones.

Workspaces and Versioning

TYPO3's workspace system lets editors stage changes across multiple pages before publishing. Most headless CMS platforms offer environments or release scheduling that partially replicate this. Contentful has Environments and Scheduled Publishing. Sanity has Releases (recently launched). None are as sophisticated as TYPO3 Workspaces out of the box, so if your editors rely heavily on workspaces, plan for workflow adjustments.

Backend User Permissions

TYPO3's permission system is extremely granular -- page-level, content-element-level, field-level access controls. Headless CMS platforms vary widely here. Contentful's role system is decent but less granular. Sanity's is more flexible but requires custom configuration. Strapi's role-based access is good. Audit your current permission matrix and validate that the target CMS can handle it before committing.

Form Handling

TYPO3's Form Framework (EXT:form) generates forms from YAML configuration. In a headless setup, you'll need a form service. Options include Formspree, Basin, or building your own with serverless functions. If you use Next.js, Server Actions make form handling straightforward.

Multilanguage and Localization

This is critical and often underestimated. TYPO3's translation handling -- with its concept of language overlays, connected/free mode, and fallback chains -- is sophisticated. Map your exact translation requirements before choosing a CMS. Storyblok and Contentful handle locale management well. Sanity requires more custom setup for complex multi-language scenarios.

SEO Preservation During Migration

This section might be the most important one. A botched migration can crater your organic traffic.

URL Mapping

Export every URL from your TYPO3 site. Every. Single. One. Use a crawler like Screaming Frog or wget --spider to build a complete URL list. Then create a redirect map:

/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf

Implement 301 redirects for every URL that changes. In Next.js, this goes in next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... hundreds more, loaded from a JSON file ideally
    ];
  },
};

For large redirect lists (500+), consider handling redirects at the edge (Vercel Edge Middleware, Cloudflare Workers, or nginx) rather than in your application config.

Meta Data Migration

TYPO3 stores SEO metadata in the pages table (seo_title, description, og_image, etc.) and potentially in extensions like EXT:cs_seo or EXT:seo_basics. Extract all of this and migrate it to your headless CMS content model. Don't forget:

  • Page titles and meta descriptions
  • Open Graph and Twitter Card data
  • Canonical URLs
  • hreflang tags for multilingual sites
  • Structured data / JSON-LD schemas
  • XML sitemap generation

Monitoring

Set up Google Search Console for the new domain/subdomain before migration. After go-live, monitor the Coverage report daily for the first two weeks. Watch for crawl errors, dropped pages, and indexing issues. Have a rollback plan.

Testing and Go-Live Strategy

I recommend a phased approach rather than a big-bang cutover.

Phase 1: Parallel Running (2-4 weeks)

Run the new headless site on a staging domain. Compare content parity with the TYPO3 site. Have editors test content workflows. Run automated visual regression tests with tools like Percy or Playwright.

Phase 2: Soft Launch

Route a small percentage of traffic to the new site using feature flags or A/B testing at the CDN level. Monitor Core Web Vitals, error rates, and user behavior.

Phase 3: Full Cutover

Switch DNS or reverse proxy configuration. Activate all redirects. Monitor aggressively for 48 hours. Keep the TYPO3 instance running (read-only) for at least 30 days as a reference.

Phase 4: Decommission

Once you're confident the migration is stable, shut down the TYPO3 infrastructure. Archive the database and fileadmin directory. You'll thank yourself later when someone asks about old content.

Real-World Migration Timeline and Costs

Let's be honest about what this costs. I've seen too many teams underestimate migration projects.

Project Size Pages Timeline Estimated Cost
Small 50-200 6-10 weeks $15,000-$35,000
Medium 200-1,000 12-20 weeks $40,000-$90,000
Large 1,000-5,000 20-36 weeks $80,000-$200,000
Enterprise 5,000+ 6-12 months $150,000-$500,000+

These numbers include content modeling, migration scripting, frontend development, testing, and launch support. They don't include CMS licensing costs, which vary by platform.

The biggest cost drivers are:

  1. Number of content types and complexity -- not raw page count
  2. Custom TYPO3 extensions that need equivalent functionality built
  3. Multi-language setup complexity
  4. Integration requirements (search, e-commerce, authentication)
  5. Editorial training and change management

If you want to discuss what a migration might look like for your specific setup, reach out to us or check our pricing page for engagement models.

FAQ

Can I use TYPO3 as a headless CMS instead of migrating to a new one? Yes, the EXT:headless extension (formerly "headless") turns TYPO3 into a JSON API. This can be a good intermediate step. However, you're still maintaining a TYPO3 backend with all its operational overhead. It makes sense as a bridge strategy but usually isn't the long-term answer if your goal is reducing TYPO3 dependency.

How long does a typical TYPO3 to headless CMS migration take? For a medium-sized site (200-1,000 pages), expect 3-5 months from kickoff to launch. The content modeling and migration scripting phases typically take longer than teams anticipate. Frontend development can often run in parallel once the content model is defined. Enterprise migrations with multiple languages and complex integrations can take 6-12 months.

Will I lose SEO rankings during migration? You shouldn't if you do it correctly. The critical factors are: implementing proper 301 redirects for all changed URLs, migrating all meta data, maintaining your site structure and internal linking, and submitting updated sitemaps to Google. A temporary dip in rankings for 2-4 weeks post-migration is normal and usually recovers. Permanent losses typically indicate missed redirects or lost content.

Which headless CMS is best for replacing TYPO3? It depends on your priorities. Storyblok is often the smoothest transition for TYPO3 editors because of its visual editing capabilities. Contentful is the safest enterprise choice with the most mature ecosystem. Sanity offers the most developer flexibility. Strapi is the best option if you need open source and self-hosting. There's no single best answer -- it depends on your team, budget, and requirements.

What happens to my TYPO3 extensions after migration? Each extension needs to be evaluated individually. Common extensions like EXT:news, EXT:cal, and EXT:powermail need equivalent functionality in your new stack. News/blog functionality is straightforward to replicate with any headless CMS. Calendar and event features might need third-party services. Forms require a new solution (form builders, serverless functions, or services like Formspree). Custom extensions need the most analysis.

How do I handle TYPO3's fileadmin assets during migration? You'll need to migrate all assets (images, PDFs, videos) to your new CMS's asset management system or a separate DAM/CDN. Write a script that downloads from fileadmin, uploads to the new platform via its API, and maps old file references to new asset IDs. Don't forget to handle processed/resized images -- most headless CMS platforms handle image transformation automatically, so you typically only need to migrate originals.

Can I migrate incrementally or does it have to be all at once? Incremental migration is possible and sometimes advisable for large sites. You can use a reverse proxy to route certain URL paths to the new headless frontend while keeping others on TYPO3. This lets you migrate section by section. The tradeoff is increased complexity in managing two systems simultaneously and maintaining consistent navigation and design across both.

What should I do about TYPO3 backend users who are resistant to change? Change management is genuinely half the battle. Start by involving editors early -- show them the new CMS during the content modeling phase, not after everything is built. Choose a CMS with a good editing experience (Storyblok and Contentful tend to get the best editor feedback). Create documentation and training materials specific to your setup. And be honest about what's changing and why -- editors usually come around when they see the improved preview experience and faster publishing workflows.