Dein Deploy wartet 40 Minuten, während TYPO3 den Cache zum dritten Mal in dieser Woche regeneriert. Frontend-Entwickler reichen ein weiteres Ticket ein und fragen, warum sie ein einfaches Carousel nicht ausliefern können, ohne TypoScript zu ändern. Marketing möchte, dass der gleiche Content Block in der Mobile App und in der E-Mail erscheint – TYPO3 wurde dafür nicht gebaut. Du betreibst diesen Monolithen seit Jahren, vielleicht ein Jahrzehnt, und er hat dir gut gedient. Aber die Architektur, die TYPO3 für komplexe europäische Enterprise-Sites mächtig gemacht hat – die enge Kopplung zwischen Content, Templates und Rendering – ist jetzt das, was jeden Sprint verlangsamt. React-Komponenten bleiben ungenutzt. API-first-Delivery bleibt Theorie. Dein Content ist in einem System gefangen, das davon ausgeht, dass er nur auf einer Website lebt. Die Frage ist nicht mehr, ob du migrieren solltest – es ist, wie du 47.000 Content-Records, 8-sprachige URL-Strukturen und SEO-Rankings erhältst, während dein Team Features ausliefert.

Hier kommt die Headless-CMS-Migration ins Spiel. Ich bin mehrfach durch diesen Prozess gegangen – habe Organisationen von TYPO3 zu Headless-Architekturen gebracht – und ich bin ehrlich: Es ist nie so einfach, wie die Vendor-Marketing-Seiten nahelegen. Aber es ist absolut sinnvoll, wenn die Bedingungen stimmen. Dieser Leitfaden behandelt die echten Entscheidungen, Fallstricke und Strategien bei der Migration von TYPO3 zu einem Headless CMS.

Inhaltsverzeichnis

TYPO3 to Headless CMS Migration: A Practical Developer Guide

Warum Teams TYPO3 verlassen

Lass mich klar sagen: TYPO3 ist keine schlechte Software. Es ist reif, gut gewartet und hat eine engagierte Community, besonders in Deutschland, Österreich und der Schweiz. Aber es hat bestimmte architektonische Einschränkungen, die im großen Maßstab schmerzhaft werden.

Developer Experience Friction

TYPO3s Templating-System (Fluid) ist mächtig, aber nischig. Entwickler zu finden, die Fluid, TypoScript und Extbase/TYPO3s Extension-Framework kennen, wird immer schwieriger. Die Lernkurve ist steil, und jüngere Entwickler bevorzugen überwiegend JavaScript-Frameworks. Ich habe gesehen, dass sich Einstellungs-Timelines verdoppelt haben, weil Teams keine TYPO3-erfahrenen Entwickler finden konnten.

Performance-Einschränkungen

TYPO3 rendert Seiten server-seitig durch PHP. Während Caching hilft, bist du grundsätzlich durch den monolithischen Request-Zyklus begrenzt. Static Site Generation und Edge Rendering – das, was moderne Frameworks gut können – sind nicht nativ in TYPOs Architektur. Die TYPO3 Headless Extension (EXT:headless) existiert und verwandelt TYPO3 in eine API, aber zu diesem Punkt maintainst du ein PHP-Backend, das immer weniger tatsächliche Arbeit verrichtet.

Content-Wiederverwendungs-Herausforderungen

TYPOs Content-Modell ist seitenzentriert. Content-Elemente leben auf Seiten. Wenn du Content gleichzeitig an eine Mobile App, einen Digital Kiosk, ein E-Mail-System und eine Website liefern musst, kämpft TYPOs Modell dich auf jedem Schritt. Headless-CMS-Plattformen behandeln Content von Anfang an als strukturierte Daten, was Multi-Channel-Delivery natürlich statt improvisiert macht.

Gesamtbetriebskosten

TYPO3 zu betreiben bedeutet, PHP-Server zu verwalten, TYPO3-Core-Updates zu verwalten (was zwischen Major-Versionen nicht trivial sein kann) und Extensions kompatibel zu halten. Ein Headless SaaS CMS beseitigt die meisten Infrastruktur-Overheads. Auch Self-hosted-Headless-Optionen wie Strapi oder Directus erfordern typischerweise weniger operativen Aufwand.

Wann Migration wirklich Sinn macht

Nicht jede TYPO3-Site muss zu Headless gehen. Hier ist meine ehrliche Einschätzung:

