Entscheidungen, die in fünf Jahren noch tragen.

Die Wahl eines Content-Management-Systems entscheidet weniger darüber, wie eine Website aussieht, als darüber, wie eine Redaktion in den nächsten Jahren arbeitet. Systeme, die in der Demo überzeugen, scheitern im Alltag oft an den unspektakulären Dingen: an Freigabeprozessen, an der Anbindung von Fachsystemen, an mehrsprachigen Auftritten oder daran, dass jede neue Seitenart wieder Entwicklungsaufwand kostet.

Wir begleiten die Auswahl von der Anforderungsaufnahme bis zur begründeten Entscheidung. Dazu erfassen wir mit allen Beteiligten — Redaktion, IT, Fachabteilungen — was das Zielsystem können muss, übersetzen das in technisch prüfbare Kriterien und vergleichen die in Frage kommenden Systeme daran. Am Ende steht eine Entscheidung, die man auch in zwei Jahren noch begründen kann, und nicht nur der Name des Anbieters mit der besten Präsentation.

Ebenso häufig ist die Frage nach der Betriebsart: klassisch, headless oder hybrid. Wir haben Zielarchitekturen entworfen, die beides bedienen — die gewohnte Seitenpflege für die Redaktion und zugleich Inhalte als Daten für App, Newsletter oder weitere Kanäle. Welche Variante trägt, hängt weniger von der Technik ab als davon, wer die Inhalte pflegt und wie viele Kanäle wirklich bedient werden.

Für bestehende Systeme übernehmen wir die Bewertung der Systemlandschaft: Wo lohnt sich Ausbau, wo ist eine Ablösung der ehrlichere Weg, und was kostet der Umstieg tatsächlich — inklusive der Migration des Bestands.

Der Weg in die Cloud wird selten an der Technik entschieden, sondern an der Rechnung. Skalierbarkeit, Verfügbarkeit und schnellere Bereitstellung sind real — genauso real sind Betriebskosten, die nach der Migration höher liegen als vorher, weil eine Anwendung einfach eins zu eins umgezogen wurde, ohne sie auf das neue Kostenmodell hin anzupassen.

Wir prüfen deshalb zuerst, welcher Teil Ihrer Landschaft in der Cloud tatsächlich gewinnt. Für manche Systeme ist es der richtige Schritt, für andere bleibt der eigene Betrieb die günstigere und ruhigere Lösung. Zu dieser Einschätzung gehört auch das Servicemodell: Wo genügt gemietete Infrastruktur, wo lohnt eine Plattform mit Datenbanken und Middleware als Dienst, und wo ist fertige Standardsoftware das Vernünftigste.

Führt der Weg in die Cloud, planen wir ihn schrittweise statt als Stichtagsumzug: Containerisierung der Anwendungen, Orchestrierung, automatisierte Bereitstellung, nachvollziehbar beschriebene Infrastruktur. Wir haben Plattformen dieser Art aufgebaut und betrieben — von containerisierten eCommerce-Systemen bis zu Diensten, die zu terminierten Veröffentlichungen mit erheblichen Lastspitzen umgehen müssen.

Ein Punkt, der in Cloud-Projekten regelmäßig zu spät kommt, steht bei uns früh auf der Liste: Wie kommen Sie wieder heraus. Wir achten darauf, dass die Abhängigkeit zu einem Anbieter bewusst gewählt und nicht nebenbei entstanden ist.

Eine Datenmigration ist der Teil einer Systemablösung, der am wenigsten glänzt und am meisten schiefgehen kann. Das neue System ist ausgewählt, die Oberfläche steht — und dann stellt sich heraus, dass zwanzig Jahre gewachsener Bestand nicht in das neue Datenmodell passt, dass Verknüpfungen fehlen oder dass niemand sagen kann, ob wirklich alles angekommen ist.

Wir gehen solche Vorhaben in klaren Schritten an. Am Anfang steht die Analyse des Quellbestands: Was ist tatsächlich vorhanden, was ist redundant, was ist über die Jahre inkonsistent geworden. Daraus entsteht die Abbildung auf das Zielmodell — der Teil, in dem die eigentliche Arbeit steckt, weil Struktur, Format und Beziehungen selten eins zu eins passen. Erst dann folgt der Transport, in der Regel wiederholbar und in mehreren Durchläufen, damit sich Fehler zwischen den Läufen korrigieren lassen statt am Stichtag.

Entscheidend ist für uns die Nachweisbarkeit: Eine Migration ist erst fertig, wenn sich in Zahlen sagen lässt, was übertragen wurde und was nicht — und wenn die Abweichungen erklärt sind. In einem Verlagsprojekt haben wir auf diesem Weg rund eine Million Beiträge und etwa 3,4 Millionen Bilder aus zwanzig Jahren Bestand überführt, bei einer Konvertierungsrate von 99,82 Prozent. Die verbleibenden Fälle waren benannt, nicht unbekannt.

Genauso wichtig ist der Übergang selbst: Welche Systeme laufen wie lange parallel, wann wird umgeschaltet, und wie sieht der Weg zurück aus, falls etwas nicht trägt. Diese Fragen klären wir vor dem ersten Datensatz, nicht danach.

Die schwierigste Frage bei KI ist nicht, welches Modell man nimmt, sondern welcher Prozess überhaupt davon profitiert. Vieles, was als KI-Projekt startet, ist in Wahrheit ein Datenproblem, eine fehlende Schnittstelle oder ein Ablauf, der sich mit klassischer Automatisierung günstiger und zuverlässiger lösen ließe. Diese Unterscheidung treffen wir am Anfang — bevor Budget gebunden ist.

Trägt ein Anwendungsfall, klären wir die Fragen, die im Betrieb über Erfolg oder Ärger entscheiden. Welche Daten dürfen das Haus verlassen, und was bedeutet das für die Wahl zwischen Cloud-Modell und eigenem Betrieb? Wie prüfen Sie, ob die Ergebnisse gut genug sind, statt sich auf ein Bauchgefühl zu verlassen? Was kostet der Betrieb pro Monat, wenn die Nutzung sich verzehnfacht — und wie deckeln Sie das? Und wie bleibt der Mensch dort in der Verantwortung, wo eine Entscheidung Konsequenzen hat?

Architektonisch raten wir konsequent dazu, die KI zu kapseln statt sie zu verweben. Modelle veralten schneller als Ihre Anwendung; wer sie hinter einer eigenen Schnittstelle hält, kann sie tauschen, ohne das Produkt anzufassen. Das gilt für den Anbieterwechsel ebenso wie für den Schritt von einem gemieteten Modell zu einem selbst betriebenen.

Am Ende steht eine ehrliche Einschätzung: welche Anwendungsfälle sich lohnen, was sie realistisch kosten, in welcher Reihenfolge man sie angeht — und welche man besser sein lässt. Wenn Sie den Schritt in die Umsetzung gehen wollen, finden Sie unter KI-Pakete unsere Festpreis-Angebote dafür; eine Beratung verpflichtet Sie dazu nicht.