Sitefinity-Upgrade: Im November laufen vier Versionen gleichzeitig aus

Im November 2026 wird der Support für die Sitefinity-Versionen 15.0, 15.1, 15.2 und 15.3 eingestellt. Nachzulesen ist das im Sitefinity Life Cycle Policy Guide von Progress (Stand 29. Oktober 2026).
In diesem Beitrag geht es darum, welche Fristen gelten, was Active, Sunset und Retired voneinander unterscheidet, was sich mit Version 15.4 LTS am Auslieferungsmodell ändert und wovon der Aufwand eines Versionsupgrades abhängt.

Für eine öffentlich erreichbare Website ist der Unterschied zwischen Sunset und Retired deshalb alles andere als akademisch. In der Sunset-Phase sind zumindest die gravierendsten Lücken noch abgedeckt, danach gibt es keine Zusage mehr.

Ein Satz aus der Policy geht gern unter, hat aber direkte Folgen: „Releases and versions not included in the table below should be considered retired.“ Wer auf einer Version arbeitet, die in der Herstellerübersicht gar nicht mehr auftaucht, muss die Frage nach dem Support also gar nicht erst stellen.

Daraus ergeben sich zwei Gruppen mit unterschiedlicher Dringlichkeit. Wer auf 15.0 bis 15.3 läuft, hat ein klares Zeitfenster bis November 2026, und der Weg auf 15.4 LTS ist technisch der kürzeste, weil er innerhalb derselben Hauptversion bleibt. Auf 13.x oder 14.0 bis 14.3 gibt es dagegen schon heute keine zugesicherten Sicherheitsupdates mehr. Hier geht es nicht mehr ums Planen, sondern ums Aufholen.

Der häufigste Einwand gegen ein Upgrade lautet, dass die Seite ja funktioniert. Das stimmt, hilft aber wenig, denn ein Risiko fällt im laufenden Betrieb nicht auf, sondern erst im Ernstfall.

Dabei werden drei Punkte regelmäßig übersehen. Der erste: Sitefinity hängt an Fremdkomponenten, allen voran am .NET-Unterbau. Progress weist selbst darauf hin, dass der Support einer Fremdbibliothek früher enden kann als der Support der Sitefinity-Version, und empfiehlt in diesem Fall das Upgrade. Der eigene Lifecycle ist also nicht die einzige Uhr, die tickt.

Der zweite: Mit dem Retirement fallen weitere Optionen weg. Retired Versionen werden in Sitefinity Cloud nicht unterstützt, und Progress rät dazu, vor einem Cloud-Deployment erst auf eine unterstützte Version zu aktualisieren. Wer später in Richtung Cloud denkt, kommt am Upgrade also ohnehin nicht vorbei, dann nur mit mehr Zeitdruck.

Der dritte: Der Abstand wächst. Ein Sprung über zwei Hauptversionen ist nicht einfach doppelt so aufwendig wie einer über eine, weil sich Anpassungen, Fremdmodule und Abhängigkeiten in der Zwischenzeit weiter auseinanderentwickelt haben. Je länger ein Upgrade liegen bleibt, desto größer wird das Projekt.

Technisch ist ein Versionsupgrade oft weniger aufwendig als gedacht. Knifflig wird es dort, wo Anpassungen aus früheren Jahren an Modelle gebunden sind, die heute nicht mehr als Basis empfohlen werden.

Für neue Projekte empfiehlt Progress den ASP.NET-Core-Ansatz, optional mit einem Frontend auf Next.js. Bestehende MVC-basierte Umsetzungen laufen weiter: MVC wird laut Progress in allen unterstützten Versionen unterstützt, eine Modernisierung empfiehlt Progress aber auch hier. Bei WebForms-Frontends, die in älteren Installationen noch vorkommen, gibt es dagegen keine Wahl mehr. Progress hat den WebForms-Support im Frontend mit Version 14.1 eingestellt, 13.3 LTS war die letzte offiziell unterstützte Version dafür. Wer WebForms-Seiten, -Templates oder -Widgets einsetzt, muss sie beim Upgrade auf ASP.NET Core oder Next.js umstellen. Nur bei sehr wenigen WebForms-Elementen in einem ansonsten MVC-basierten Projekt ist auch eine Migration nach MVC möglich.

Deshalb lohnt es sich, ein Upgrade als zwei Entscheidungen zu behandeln. Die erste betrifft die Version und wird durch die Fristen vorgegeben. Die zweite betrifft das Frontend-Modell und ist, sofern kein WebForms im Spiel ist, eine echte Wahl: mitnehmen, was läuft, oder den Anlass nutzen und Templates und Widgets auf den empfohlenen Weg heben. Beides ist vertretbar, es sollte nur eine bewusste Entscheidung sein und kein Nebenprodukt, das im Projektverlauf einfach passiert.

Für den Weg selbst stellt Progress Werkzeuge bereit, darunter den Migration Analyzer und CLI-Unterstützung, dazu kommen dokumentierte Upgrade-Anleitungen je Ausgangsversion. Bei uns hat sich in Projekten dieser Ablauf bewährt:

Eine belastbare Zahl lässt sich ohne Blick in die Installation nicht nennen, und pauschale Angaben führen bei Upgrades besonders schnell in die Irre. Vier Treiber bestimmen den Aufwand fast vollständig.

Am meisten fällt der Umfang eigener Anpassungen ins Gewicht: Wie viele eigene Widgets, Templates und Erweiterungen gibt es, und wie stark greifen sie in den Kern ein? Eine Installation nah am Standard ist ein ganz anderes Projekt als eine, die über Jahre tief angepasst wurde.

Dazu kommt die Versionsdistanz: Ein Sprung von 15.3 auf 15.4 verhält sich anders als einer von 13.3 auf 15.4.

Dritter Treiber sind Fremdmodule und Integrationen, weil sie nicht im eigenen Zeitplan liegen. Ein Modul ohne kompatible Version wird schnell zum Engpass.

Und schließlich die Testabdeckung. Wo dokumentiert ist, was funktionieren muss, geht die Abnahme zügig. Fehlt diese Grundlage, entsteht sie im Projekt, was gut investierte Zeit ist, aber eingeplant werden will.

Für einen Teil der Sitefinity-Installationen steht der Termin fest: November 2026 für 15.0 bis 15.3 und April 2027 für 14.4 LTS. Bei 13.x und 14.0 bis 14.3 ist er längst verstrichen.

Wer jetzt auf 15.4 LTS geht, erledigt damit absehbar den letzten großen Versionssprung für längere Zeit, weil Progress danach auf kumulative Product Updates umstellt. Zwei Dinge zahlen sich dabei aus: die Frage nach dem Frontend-Modell bewusst zu entscheiden und das Testkonzept vor dem Eingriff zu schreiben statt danach.

Wir sind zertifizierter Partner von Progress Sitefinity und tragen die Badges Technical Accredited Sitefinity und Digital Agency Partner. Bei Upgrades zählt allerdings noch etwas anderes: Wir kommen aus der .NET-Entwicklung und bringen mehr als 25 Jahre Erfahrung mit Software und ihren Schnittstellen mit. Die Stolpersteine eines Upgrades liegen selten im CMS-Kern, meistens stecken sie in eigenen Anpassungen und angebundenen Systemen.

Unklar, auf welcher Version der eigene Auftritt läuft und wie dringend es ist?
Das ist ein guter Startpunkt. Nimm Kontakt zu uns auf, wir schauen uns Version, Anpassungen und Integrationen an und sagen Dir, was bis wann nötig ist.