Szenario Migrieren? Warum
Einfache Broschüren-Website, 50 Seiten, eine Sprache Wahrscheinlich nicht Overkill. TYPO3 funktioniert hier gut.
Multi-Language Enterprise-Site mit Mobile Apps Ja Headless glänzt bei Omnichannel-Delivery
E-Commerce mit komplexen Produktdaten Ja Bessere Frontend-Flexibilität, API-First-Integrationen
Site mit vielen TYPO3 Extensions (news, events, forms) Vielleicht Audit Extension-Dependencies erst
Internes Portal mit TYPO3 Backend-Workflows Vorsicht Möglicherweise verlierst du Workflow-Features, die schwer zu ersetzen sind
Team kann keine TYPO3-Entwickler anstellen Ja Nachhaltigkeit ist wichtiger als Features

Die Migration macht am meisten Sinn, wenn du ohnehin ein Redesign oder Platform-Upgrade planst. Migration rein aus technischen Gründen – ohne Business-Trigger – kämpft oft um Budget-Genehmigung.

Auswahl deines Headless CMS

Hier bleiben Teams stecken. Es gibt Dutzende von Headless-CMS-Optionen, und die richtige Wahl hängt stark von deiner spezifischen Situation ab.

Enterprise-Grade-Optionen

Contentful bleibt der Marktführer für Enterprise Headless CMS. Pricing beginnt bei etwa 300 USD/Monat für den Team Plan und skaliert zu Custom Enterprise Pricing (typischerweise 2.000-10.000+ USD/Monat je nach Nutzung). Es ist reif, gut dokumentiert und hat exzellente SDKs. Das Content Modeling ist flexibel, und die Compose-Feature behandelt Page-Building Use Cases, an die TYPO3-Editoren gewöhnt sind.

Sanity ist mein persönlicher Favorit für Developer Experience. Das Pricing-Modell ist großzügig – die kostenlose Tier behandelt viele kleine Projekte, und der Team Plan bei 15 USD/Benutzer/Monat ist angemessen. Sanity Studio ist vollständig mit React anpassbar, so dass du Editorial-Experiences bauen kannst, die TYPOs Backend erfüllen oder übertreffen. Die GROQ-Query-Sprache erfordert etwas Gewöhnung, ist aber unglaublich mächtig, wenn du es tust.

Storyblok verdient besondere Aufmerksamkeit für TYPO3-Migrationen, weil es einen visuellen Editor anbietet, der sich für TYPO3-Backend-Benutzer vertraut anfühlt. Pricing beginnt bei €99/Monat für den Entry Plan. Es ist besonders beliebt in der DACH-Region, die stark mit TYPOs Benutzerbasis überlappt.

Open-Source-Alternativen

Strapi (v5 veröffentlicht 2024) ist die führende Open-Source-Option. Du kannst es Self-hosten oder Strapi Cloud nutzen (ab 29 USD/Monat pro Seat). Es ist Node.js-basiert, nutzt PostgreSQL oder MySQL und bietet ein wachsendes Plugin-Ökosystem.

Directus wrappet jede SQL-Datenbank mit einer API und Admin-Panel. Es ist eine großartige Wahl, wenn du deine existierende Datenbankstruktur behalten und schrittweise migrieren möchtest. Die Open-Source-Version ist vollständig ausgestattet; die Cloud-Version beginnt bei 99 USD/Monat.

Vergleichstabelle: Headless-CMS-Optionen für TYPO3-Migration

Feature Contentful Sanity Storyblok Strapi Directus
Hosting-Modell SaaS SaaS + Self-host SaaS Self-host + Cloud Self-host + Cloud
Visueller Editor Compose (Add-on) Anpassbar Eingebaut Plugin Begrenzt
Multi-Language Ausgezeichnet Gut Ausgezeichnet Gut Gut
Einstiegspreis 300 USD/Mo Kostenlose Tier €99/Mo Kostenlos (OSS) Kostenlos (OSS)
TYPO3-Editor-Vertrautheit Mittel Niedrig Hoch Mittel Mittel
Content Modeling Flexibel Sehr flexibel Komponenten-basiert Flexibel Datenbankgesteuert
Webhooks/Workflows Ja Ja Ja Ja Ja

Wir arbeiten mit den meisten dieser Plattformen durch unsere Headless-CMS-Entwicklungsdienste. Die Wahl hängt oft davon ab, ob deine Editoren eine visuelle Editing-Erfahrung benötigen (Storyblok, Contentful Compose) oder ob Developer-Flexibilität die Priorität ist (Sanity, Strapi).

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

