Content Migration war jahrelang der heimliche Kostenfresser in jedem CMS-Projekt. Wer einmal ein großes Relaunch oder einen Systemwechsel miterlebt hat, kennt das Bild: ein eigenes Migrationsteam, das über Wochen oder Monate aus alten Datenbanken exportiert, Felder mappt, Abhängigkeiten entflechtet, Medien umbenennt, Rich-Text repariert und am Ende eine Liste von Hand-Korrekturen hinterlässt. Die Produktion der Redaktion stand derweil still, die Nerven lagen blank, das Budget war länger gebunden als geplant. Und am Tag nach dem Go-Live kamen trotzdem die ersten Tickets mit kaputten Links.
Das war der Status quo. Er ist es nicht mehr.
Was Content Migration heute kostet, wenn man ehrlich rechnet
In klassischen Projekten verteilen sich die Kosten auf drei Bereiche, die in Angeboten selten zusammen auftauchen. Erstens: die reine Migrations-Pipeline — Export, Transformation, Import. Zweitens: die Nacharbeit — alles, was die Pipeline nicht abdeckt, weil die alte Datenhaltung „gewachsen“ war. Drittens: der Stillstand der Redaktion, weil in der Übergangsphase entweder doppelt gepflegt oder gar nichts veröffentlicht wird.
Unsere Erfahrung aus vielen Migrationen ist, dass die ersten beiden Punkte in Angeboten landen, der dritte aber fast nie. Dabei ist es oft der teuerste. Wenn eine Redaktion über acht Wochen nicht veröffentlichen kann, ist der entgangene Nutzen höher als die Lizenzkosten des neuen Systems.
Was sich mit KI-Agenten und MCP verändert hat
Seit einigen Monaten bauen wir Content Migration auf einem völlig anderen Fundament. Im Kern stehen zwei Bausteine: ein KI-Agent, der die bestehende Seite versteht, und ein Model-Context-Protocol-Server (MCP) auf dem neuen CMS, der dem Agenten strukturiert Schreibzugriff gibt. Der Agent liest die alte Seite, extrahiert Struktur und Inhalt, entscheidet auf Basis einer vorher festgelegten Mapping-Regel, welches neue Inhaltselement am besten passt, und schreibt das Ergebnis direkt ins neue CMS. Kein CSV-Import, keine Transformations-Skripte, kein Zwischenlager.
Dass das überhaupt geht, liegt an einem Architekturprinzip, das wir seit Monaten konsequent verfolgen: Das CMS selbst muss agent-ready sein. Es muss seine Schreibfähigkeiten nicht nur Redaktionen, sondern auch Agenten sauber zur Verfügung stellen — mit definierten Tools, Validierung, Workspace-Kontext, Rollen und Rollback. Genau das leistet unser AI-Ready CMS as a Service auf Basis von TYPO3. Der MCP ist keine Abkürzung um die Redaktion herum, sondern ein zweiter, gleich starker Schreibkanal neben ihr.
Wie das in der Praxis aussieht
Wir haben den Ansatz gerade erst in einem eigenen Projekt skaliert. Wir hatten 45 Blog-Posts als Markdown-Drafts vorliegen, mit Frontmatter, Bildprompts, Alt-Texten und thematisch passenden Zusätzen. Ein Agent hat sie gelesen, interpretiert, pro Post den richtigen Seitentyp ausgewählt und dann strukturiert in zwei Websites geschrieben: Blog Hero mit Titel und Teaser, Text & Bild mit dem Fließtext und Platzhalter für das spätere Hero-Image, CTA-Section mit thematisch passendem Button-Label, FAQ mit fünf redaktionell kuratierten Fragen, Meta-Felder, Open-Graph- und Twitter-Card-Daten. Alles in einem Rutsch, alles nachvollziehbar, alles revidierbar, weil jede Änderung im Workspace liegt und erst durch Publikation live geht.
Was früher ein mehrwöchiges Projekt gewesen wäre, war eine Arbeitssitzung am Nachmittag. Was früher ein Team gebraucht hätte, haben wir mit zwei Rollen gemacht: der Mensch, der die Mapping-Regeln festlegt und Qualität prüft. Der Agent, der die Ausführung übernimmt.
Was das für Ihr Unternehmen bedeutet
Die wichtigste Aussage zuerst: Das ist kein Knopfdruck-Versprechen. Qualitätskontrolle bleibt ein menschliches Handwerk, und sie muss es bleiben. Was sich radikal verändert hat, ist das Verhältnis zwischen Aufwand und Ergebnis. Die Pipeline ist nicht mehr das Projekt, sie ist ein Werkzeug. Die Redaktion bleibt handlungsfähig, weil die Migration im Hintergrund läuft und im Workspace vorerst unsichtbar liegt. Und die Nachlaufzeit nach Go-Live sinkt, weil die Struktur von Anfang an zum neuen System passt — statt wie früher irgendwie „hineingebogen“ zu werden.
Praktisch bedeutet das: Migrationen, für die wir früher zwei bis vier Monate geplant hätten, schaffen wir heute in Tagen. Nicht, weil wir weniger Sorgfalt anwenden, sondern weil wir einen Großteil des Aufwands an eine Maschine delegieren, die konsistent, geduldig und vollständig transparent arbeitet.
Lassen Sie uns über Ihre Migration sprechen
Wenn Sie vor einem CMS-Wechsel stehen oder ein großes Relaunch-Projekt planen, lohnt sich ein offenes Gespräch bevor Sie ein klassisches Migrationsangebot unterschreiben. Wir schauen uns Ihre bestehende Seite an, besprechen die Zielstruktur und sagen Ihnen realistisch, welchen Teil der Arbeit ein Agent heute übernehmen kann und welchen Sie weiterhin bewusst in menschliche Hände legen sollten. 30 Minuten, kein Pitch.
Häufige Fragen
Was Kundinnen und Kunden uns zum Thema Content Migration am häufigsten fragen — offen beantwortet.
Heißt das, Sie ziehen einfach alle alten Inhalte automatisch ins neue System?+
Nein. Der Agent arbeitet gegen ein Mapping, das wir mit Ihnen vorher festlegen — welcher Alt-Bereich wohin wandert, welche Felder übernommen werden, welche neu benannt werden. Was nicht eindeutig abbildbar ist, landet in einer Review-Queue und nicht im Frontend. Vollautomatik ohne menschliche Prüfung ist bei Content-Migrationen ein Risiko, das sich nicht rechnet.
Was passiert mit Bildern und Medien?+
Bilder werden referenziert und wo nötig umstrukturiert — gleiche Datei, neuer Kontext. Wo Ihre alte Medienverwaltung Lücken hat (fehlende Alt-Texte, chaotische Dateinamen, doppelte Assets), entscheidet das Mapping, ob wir ersetzen, regenerieren oder als TODO markieren. Eine Migration ist oft der beste Moment, Medien-Metadaten endlich sauber zu ziehen.
Wie stellen Sie Stilkonsistenz und Qualität sicher?+
Der Agent arbeitet gegen ein Styleguide-Profil, das Ihre Marke definiert — Tonalität, erlaubte Fachbegriffe, typografische Regeln, CTA-Muster. Am Ende prüft ein Mensch. Das Styleguide-Profil bauen wir einmal auf und pflegen es mit jeder Produktion weiter. So wird die Migration nicht zum Stil-Rückschritt, sondern zum Stil-Schliff.
Funktioniert das nur mit TYPO3 oder auch mit anderen CMS?+
Voraussetzung ist ein MCP-Server am Ziel-CMS, der die Schreibfähigkeiten strukturiert freigibt. Für TYPO3 haben wir das fertig. Für andere CMS bauen wir den MCP in überschaubarer Zeit — eher Wochen- als Monatsaufwand, und er rechnet sich im Migrationsprojekt selbst. Wichtig ist, dass der MCP dieselben Sicherheits- und Workspace-Regeln respektiert wie Ihre Redaktion.
Wie realistisch ist die Zeitersparnis wirklich?+
Faktor zehn gegenüber klassischen Migrationen ist der typische Wert in unseren aktuellen Projekten. Bei besonders gewachsenen Altsystemen fällt die Ersparnis geringer aus, weil das Mapping selbst komplex wird — dort ist der Gewinn nicht so sehr die Zeit als die Konsistenz. Nach einem Aufnahmegespräch sagen wir Ihnen realistisch, wo Ihre Migration landen würde.