In den letzten Wochen habe ich mehrere Contao-Websites auf die aktuelle Langzeitversion 5.7 gebracht: die Website einer Schule mit vielen Formularen und einer kommerziellen Marketing-Erweiterung, eine Vereinsseite mit mehreren hundert Beiträgen und zwei Websites von Selbstständigen. Eine dieser Websites habe ich Anfang 2025 schon von Contao 4 auf Contao 5 gehoben.

Das Fazit vorweg: Der Schritt von Contao 5.3 auf 5.7 war in allen Fällen unspektakulär. Der Sprung von Contao 4 auf Contao 5 dagegen ist ein eigenes Projekt, besonders bei Websites, die schon einige Versionen hinter sich haben.

Wo stehen die Contao-Versionen gerade?

Contao veröffentlicht alle zwei Jahre im Februar eine Langzeitversion (LTS). Sie bekommt drei Jahre lang Fehlerbehebungen und danach ein weiteres Jahr Sicherheitsupdates.

  • Contao 4 ist komplett ohne Support. Die letzte Version 4.13 hat am 14. Februar 2026 ihr letztes Sicherheitsupdate bekommen.
  • Contao 5.3 LTS bekommt noch bis 14. Februar 2027 Fehlerbehebungen und bis 14. Februar 2028 Sicherheitsupdates.
  • Contao 5.7 LTS ist seit Februar 2026 die aktuelle Langzeitversion, mit Fehlerbehebungen bis 2029 und Sicherheitsupdates bis 14. Februar 2030.
  • Contao 6.0 ist im August 2026 erschienen, allerdings als Zwischenversion mit nur einem halben Jahr Support. Die nächste Langzeitversion 6.3 ist für Februar 2028 geplant.

Für die meisten Websites ist Contao 5.7 deshalb das richtige Ziel.

Contao 5.3 auf 5.7: meistens ein problemloser Schritt

So bin ich vorgegangen

Bei allen Websites war der Ablauf ähnlich:

  1. Kopie der Live-Website in eine lokale Entwicklungsumgebung holen, mit Datenbank und Dateien.
  2. Zwischenschritt innerhalb von 5.3: zuerst auf die neueste 5.3-Version. So lassen sich Änderungen sauber den beiden Schritten zuordnen.
  3. Sprung auf 5.7: Versionsangaben anpassen, Pakete aktualisieren, Datenbank migrieren.
  4. Abgleich mit der Live-Website: Ich rufe diverse Seiten lokal und live ab und vergleiche das HTML automatisch. So fällt jede Abweichung auf, auch eine, die man im Browser übersehen würde.
  5. Test im Browser und im Backend nach einer festen Testliste: Formulare mit echtem Mailversand, Galerien, Navigation auf dem Smartphone, Artikel bearbeiten und speichern.
  6. Livegang per Kommandozeile, mit Wartungsmodus und Datenbank-Backup direkt davor.

Bei den drei kleineren Websites war das Update jeweils an einem Tag erledigt, inklusive Tests.

Composer statt Contao Manager

Viele Contao-Websites werden über den Contao Manager aktualisiert, eine Weboberfläche, die direkt auf dem Server läuft. Ich habe ihn bei allen vier Websites abgelöst und arbeite nur noch mit Composer, dem Werkzeug, das auch hinter dem Contao Manager steckt. Die Befehle laufen lokal und per SSH auf dem Server.

  • Weniger Angriffsfläche. Der Contao Manager ist eine Datei, die öffentlich im Web erreichbar ist. Wo er nicht mehr gebraucht wird, entferne ich ihn.
  • Keine Abbrüche mitten im Update. Bei großen Updates stößt der Contao Manager auf manchen Hostings an Zeit- oder Speichergrenzen. Auf der Kommandozeile gelten diese Grenzen in der Regel nicht.

Voraussetzung ist ein SSH-Zugang beim Hoster.

Was sich geändert hat

Im Frontend fast nichts Sichtbares. Der HTML-Abgleich zeigte nur Kleinigkeiten, die meisten davon sind Verbesserungen bei der Barrierefreiheit: Der aktive Menüpunkt wird für Screenreader gekennzeichnet, Sonderzeichen werden korrekt ausgegeben, Inline-Skripte bekommen ein Sicherheitsmerkmal. Inhalte, Bilder und Seitenaufbau waren identisch.

Spürbarer ist die Änderung im Backend: Seit Contao 5.5 stecken viele Aktionen in den Listen (Kopieren, Bearbeiten, Ein- und Ausblenden) in einem „…“-Menü statt als Icon direkt in der Zeile. Für Redakteure, die täglich damit arbeiten, ist das ein ungewohnter Extra-Klick. Ich habe dafür eine kleine Erweiterung geschrieben, die die wichtigsten Aktionen wieder als Icons anzeigt. Das gehört für mich zu einem Update dazu: Nicht nur die Technik muss laufen, auch die Menschen, die mit dem Backend arbeiten, sollen sich zurechtfinden.