Content Modeling: Der schwierige Teil

Hier gehen die meisten Migrationen schief. TYPOs Content-Modell ist grundlegend anders als Headless-CMS-Content-Modelle, und du kannst das eine nicht einfach auf das andere abbilden.

Verstehen von TYPOs Content-Struktur

In TYPO3 ist Content organisiert als:

  • Seiten (der Seitenbaum) mit Properties und Metadaten
  • Content-Elemente (tt_content) positioniert in Spalten auf Seiten
  • Extensions, die benutzerdefinierte Record-Typen hinzufügen (news, events, etc.)
  • Kategorien und Datei-Verweise verlinkt durch die sys_file_reference-Tabelle
  • TypoScript-Konfiguration, die Rendering und Datenfluss beeinflusst

Das ist ein seitenerstesModell. Content existiert im Kontext einer Seite.

Headless Content Modeling

Headless-CMS-Plattformen nutzen ein inhaltserstes Modell. Du definierst Content-Typen (wie Artikel, Autor, Produkt) mit Feldern und komponierst dann Seiten aus Verweisen auf diese Content-Items. Die Seite selbst ist oft nur ein weiterer Content-Typ.

Die Übersetzungsarbeit sieht etwa so aus:

TYPO3 Seitenbaum          →  Page-Content-Typ mit slug/hierarchy-Feldern
tt_content (text)        →  Rich-Text-Komponente/Block
tt_content (image)       →  Media-Komponente mit Asset-Verweisen
tx_news_domain_model_news →  Article/News-Content-Typ
Kategorien (sys_category) →  Tags/Categories-Content-Typ
Datei-Verweise          →  Asset-Management (DAM)

Praktische Beratung

Versuche nicht, TYPOs Content-Modell in deinem Headless CMS zu replizieren. Das ist eine Chance, deine Content-Architektur zu überdenken und zu verbessern. Beginne mit einem Audit:

  1. Welche Content-Typen existieren? Exportiere deine tt_content CTypes und liste alle Extension Record-Typen auf.
  2. Welche Felder werden tatsächlich verwendet? TYPO3-Tabellen haben Dutzende von Feldern. Der meiste Content nutzt nur eine Handvoll.
  3. Was sind die Beziehungen? Kartografiere, wie Content anderer Content referenziert.
  4. Wie sieht die Übersetzungs-Setup aus? TYPO3 unterstützt verbundene und freie Übersetzungsmodi – dein Headless CMS muss mit dem umgehen, den du nutzt.
-- Hilfreiche TYPO3-Audit-Abfragen
-- Content-Elemente nach Typ zählen
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Seiten nach doktype zählen
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- Alle verwendeten Sprachen suchen
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Datenmigrationsstrategien

Sobald dein Content-Modell im Ziel-CMS definiert ist, musst du die Daten tatsächlich verschieben. Es gibt drei Hauptansätze.

Ansatz 1: Script-basierter Export/Import

Schreibe Scripts, die TYPOs Datenbank direkt abfragen, die Daten transformieren und sie über die Management API des Headless CMS pushen. Das ist der häufigste Ansatz und gibt dir die meiste Kontrolle.

// Beispiel: Migrieren von TYPO3 News Records zu 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(`Migriert: ${row.title}`);
  }
}

Die convertRteToRichText-Funktion ist dort, wo es unordentlich wird. TYPOs RTE-Output ist HTML (oft mit benutzerdefinierten Tags wie <link> für interne Links). Die Konvertierung zu strukturierten Rich-Text-Formaten variiert je nach CMS – Contentful nutzt sein eigenes Rich-Text-JSON, Sanity nutzt Portable Text, etc.

Ansatz 2: TYPO3 Headless Extension als Brücke

Installiere die EXT:headless Extension auf deiner existierenden TYPO3-Instanz. Das verwandelt TYPO3 in eine JSON API, die du dann von Migration Scripts konsumieren kannst oder sogar temporär als dein Headless-Backend nutzen kannst, während du das neue Frontend baust.

Dieser Ansatz hat einen schönen Vorteil: Du kannst das neue Frontend erst gegen TYPOs Headless API laufen lassen, dann später das Backend zu einem echten Headless CMS wechseln. Es bricht die Migration in zwei Phasen auf.

Ansatz 3: Manuelle Rekonstruktion

Für kleinere Sites (unter 100 Seiten) ist es manchmal schneller, Content einfach manuell im neuen CMS zu rekonstruieren. Besonders wenn du auch Struktur- und Inhalts-Umstrukturierung und -Umschrift machst – was du wahrscheinlich solltest.

