Eine Technische Redaktion hat vor Jahren ein Redaktionssystem eingeführt, war lange zufrieden – und irgendwann kippt die Stimmung. Erst schleichend, dann ziemlich unübersehbar. Diese Situation kennen wir aus unserem Dienstleisteralltag nur zu gut.
Ein großer Maschinenhersteller, den wir begleitet haben, konnte etwa Inhalte mit zusätzlichen Metadaten erst dann versehen, als dieses Feature vom CMS-Hersteller programmiert, getestet und ausgeliefert wurde – jedes Mal ein Projekt für sich. Gleichzeitig wuchs die Datenbank immer weiter an, weil fast identische Maschinenvarianten nicht wiederverwendet werden konnten, sondern ständig kopiert wurden. Das System wurde langsamer, die Redaktion unzufriedener. Die Dubletten haben wir im Zuge der Migration nach SCHEMA ST4 automatisiert entfernt. Am Ende hat der Kunde für die Erstellung eines Dokuments statt sechs Minuten nur noch eine gebraucht. Bei 1200 Dokumenten pro Jahr eine Ersparnis, die sich sofort in der Redaktion bemerkbar gemacht hat.
Solche Geschichten sind kein Einzelfall und die Moral von der Geschichte ist: Ein Redaktionssystem hält selten ewig. Die Gründe dafür lassen sich in der Regel einem der drei folgenden Szenarien zuordnen.
Szenario 1: Das CMS verschwindet
Manchmal kommt der Handlungsdruck von außen. Ihr CMS-Hersteller kündigt das Produkt ab, gerät wirtschaftlich ins Straucheln oder wird aufgekauft. Und plötzlich stellt sich die Frage: Beim Nachfolgesystem bleiben oder etwas Neues versuchen?
Typische Warnsignale sind schlechter werdender Support, Updates, die nicht mehr zuverlässig kommen, und ein Ökosystem, das langsam austrocknet: weniger Ansprechpartner, weniger Spezialist:innen, die das System noch wirklich kennen. Oft macht sich das zuerst an der Weiterentwicklung bemerkbar: Features, die anderswo längst Standard sind – KI-Integration, moderne Schnittstellen, Automatisierung –, lassen bei einem stagnierenden Hersteller einfach auf sich warten.
Wer sich in dieser Lage befindet, geht mit jedem weiteren Betriebsjahr ein wachsendes Risiko ein. Der Appell ist einfach: Nicht warten, bis der Zug abgefahren ist.
Szenario 2: Das CMS ist technisch K.O.
Der zweite Fall ist oft selbst verschuldet, wenn auch aus nachvollziehbaren Gründen. Ein Kunde von uns hatte sein Redaktionssystem vom Hersteller individuell anpassen lassen, weil bestimmte Funktionen für die extrem hohen Anforderungen an die Druckausgabe bei Einführung im Standardsystem schlicht nicht vorgesehen waren. Also hat er sie sich bauen lassen.
Eine Zeit lang war das eine gute Lösung. Das Tückische daran: Für viele dieser Funktionen hat der Hersteller Jahre später Lösungen nachgerüstet, die die Anforderungen sehr viel generischer und anwendungsfreundlicher umgesetzt haben – inklusive Update-Pfad und Support. Die individuelle Lösung des Kunden konnte davon nicht profitieren, weil sie zu tief ins Datenmodell eingriff. Irgendwann ließ sich das System kaum noch aktualisieren, weil das Customizing jeden Update-Zug blockierte. Die Folge: steigende Hostingkosten, sinkende Performance, ein Team, das zunehmend mit Workarounds arbeiten musste.
Wenn Ihre Standardabläufe also nur noch mit Klimmzügen funktionieren, Sicherheitsupdates nicht mehr einspielbar sind oder das Systemwissen im Haus verloren geht, ist der Punkt erreicht, an dem ein Weiterbetrieb selbst zum Risiko wird.
Szenario 3: Das CMS läuft – aber nicht die Redaktion
Der dritte Fall ist der subtilste, weil weder der Hersteller noch die Technik das Problem ist.
Das System läuft, aber es tut nicht mehr das, was gebraucht wird. Wiederverwendung und Filterung funktionieren nicht, weil die eigenen Klassifikationsmerkmale über die Jahre inkonsistent geworden sind. Oder ein neuer Kanal kommt dazu, wie etwa der Digitale Produktpass, und die bestehende Modularisierung passt nicht mehr zu den neuen Anforderungen.
Wer bisher kapitelorientiert dokumentiert hat, aber künftig topic-orientierte Inhalte für einen KI-Chatbot oder eine Service-App braucht, stößt mit der alten Struktur an eine Grenze.
In solchen Fällen hilft oft nicht der Kauf eines neuen Systems, sondern eine gründliche Bereinigung des bestehenden. Im Ergebnis ist das nicht selten trotzdem ein Migrationsprojekt, weil die Daten technisch umgeformt werden müssen. Vielleicht brauchen Sie also gar kein neues CMS, sondern ein neues CM?
Aber egal, ob Sie wirklich ein System wechseln oder Ihre Daten für einen Weiterbetrieb migrieren müssen: Es gibt Klärungsbedarf!
Was Sie vor der Migration klären müssen
Steht ein Wechsel an, lohnt sich vor allem eines: nicht einfach das Alte nachbauen. Ein Systemwechsel sollte immer einen Zusatznutzen schaffen. Deshalb sollten Sie diese Fragen für sich beantworten können:
- Welche Nutzung und welche Ausgabeformate wollen wir künftig ermöglichen?
- Welche Anforderungen muss das Zielsystem tatsächlich erfüllen?
- Was soll mit dem Bestand geschehen – alles migrieren oder gezielt einen Cut machen?
- Was muss sich an Content und Prozessen ändern?
Was dabei garantiert nicht automatisch mitverschwindet: alte Sonderfälle, uneinheitliche Inhalte, ungeklärte Prozesse und fehlende Kapazitäten. Eine reine Datenübertragung schneidet diese Baustellen nicht ab, sondern nimmt sie einfach mit ins neue System.
Manche Unternehmen entscheiden sich deshalb bewusst gegen eine automatisierte Migration und bauen ihren Content stattdessen neu auf, wenn der Bestand noch überschaubar ist. Das kostet Zeit, eröffnet aber die Chance, Content-Modell, Klassifizierung und Bausteingrößen komplett neu zu denken – etwas, wofür im laufenden Betrieb sonst nie ein Anlass entsteht.
Stellen Sie sich statt der Frage „Was kostet ein Wechsel des CMS?“ lieber diese: „Was kostet es uns, wenn wir im alten CMS bleiben?“ Denn ein Weiterbetrieb auf einem auslaufenden System kostet ebenfalls, nur eben in Zeit, Qualität und Sicherheit, die heute vielleicht noch nicht zu spüren ist. Im nächsten Jahr aber umso deutlicher.
Entscheider:innen von einer Migration überzeugen
Wer eine Migration intern durchsetzen will, kommt an einem Punkt nicht vorbei: Irgendwann müssen Geldgeber und Unterstützer überzeugt werden. Mit sehr CMS-technischen Argumenten wie „Wir müssen unbedingt die Fragmenttypen ändern.“ werden Sie dort selten Gehör finden.
Was Management-Ebenen dagegen verstehen, sind Zahlen und Risiken. Bei einem Kunden mit einem stark individuell angepassten System etwa kostete allein die jährliche Wartung eine erhebliche Summe. Dazu kam, dass technische Daten für Übersetzungen bislang von Hand in 20 Mitarbeitertagen aufbereitet werden mussten, weil die Automatisierung im System schlicht nicht funktionierte. Sobald sich solche Kosten benennen lassen, wird aus einer redaktionellen Wunschliste ein wirtschaftliches Argument.
Ein paar Leitfragen helfen dabei, diese Übersetzungsarbeit zu strukturieren:
- Was zwingt uns – und bis wann? Gibt es ein konkretes Datum (Abkündigung, Vertragsende, Auslaufen von Support), das den Druck objektiv macht?
- Was hängt wirklich an unserem CMS? Meist mehr, als man auf den ersten Blick denkt: Compliance-Nachweise, Übersetzungsmanagement, Freigabeprozesse, im Zweifel auch die Haftungssicherheit bei Warnhinweisen.
- Was kostet uns der Status quo – nicht nur in Lizenzgebühren, sondern in Arbeitsstunden, Fehlerkorrekturen und verpassten Automatisierungspotenzialen?
- Welche Optionen haben wir noch, und welche verlieren wir gerade, wenn wir jetzt nicht handeln?
- Wer schafft jetzt eine belastbare Entscheidungsgrundlage – und bis wann muss diese stehen, damit ein Wechsel überhaupt noch geordnet ablaufen kann?
Wer diese Fragen mit konkreten Zahlen und Beispielen aus dem eigenen Redaktionsalltag beantworten kann, hat eine Argumentation, die auch außerhalb der Technischen Redaktion trägt.
Erst Klarheit, dann entscheiden, dann handeln
Ob der Anstoß von außen kommt, aus der Technik oder aus der eigenen Unzufriedenheit mit dem System – ein Umstieg ist selten ein Spaziergang, aber auch kein unbekanntes Terrain und schon gar kein Hexenwerk.
Der Markt der Redaktionssysteme hat sich in den letzten Jahren deutlich stabilisiert. Es gibt heute Hersteller mit klarem Profil und echten Alternativen für jeden Einsatzzweck.
Um auf das Eingangsbeispiel zurückzukommen: Unser Kunde hat übrigens nicht nur Zeit gespart, sondern auch wieder Lust am eigenen System gefunden. Nach über 25 Jahren an der Seite von Redaktionsteams ist das auch unsere Erfahrung: Wer frühzeitig plant, statt erst unter Druck zu handeln, macht aus der Migration keine Notoperation, sondern eine echte Weichenstellung für die eigene Content-Strategie. Und die erweist sich hinterher meistens als goldrichtig.
FAQ
Wann ist der richtige Zeitpunkt für eine CMS-Migration?
Wenn der Hersteller den Support oder die Weiterentwicklung einschränkt, technische Anpassungen Updates verhindern oder das System die Anforderungen der Redaktion nicht mehr erfüllt. Frühzeitige Planung reduziert das Risiko, unter Zeitdruck handeln zu müssen.
Muss bei Problemen immer ein neues CMS eingeführt werden?
Nein. Wenn das System technisch noch tragfähig ist, können eine Bereinigung der Inhalte und eine Anpassung der Datenstruktur ausreichen. Entscheidend ist, ob das bestehende CMS die künftigen Anforderungen weiterhin erfüllen kann.
Was sollte vor einer CMS-Migration geklärt werden?
Wichtig sind die künftigen Nutzungsszenarien und Ausgabeformate, die Anforderungen an das Zielsystem sowie der Umgang mit dem bestehenden Content. Auch Inhalte, Prozesse und Sonderfälle sollten geprüft werden, statt sie ungefiltert ins neue System zu übernehmen.
Wie lässt sich eine CMS-Migration intern überzeugend begründen?
Eine belastbare Begründung zeigt neben den Wechselkosten auch die Kosten und Risiken des Weiterbetriebs, etwa für Wartung, manuelle Arbeit, Fehlerkorrekturen und Sicherheit. Konkrete Zahlen aus dem Redaktionsalltag helfen, den Handlungsbedarf nachvollziehbar zu machen.