Worauf man achten sollte

  • PHP 8.3: Contao 5.7 braucht mindestens PHP 8.3, Contao 5.3 kam noch mit PHP 8.1 aus. Vor dem Update beim Hoster prüfen.
  • Erweiterungen: Contao 5.7 setzt auf eine neuere Version des Symfony-Frameworks. Jede Erweiterung, die noch auf die alte Version festgelegt ist, blockiert das Update. Meist gibt es eine aktuelle Version, manchmal muss man ausweichen.
  • Datenbank-Migration nie blind bestätigen: Contao schlägt nach dem Update Änderungen an der Datenbank vor, auch Löschungen. Bei einer Website wollte Contao eine Tabelle löschen, in der ein Formular-Protokoll lag, weil keine Erweiterung sie mehr „kannte“. Ein Klick auf „Ausführen“ hätte die Daten unwiederbringlich gelöscht. Solche Vorschläge prüfe ich einzeln und sichere die Tabellen im Projekt ab, bevor die Migration läuft.
  • Eigener Code: Kleine Hilfsprogramme aus früheren Projektphasen können mit der neuen Framework-Version Warnungen erzeugen. Hier lohnt es sich, aufzuräumen.

Auch eine LTS braucht Updates

Eine Erkenntnis, die mir wichtig ist: Langzeitversion heißt nicht, dass man nichts tun muss. Eine der Websites lief auf einem Stand von Contao 5.3, für den bereits mehrere Sicherheitslücken bekannt waren, darunter eine Rechteausweitung im Backend und Cross-Site-Scripting in der Suche. Die Korrekturen gab es längst, sie waren nur nie eingespielt worden. Wer eine LTS-Version einsetzt, sollte die regelmäßigen Patch-Updates trotzdem zeitnah installieren.

Sonderfall: kommerzielle Erweiterungen

Aufwendiger war die größte der vier Websites. Sie nutzt die Marketing Suite, eine kommerzielle Erweiterung für Conversion-Elemente, Statistiken und Kurzlinks. Der Hersteller hat die Entwicklung im Juni 2026 eingestellt. Die letzte Version ist nur bis Contao 5.7.5 freigegeben.

Das bedeutete: Ein Update auf die aktuelle 5.7 war offiziell nicht möglich, und ausgerechnet 5.7.5 hatte noch bekannte Sicherheitslücken. Der Kunde wollte die Erweiterung behalten. Ich habe die Website deshalb in zwei Schritten aktualisiert: zuerst auf 5.7.5, um alles andere sauber umzustellen, danach auf die aktuelle Version 5.7.13. Dafür habe ich die Versionsgrenze der Erweiterung im Projekt aufgehoben und drei kleine Korrekturen eingebaut. Eine davon war nötig, weil ein Sicherheitsupdate von Contao eine Rechteprüfung verschärft hat, die die Erweiterung bis dahin nur zufällig bestanden hatte.

Die Website läuft seit Oktober auf dem aktuellen Stand. Die Lehre daraus: Vor jedem Update prüfe ich, ob alle Erweiterungen noch gepflegt werden. Eine eingestellte Erweiterung ist kein sofortiges Problem, aber eine Verpflichtung für jedes künftige Update. Langfristig ist es oft günstiger, sie durch Bordmittel oder eine gepflegte Alternative zu ersetzen.

Contao 4 auf 5: ein anderes Kaliber

Wer noch Contao 4 einsetzt, betreibt seit Februar 2026 eine Website ohne Sicherheitsupdates. Spätestens jetzt ist der Umstieg auf Contao 5 fällig. Der Weg führt dabei über die letzte Version 4.13.

Dieselbe Website habe ich im Januar 2025 von Contao 4.13 auf 5.3 gebracht. Das war deutlich aufwendiger als der jetzige Schritt auf 5.7: Statt eines Tages waren es rund zwei Wochen.

  • Fast jede Erweiterung brauchte eine neue Hauptversion: das Bootstrap-Framework, das Notification Center für die Formular-Mails, das Cookie-Banner, die Marketing Suite, das Backup-Modul.
  • Einige Erweiterungen gab es für Contao 5 nicht mehr. Der iCal-Export für Termine musste durch eine andere Erweiterung ersetzt werden, mehrere kleine Helfer fielen ganz weg.
  • Die Bootstrap-Erweiterung für Contao 5 gab es damals nur als Vorabversion. Mein erster Versuch, die vorhandene Bootstrap-Anpassung selbst auf Contao 5 zu übertragen, wurde abgebrochen. Mit der Vorabversion des Herstellers ging es dann deutlich schneller. Heute ist das kein Hindernis mehr: Alle Pakete von Contao Bootstrap gibt es inzwischen frei und unter einer Open-Source-Lizenz für Contao 5.
  • Templates und Stylesheets mussten nachgezogen werden: eigene Inhaltselemente, Termin-Teaser, Galerie-Darstellung, Backend-Anpassungen.
  • Manche Altlasten fallen erst später auf. Contao 5 liest Konfigurationsdateien an einem anderen Ort als Contao 4. Die alten Dateien lagen noch im Projekt und wurden seit dem Upgrade stillschweigend ignoriert.