Frontend-Architektur-Entscheidungen

Mit einem Headless CMS brauchst du ein separates Frontend. Das ist hier die echten Performance-Gewinne.

Next.js

Die beliebteste Wahl. Server-Side Rendering, Static Generation, Inkrementelle Static Regeneration – Next.js behandelt alle Rendering-Strategien, die du möglicherweise brauchst. Der App Router (stabil seit Next.js 13.4) mit React Server Components ist besonders gut für Content-Heavy Sites geeignet. Wir machen viel diese Arbeit durch unsere Next.js Entwicklungspraxis.

Astro

Für Content-Heavy Sites, die nicht viel Interaktivität brauchen, ist Astro phänomenal. Es liefert standardmäßig null JavaScript und unterstützt partielle Hydration durch seine Islands Architecture. Wir haben Lighthouse-Scores konsistent 95+ mit Astro-Builds gesehen, was eine dramatische Verbesserung gegenüber typischer TYPO3-Frontend-Performance ist. Schau dir unsere Astro-Entwicklungsdienste an, wenn dich das interessiert.

Nuxt

Wenn dein Team Vue über React bevorzugt, ist Nuxt 3 das Äquivalent zu Next.js. Solide Wahl, großartige DX, gutes Ökosystem.

Framework Beste für JS verschifft Lernkurve CMS-Integrationen
Next.js Dynamische Apps, E-Commerce, Dashboards Medium-Hoch Mittel Ausgezeichnet
Astro Content-Sites, Blogs, Marketing Minimal Niedrig Ausgezeichnet
Nuxt 3 Vue-Teams, Content + Apps Mittel Mittel Gut
SvelteKit Kleine Teams, die Simplizität wollen Niedrig Niedrig-Mittel Wächst

Umgang mit TYPO3-spezifischen Features

Einige TYPO3-Features haben keine direkten Äquivalente in der Headless-Welt. Hier ist, wie du die häufigen handhast.

Workspaces und Versionierung

TYPOs Workspace-System lässt Editoren Änderungen über mehrere Seiten hinweg stagieren, bevor sie veröffentlicht werden. Die meisten Headless-CMS-Plattformen bieten Environments oder Release-Planung, die dies teilweise replizieren. Contentful hat Environments und Scheduled Publishing. Sanity hat Releases (kürzlich gestartet). Keine ist out-of-the-box so anspruchsvoll wie TYPOs Workspaces, so dass wenn deine Editoren schwer auf Workspaces angewiesen sind, plane für Workflow-Anpassungen.

Backend-Benutzerberechtigungen

TYPOs Berechtigungssystem ist extrem granular – Seiten-Level, Content-Element-Level, Feld-Level-Zugriffskontrollen. Headless-CMS-Plattformen variieren hier stark. Contentfuls Rollensystem ist anständig aber weniger granular. Sanitys ist flexibler aber erfordert benutzerdefinierte Konfiguration. Strapis rollenbasierter Zugriff ist gut. Audit deine aktuelle Berechtigungsmatrix und validiere, dass das Ziel-CMS es handhaben kann, bevor du dich bindest.

Formular-Bearbeitung

TYPOs Form Framework (EXT:form) generiert Formulare aus YAML-Konfiguration. In einer Headless-Setup brauchst du einen Form-Dienst. Optionen umfassen Formspree, Basin oder das Bauen deiner eigenen mit Serverless-Funktionen. Wenn du Next.js nutzt, machen Server Actions die Formular-Bearbeitung unkompliziert.

Multi-Language und Lokalisierung

Das ist kritisch und wird oft unterschätzt. TYPOs Übersetzungs-Handling – mit seinem Konzept von Language Overlays, verbundenenem/freiem Modus und Fallback-Ketten – ist anspruchsvoll. Kartografiere deine genauen Übersetzungs-Anforderungen, bevor du ein CMS wählst. Storyblok und Contentful handhaben Locale-Management gut. Sanity erfordert mehr benutzerdefinierte Setup für komplexe Multi-Language-Szenarien.

SEO-Erhalt während der Migration

Dieser Abschnitt ist wahrscheinlich der wichtigste. Eine vermasselten Migration kann dein organisches Verkehr zusammenbrechen lassen.

URL-Mapping

