RedDot / OpenText Recreation Guide
Von der gewachsenen Website zur offenen Contentplattform mit Drupal.
Kurzfassung
Der Wechsel von RedDot beziehungsweise OpenText Web Site Management zu Drupal lässt sich systematisch aufbauen: Inhalte auslesen, Strukturen zuordnen, automatisiert übertragen und gemeinsam prüfen. Die Ähnlichkeit der Inhaltsmodelle erleichtert den Übergang. Drupal bietet anschließend eine offene Grundlage für Redaktion, digitale Dienste und weitere Anwendungen. E-FORK hat diesen Wechsel bereits für die Heinrich-Böll-Stiftung umgesetzt.
Die Plattformgeschichte: von RedDot zu OpenText
RedDot prägte mit SmartEdit die direkte Bearbeitung von Inhalten auf der Seite. Über Hummingbird gelangte das Produkt 2006 zu OpenText. Aus RedDot wurde zunächst OpenText Web Solutions, später OpenText Web Site Management. Die heutigen Installationen tragen häufig viele Jahre redaktioneller Arbeit und individueller Entwicklung in sich. OpenText dokumentiert diese Produktgeschichte.
Damit stellt sich eine strategische Frage: Wie lange passt die bestehende Architektur noch zu den nächsten Anforderungen?
Warum sich der Wechsel lohnt
Eine Migration wird sinnvoll, wenn neue Funktionen aufwendig werden, Schnittstellen fehlen oder Betrieb und Weiterentwicklung von wenigen Spezialist*innen abhängen. Statt immer mehr Sonderlösungen anzubauen, lässt sich der vorhandene Inhalt auf eine offenere Grundlage übertragen.
Drupal verbindet Contentmanagement mit einem Entwicklungsframework: strukturierte Inhalte, Mehrsprachigkeit, redaktionelle Abläufe und individuell erweiterbare Anwendungen. Der offene Quellcode und die Drupal-Community schaffen Wahlmöglichkeiten bei Dienstleistern und Weiterentwicklung. Der wirtschaftliche Vorteil entsteht durch Wiederverwendung und weniger vermeidbare Abhängigkeiten.
RQL: der Zugang zum vorhandenen Inhalt
Die RedDot Query Language, kurz RQL, bietet einen programmatischen Zugang zum Management Server. Darüber können – abhängig von Version, Berechtigungen und verfügbaren Befehlen – Seiteninformationen, Elemente und Beziehungen für die Migration ausgelesen werden.
Ein Exportprozess überführt diese Daten in ein prüfbares Zwischenformat. Anschließend legt das Content-Mapping fest, wie daraus Drupal-Inhalte entstehen. RQL erschließt die Quelle; das Mapping übersetzt ihre Struktur. Dateien und Medien werden ergänzend übernommen. Alternativ kommen vorhandene Exporte oder ein abgestimmter Datenbankzugriff infrage.
Content-Mapping: von RedDot nach Drupal
Content Class → Inhaltstyp, etwa Artikel oder Publikation
Page → Inhalt, beispielsweise ein Artikel
Element → Feld für Titel, Text, Datum oder weitere Angaben
Seitenbeziehung → Referenz auf einen anderen Inhalt
Sprachvariante → Übersetzung des zugehörigen Inhalts
Bild oder Dokument → Medienobjekt mit Datei und Metadaten
Bisherige URL → beibehaltene Adresse oder Weiterleitung
Das Mapping wird für den konkreten Bestand definiert. Nicht jede alte Struktur muss unverändert weiterleben: Gemeinsam genutzte Informationen können beispielsweise zu eigenständigen, wiederverwendbaren Inhalten werden.
Die Migration Pipeline
Bestand → RQL / Export → Mapping → Drupal-Import → Prüfung → Go-live
Bestand klären: Inhalte, Content Classes, Medien, Sprachen und Sonderfunktionen erfassen. Festlegen, was übernommen, überarbeitet oder archiviert wird.
Zielmodell entwickeln: Inhaltstypen, Felder, Beziehungen und redaktionelle Abläufe in Drupal definieren.
Übertragung automatisieren: Quelldaten auslesen, bereinigen und über Drupals Migrate API importieren. Alte und neue Kennungen einander zuordnen, damit Beziehungen erhalten bleiben.
Testmigrationen durchführen: Vollständigkeit, Medien, Übersetzungen, interne Links und Weiterleitungen prüfen. Redaktionsteams testen die Arbeitsabläufe.
Umstieg durchführen: Letzte Änderungen übernehmen, den Veröffentlichungswechsel koordinieren und die neue Plattform im Betrieb begleiten.
Drupals Migrate API liefert dafür die Grundlage aus Datenquelle, Verarbeitung und Ziel. Die projektspezifischen Regeln machen die Übertragung nachvollziehbar und wiederholbar.
Erfahrung aus der Praxis
Für eine große Stiftung haben wir den Wechsel von RedDot zu Drupal umgesetzt. Diese Erfahrung bringen wir in weitere Migrationen ein: Bestehende Inhalte verstehen, die Zielarchitektur bewusst gestalten und Technik und Redaktion gemeinsam durch den Übergang führen.
Ihr plant den Wechsel von RedDot oder OpenText WSM?
Lasst uns euren Bestand und den passenden Migrationsweg gemeinsam ansehen.
Weiterführende Quellen: OpenText: Übernahme von Hummingbird (2006) · Drupal: Inhaltsübersetzungen · Drupal: Layout Builder
FAQ: Migration von RedDot und OpenText WSM zu Drupal
-
Nein. Wiederkehrende Strukturen lassen sich automatisiert migrieren. Redaktionelle Entscheidungen bleiben dort nötig, wo Inhalte veraltet, doppelt oder uneinheitlich sind.
-
RQL dient dem Zugriff auf das Quellsystem. Die Zuordnung zu Drupal-Inhaltstypen und Feldern wird separat definiert und im Migrationsprozess umgesetzt.
-
Bestehende URLs können, soweit sinnvoll, übernommen werden. Für geänderte Adressen werden Weiterleitungen eingerichtet und getestet. Rankings lassen sich dadurch nicht garantieren.
-
Drupal bietet Inhaltsübersetzungen und visuelle Layoutwerkzeuge. Wie sie zusammenspielen, wird passend zu den bisherigen Abläufen und künftigen Anforderungen eingerichtet.
-
Ein pauschales Supportende behaupten wir nicht. Maßgeblich sind die eingesetzte Version und die vertraglichen Supportbedingungen. Ein Wechsel kann sich bereits lohnen, wenn die Weiterentwicklung zu aufwendig wird.
-
Das hängt vor allem von Strukturvielfalt, Datenqualität, Sprachen, Schnittstellen und Sonderfunktionen ab. Eine Bestandsaufnahme und eine erste Testmigration schaffen die Grundlage für einen belastbaren Plan.