Besonders aufwendig: Websites mit langer Vorgeschichte

Am meisten Arbeit machen Websites, die ursprünglich mit Contao 3 entstanden und seitdem mehrfach aktualisiert worden sind. Bei ihnen finden sich typischerweise:

  • Erweiterungen im alten Modulformat, die nie für neuere Versionen umgeschrieben wurden,
  • Templates mit Platzhaltern und Klassen, die es so nicht mehr gibt,
  • Konfigurationsdateien und Datenreste aus mehreren Generationen,
  • Inhalte, die als HTML-Code direkt in der Datenbank stecken und beim Update von Hand geprüft werden müssen.

Bei solchen Websites ist eine ehrliche Bestandsaufnahme vor dem Update wichtig. Manchmal ist ein Neuaufbau auf Contao 5 mit Übernahme der Inhalte wirtschaftlicher als ein Update Schritt für Schritt. Dann lohnt sich auch die Frage, ob Contao noch das passende System ist. Wann welches System passt, habe ich im CMS-Vergleich aus der Praxis zusammengefasst.

Und Contao 6?

Contao 6 ist der nächste große Schritt, vergleichbar mit dem Wechsel von 4 auf 5. Die alten Templates im Format .html5, mit denen viele Themes und Erweiterungen noch arbeiten, funktionieren dort nicht mehr. Außerdem braucht Contao 6 mindestens PHP 8.4.

Contao 5.7 ist damit die letzte Version, die diese Templates unterstützt. Alle vier Websites aus diesem Artikel arbeiten noch mit solchen Templates, ebenso die verwendeten Themes. Mein Rat: Contao 6 erst mit der Langzeitversion 6.3 angehen, frühestens 2028. Bis dahin ist genug Zeit, Templates und Erweiterungen in Ruhe vorzubereiten, statt alles in einem großen Sprung zu erledigen.

Meine Empfehlung je nach Ausgangslage

  • Contao 4: Jetzt handeln. Die Website bekommt keine Sicherheitsupdates mehr, und das Update auf Contao 5 braucht Vorlauf.
  • Contao 5.3: Kein Grund zur Eile, aber das Update im Laufe von 2027 einplanen. Die Fehlerbehebungen enden im Februar 2027, die Sicherheitsupdates ein Jahr später. Nach meiner Erfahrung ist der Schritt auf 5.7 bei gut gepflegten Websites mit überschaubarem Aufwand erledigt.
  • Contao 5.7: Regelmäßig die Patch-Updates einspielen und die Vorbereitung auf Contao 6 im Blick behalten.
  • Kommerzielle oder eingestellte Erweiterungen: Vor jedem Update prüfen, ob sie zur Zielversion passen.

Häufige Fragen zum Contao-Update

Kann man direkt von Contao 4.9 auf Contao 5 aktualisieren?

Nein. Der Weg führt über Contao 4.13, erst von dort geht es auf Contao 5.

Wie lange dauert ein Update von Contao 5.3 auf 5.7?

Bei gut gepflegten Websites ohne exotische Erweiterungen in der Regel einen Tag inklusive Tests. Mit kommerziellen oder nicht mehr gepflegten Erweiterungen entsprechend länger.

Sieht die Website nach dem Update anders aus?

In meinen Projekten nicht. Die Unterschiede lagen im Quelltext und betrafen vor allem die Barrierefreiheit. Im Backend gibt es dagegen wenige sichtbare Änderungen, an die sich Redakteure gewöhnen müssen.

Braucht man für Contao 5.7 einen neuen Hoster?

Nicht unbedingt. Contao 5.7 braucht mindestens PHP 8.3, das bieten die meisten Hoster an. Für Contao 6 ist später PHP 8.4 nötig.

Übernimmt w3box auch Contao-Websites, die eine andere Agentur gebaut hat?

Ja. Die Website mit der Marketing Suite aus diesem Artikel habe ich selbst übernommen und zunächst analysiert, bevor das erste Update lief.

Contao-Update anfragen

Sie betreiben eine Contao-Website auf Version 4 oder 5.3 und möchten wissen, was ein Update bedeutet? Schreiben Sie mir. Ich sehe mir Ihr System an und sage Ihnen ehrlich, ob ein Update reicht oder ob ein Neuaufbau sinnvoller ist.