Exportiere jede URL aus deiner TYPO3-Site. Jede. Einzelne. Eine. Nutze einen Crawler wie Screaming Frog oder wget --spider, um eine komplette URL-Liste zu bauen. Dann erstelle eine Redirect-Map:

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

Implementiere 301-Redirects für jede URL, die sich ändert. In Next.js geht das in next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... Hunderte mehr, idealerweise aus einer JSON-Datei geladen
    ];
  },
};

Für große Redirect-Listen (500+), erwäge, Redirects am Edge zu handhaben (Vercel Edge Middleware, Cloudflare Workers oder nginx) statt in deiner Anwendungs-Config.

Meta-Daten-Migration

TYPO3 speichert SEO-Metadaten in der pages-Tabelle (seo_title, description, og_image, etc.) und potenziell in Extensions wie EXT:cs_seo oder EXT:seo_basics. Extrahiere all das und migriere es zu deinem Headless-CMS-Content-Modell. Vergiss nicht:

  • Seiten-Titel und Meta-Beschreibungen
  • Open Graph und Twitter Card Daten
  • Kanonische URLs
  • hreflang-Tags für mehrsprachige Sites
  • Strukturierte Daten / JSON-LD Schemas
  • XML-Sitemap-Generierung

Überwachung

Richte Google Search Console für die neue Domain/Subdomain vor der Migration ein. Nach dem Go-Live, überwache den Coverage Report täglich für die erste zwei Wochen. Beobachte auf Crawl-Fehler, gelöschte Seiten und Indexierungs-Probleme. Habe einen Rollback-Plan.

Test- und Go-Live-Strategie

Ich empfehle einen gestaffelten Ansatz statt eines Big-Bang-Cutover.

Phase 1: Paralleles Laufen (2-4 Wochen)

Führe die neue Headless-Site auf einer Staging-Domain aus. Vergleiche Content-Parität mit der TYPO3-Site. Lasse Editoren Content-Workflows testen. Führe automatisierte visuelle Regressions-Tests mit Tools wie Percy oder Playwright aus.

Phase 2: Soft Launch

Route einen kleinen Prozentsatz des Verkehrs zur neuen Site mit Feature Flags oder A/B Testing auf CDN-Level. Überwache Core Web Vitals, Error-Raten und Benutzer-Verhalten.

Phase 3: Vollständiger Cutover

Wechsle DNS oder Reverse-Proxy-Konfiguration. Aktiviere alle Redirects. Überwache aggressiv für 48 Stunden. Halte die TYPO3-Instanz (read-only) für mindestens 30 Tage als Referenz am Laufen.

Phase 4: Decommission

Sobald du zuversichtlich bist, dass die Migration stabil ist, fahre die TYPO3-Infrastruktur herunter. Archiviere die Datenbank und fileadmin-Verzeichnis. Du wirst dir später selbst danken, wenn jemand nach altem Content fragt.

Reale Migrations-Timeline und Kosten

Lass mich ehrlich sein, welches das kostet. Ich habe zu viele Teams gesehen, die Migrations-Projekte unterschätzen.

Projektgröße Seiten Timeline Geschätzte Kosten
Klein 50-200 6-10 Wochen 15.000-35.000 USD
Mittel 200-1.000 12-20 Wochen 40.000-90.000 USD
Groß 1.000-5.000 20-36 Wochen 80.000-200.000 USD
Enterprise 5.000+ 6-12 Monate 150.000-500.000+ USD

Diese Zahlen beinhalten Content Modeling, Migration Scripting, Frontend-Entwicklung, Testing und Launch-Support. Sie beinhalten nicht CMS-Lizenzierungskosten, die je nach Plattform variieren.

Die größten Kostentreiber sind:

  1. Anzahl von Content-Typen und Komplexität – nicht Raw-Seitenzahl
  2. Benutzerdefinierte TYPO3 Extensions, die äquivalente Funktionalität brauchen
  3. Multi-Language Setup Komplexität
  4. Integrations-Anforderungen (Suche, E-Commerce, Authentifizierung)
  5. Editorial-Training und Change Management

Wenn du diskutieren möchtest, wie eine Migration für dein spezifisches Setup aussehen könnte, kontaktiere uns oder schau dir unsere Pricing-Seite für Engagement-Modelle an.

Häufig gestellte Fragen

Kann ich TYPO3 als Headless CMS nutzen, statt zu einem neuen zu migrieren? Ja, die EXT:headless Extension (ehemals "headless") verwandelt TYPO3 in eine JSON API. Das kann eine gute Zwischenphase sein. Allerdings maintainst du immer noch ein TYPO3-Backend mit all seinem operativen Overhead. Es macht Sinn als Bridge-Strategie, ist aber gewöhnlich nicht die langfristige Antwort, wenn dein Ziel die Reduktion von TYPO3-Abhängigkeit ist.

Wie lange dauert eine typische TYPO3-zu-Headless-CMS-Migration? Für eine mittelgroße Site (200-1.000 Seiten), erwarte 3-5 Monate vom Kickoff zum Launch. Die Content-Modeling- und Migration-Scripting-Phasen nehmen typischerweise länger als Teams erwarten. Frontend-Entwicklung kann oft parallel laufen, sobald das Content-Modell definiert ist. Enterprise-Migrationen mit mehreren Sprachen und komplexen Integrationen können 6-12 Monate dauern.

Werde ich SEO-Rankings während der Migration verlieren? Du solltest nicht, wenn du es richtig machst. Die kritischen Faktoren sind: Implementiere richtige 301-Redirects für alle geänderten URLs, migriere alle Meta-Daten, halte deine Site-Struktur und internes Linking, und reiche aktualisierte Sitemaps bei Google ein. Ein temporärer Ranking-Rückgang für 2-4 Wochen nach Migration ist normal und erholt sich gewöhnlich. Permanente Verluste deuten typischerweise auf fehlende Redirects oder verlorene Inhalte hin.

Welches Headless CMS ist am besten, um TYPO3 zu ersetzen? Es hängt von deinen Prioritäten ab. Storyblok ist oft der glatteste Übergang für TYPO3-Editoren, wegen seiner visuellen Editing-Möglichkeiten. Contentful ist die sicherste Enterprise-Wahl mit dem reifesten Ökosystem. Sanity bietet die meiste Developer-Flexibilität. Strapi ist die beste Option, wenn du Open Source und Self-Hosting brauchst. Es gibt keine einzelne beste Antwort – es hängt von deinem Team, Budget und Anforderungen ab.

Was passiert mit meinen TYPO3 Extensions nach der Migration? Jede Extension muss einzeln ausgewertet werden. Häufige Extensions wie EXT:news, EXT:cal und EXT:powermail brauchen äquivalente Funktionalität in deinem neuen Stack. News/Blog-Funktionalität ist unkompliziert mit jedem Headless CMS zu replizieren. Kalender- und Event-Features brauchen möglicherweise Third-Party-Services. Forms erfordern eine neue Lösung (Form Builders, Serverless-Funktionen oder Services wie Formspree). Benutzerdefinierte Extensions brauchen die meiste Analyse.

Wie handhabe ich TYPOs fileadmin-Assets während der Migration? Du musst alle Assets (Bilder, PDFs, Videos) zu deines neuen CMSs Asset-Management-System oder ein separates DAM/CDN migrieren. Schreibe ein Script, das von fileadmin herunterlädt, zum neuen Platform via dessen API hochlädt und alte Datei-Verweise zu neuen Asset-IDs mapped. Vergiss nicht auf verarbeitete/resized Bilder – die meisten Headless-CMS-Plattformen handhaben Bild-Transformation automatisch, so dass du typischerweise nur Originals migrieren brauchst.

Kann ich schrittweise migrieren oder muss es auf einmal sein? Inkrementelle Migration ist möglich und manchmal empfehlenswert für große Sites. Du kannst einen Reverse Proxy nutzen, um bestimmte URL-Paths zur neuen Headless-Frontend zu routen, während du andere auf TYPO3 behältst. Das lässt dich Sektion um Sektion migrieren. Das Trade-off ist erhöhte Komplexität beim gleichzeitigen Management von zwei Systemen und Erhalt von konsistenter Navigation und Design über beide.

Was sollte ich über TYPO3-Backend-Benutzer tun, die gegen Veränderung widerständig sind? Change Management ist wirklich halb die Schlacht. Beginne damit, Editoren früh einzubeziehen – zeige ihnen das neue CMS während der Content-Modeling-Phase, nicht nachdem alles gebaut ist. Wähle ein CMS mit einer guten Editing-Erfahrung (Storyblok und Contentful bekommen gewöhnlich das beste Editor-Feedback). Erstelle Dokumentation und Training-Materialien spezifisch zu deinem Setup. Und sei ehrlich über das, was sich ändert und warum – Editoren kommen gewöhnlich herum, wenn sie die verbesserte Preview-Erfahrung und schnellere Publishing-Workflows sehen.