Update-Politik und Versionen: Wie lange ein System unterstützt wird

Worum es bei der Auswahl geht

Die Update-Politik legt fest, welche Fassung eines Shopsystems wann keine Korrekturen mehr erhält. Dieser Beitrag nennt Kriterien, Prüfungen und eine Tabelle zum Ausfüllen; Anbieter und Ranglisten kommen darin nicht vor.

Drei Angaben sind auseinanderzuhalten: Die Versionsnummer beschreibt den Inhalt einer Fassung, der Release-Kanal den Takt der Veröffentlichung, die Support-Zusage die Dauer der Pflege. Für die Entscheidung zählt die dritte Angabe, und sie steht in einem Dokument mit Datum. Die übrigen Auswahlkriterien sammelt Shopsystem auswählen.

Versionsnummern lesen: Was die Ziffern sagen und was nicht

Die Spezifikation Semantic Versioning 2.0.0 beschreibt das Format MAJOR.MINOR.PATCH. Die Major-Ziffer steigt bei Änderungen, die mit der bisherigen öffentlichen Schnittstelle (API) nicht verträglich sind, die Minor-Ziffer bei verträglichen neuen Funktionen, die Patch-Ziffer bei verträglichen Fehlerkorrekturen. Fassungen mit der Major-Ziffer 0 gelten dabei als Entwicklung, deren Schnittstelle nicht stabil ist.

Diese Regeln greifen nur, wenn ein Projekt sie anwendet und eine öffentliche Schnittstelle definiert; über die Dauer sagen sie nichts. Aus der Nummer 7.4.2 lässt sich nicht ablesen, bis wann die Fassung 7.4 Sicherheitskorrekturen erhält.

Zwei Support-Policies aus anderen Softwarebereichen, nicht aus Shopsystemen, zeigen, wie unterschiedlich solche Zusagen aussehen. Ein Projekt einer Programmiersprache unterstützt jede Fassung zwei Jahre voll ab der ersten stabilen Veröffentlichung und danach zwei weitere Jahre ausschließlich für kritische Sicherheitsfehler; für die Fassung 8.2, erstmals veröffentlicht am 8. Dezember 2022, endet diese Sicherheitsunterstützung am 31. Dezember 2026. Ein Projekt einer Kryptografie-Bibliothek nutzt dasselbe Zahlenformat, nennt sich aber nicht semantische Versionierung im strengen Sinn: Ab der Fassung 3.5 erscheint alle zwei Jahre eine Fassung mit langfristiger Unterstützung (LTS) über mindestens fünf Jahre, Fassungen ohne diesen Status werden dreizehn Monate voll unterstützt, und für die Fassung 3.5 nennt die Policy den 8. April 2030.

Beide Angaben belegen, wie eine Policy aussieht, und sind keine Empfehlung. Ob ein System nur kritische Sicherheitsfehler oder auch andere Fehler behebt, ist die Angabe, die Sie für Ihre Fassung brauchen; Kriterien zu Erweiterungen sammelt Erweiterungen und Ökosystem bewerten.

Diese Kriterien zählen

Verglichen wird nicht die Funktionsliste, sondern die Zusage für die Fassung, die Sie einsetzen; die Kriterien sind zugleich Prüfung und Frage an den Anbieter.

Kriterium	Warum es zählt	So prüfen Sie es	Frage an den Anbieter
Laufende Fassung	Ohne sie gibt es nichts zu prüfen	Version von System, Erweiterungen und Laufzeitumgebung auslesen	Wo sehe ich die laufende Fassung und die jeder Erweiterung?
Ende der Fehlerbehebung	Danach kommen keine Fehlerkorrekturen mehr	Datum in der Support-Policy suchen, Stand der Angabe notieren	Bis wann werden Fehler in der Fassung behoben, die ich heute einsetze?
Ende der Sicherheitskorrekturen	Dieses Datum bestimmt den Umstiegszeitpunkt	zweites Datum je Fassung suchen	Welches Datum gilt, und was ist danach möglich?
Sicherheitsprozess	Ohne Verfahren erfahren Sie von Lücken nur zufällig	nach Hinweisen, Meldestelle und koordinierter Offenlegung fragen	Wo erscheinen Sicherheitshinweise, und wer darf Lücken melden?
Frist bis zur Korrektur	Zwischen Bekanntwerden und Behebung liegt Ihr Risiko	zugesagte Frist schriftlich verlangen	Innerhalb welcher Frist wird eine bekannte Lücke geschlossen?
Upgrade-Pfad	Ob ein direkter Sprung möglich ist, sagt die Migrationsanleitung, nicht die Versionsnummer	Zwischenschritte und Migrationswerkzeuge erfragen	Welche Zwischenfassungen brauche ich, und was migriert das System selbst?
Wer Updates einspielt	Zwischen Anbieter, Hoster und Betreiber geht Verantwortung verloren	Vertrag prüfen, wer auslöst, und ein Änderungsprotokoll abrufen	Wer spielt ein Update ein, wann wird es aktiv, und wie dokumentiere ich den Patchstand?
Abhängigkeiten	Ihr Supportende kann früher liegen als das des Shops	Laufzeitumgebung, Datenbank und TLS-Bibliothek auflisten	Welche Fassungen setzt die aktuelle Version voraus, und wie lange werden sie unterstützt?

Die Lebenszyklus-Tabelle als Vorlage

Tragen Sie für jedes System und jede Fassung eine Zeile ein. Pflicht sind die beiden Enddaten, die Quelle und das Lesedatum; ohne sie ist die Zeile eine Annahme, keine Prüfung. Laufzeitumgebung, Datenbank und TLS-Bibliothek bekommen eigene Zeilen, weil ihr Supportende früher liegen kann.

System und Fassung	Release-Kanal	Fehlerbehebung bis	Sicherheitskorrekturen bis	Quelle und Lesedatum	Upgrade-Pfad	Offene Punkte
Beispiel (erfundene Angaben): Shopsystem, Fassung 7.4	LTS alle zwei Jahre	31.12.2028	31.12.2029	Support-Policy des Anbieters, gelesen am 14.10.2026	7.4 auf 8.0 mit Datenmigration	drei Erweiterungen ohne Freigabe

Maßgeblich ist das früheste Datum der Zeile: Liegt es vor dem nächsten größeren Umbau, schieben Sie diesen Umstieg vor. Steht in den offenen Punkten „nicht zugesagt“, behandeln Sie die Fassung so, als hätte sie kein Enddatum.

Was ein Supportende kostet

Mit dem Supportende endet die reguläre Zusage Ihrer Fassung; danach umfasst sie keine weitere Pflege mehr. Ob ein Anbieter darüber hinaus Korrekturen liefert, steht in seiner Policy und im Vertrag; die Release-Strategie einer Kryptografie-Bibliothek weist für mehrere Altfassungen einen erweiterten Support aus. Der Ausweg ist ein Umstieg, und der ist ein Projekt: Freigaben der Erweiterungen prüfen, eigene Templates und Schnittstellen nachziehen, Daten migrieren, Testbestellungen durchspielen, ein Zeitfenster außerhalb der Hauptsaison finden.

Rechnen Sie mit internen oder externen Stunden, Testaufwand und Ausfallzeit statt nur mit dem Systempreis; Preise und Tagessätze gehören aus einem datierten, schriftlichen Angebot in die Rechnung. Die Gesamtkosten rechnet Gesamtkosten eines Shopsystems durch, den Ablauf Shopsystem-Wechsel planen.

Wer für Updates und Sicherheit verantwortlich ist

Die Support-Policy ändert nichts daran, wen die Pflicht zum sicheren Betrieb trifft. Nach Art. 32 Abs. 1 DSGVO treffen den Verantwortlichen und den Auftragsverarbeiter unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Risiken geeignete technische und organisatorische Maßnahmen, zu denen die Fähigkeit gehört, die Systeme verfügbar und belastbar zu halten und nach einem Zwischenfall rasch wiederherzustellen (Buchst. b und c). In Deutschland und Österreich gilt Art. 32 Abs. 1 DSGVO; nach Art. 3 Abs. 2 DSGVO kann die Verordnung auch einen Verantwortlichen außerhalb der Union erfassen, der Personen in der Union Waren oder Dienstleistungen anbietet. Für die Schweiz verlangt Art. 8 Abs. 1 DSG geeignete technische und organisatorische Maßnahmen für eine dem Risiko angemessene Datensicherheit; die Mindestanforderungen erlässt der Bundesrat (Art. 8 Abs. 3 DSG).

Ein Wartungsvertrag beschreibt, was ein Dienstleister tut; er ersetzt nicht die Maßnahmen, zu denen Art. 32 Abs. 1 DSGVO verpflichtet. Eine Prüfliste für den eigenen Betrieb gibt Sicherheit im Shop: Grundschutz-Checkliste.

Eine zweite Regel steht im Abschnitt über die Hersteller: Für auf dem Markt bereitgestellte Produkte mit digitalen Elementen, deren Zweck oder vorhersehbare Verwendung eine Datenverbindung einschließt (Art. 2 Abs. 1 der Verordnung (EU) 2024/2847), legt der Hersteller den Unterstützungszeitraum nach der voraussichtlichen Nutzungsdauer fest; er beträgt mindestens fünf Jahre, außer wenn das Produkt voraussichtlich kürzer in Betrieb ist (Art. 13 Abs. 8). Das Enddatum muss beim Kauf klar zugänglich angegeben werden, mindestens mit Monat und Jahr (Art. 13 Abs. 19); Sicherheitsaktualisierungen müssen mindestens zehn Jahre oder für die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben, je nachdem, was länger ist (Art. 13 Abs. 9). Die Pflichten gelten ab 11. Dezember 2027 (Art. 71 Abs. 2) und erfassen Produkte, die vor diesem Datum in Verkehr gebracht wurden, nur, wenn sie danach einer wesentlichen Änderung unterliegen (Art. 69 Abs. 2). Ob Ihr Shopsystem darunter fällt, hängt von den Umständen ab; lassen Sie sich das vom Anbieter bestätigen. Weitere Pflichten für Händler nennt NIS2 und Cyber Resilience Act.

Warnsignale in Angebot und Vertrag

• Die Update-Policy nennt kein Enddatum, sondern nur „regelmäßige Updates“.
• Eine Zusage wie „dauerhaft“ oder „lebenslang“ steht ohne Definition, worauf sich die Dauer bezieht.
• Unterstützt ist nur eine Hauptfassung („Version 9“), nicht die Fassung, die Sie heute erhalten.
• Ein Sicherheitsprozess fehlt: keine Hinweise, keine Meldestelle, keine koordinierte Offenlegung.
• Enddaten von Laufzeitumgebung, Datenbank oder TLS-Bibliothek fehlen.
• Der Preis ist genannt, der Umstiegspfad nicht: kein Wort zu Zwischenschritten, Migration und Test.

Welche Kriterien für welchen Betrieb

Betrieb	Was am schwersten wiegt	Erste Prüffrage
Selbst betriebenes Open-Source-System	Patchprozess und Abhängigkeiten liegen bei Ihnen	Wer prüft Hinweise und spielt innerhalb welcher Frist ein?
Gemietetes System (SaaS)	Update-Takt und Ankündigungsfrist des Anbieters	Wie viel Zeit liegt zwischen Ankündigung und Update?
Shop mit Erweiterungen Dritter	Freigaben für die nächste Fassung	Welche Erweiterungen sind für die nächste Fassung freigegeben?
B2B-Shop mit eigenen Anpassungen	Nachziehen der Anpassungen bei jedem Major-Sprung	Was kostet der Nachzug je eigener Anpassung?
Saisongeschäft	Zeitfenster für Updates	Können Sie Zeitfenster außerhalb der Saison mitbestimmen?
Shop mit Warenwirtschaft oder ERP	Zusammenspiel der Versionen beider Systeme	Welche Fassung der Schnittstelle passt zu welcher Shop-Fassung?

Für Miete oder eigenen Betrieb: SaaS-Shop oder Self-Hosting; zum Aufwand beim Selbstbetrieb Open-Source-Shopsystem: Aufwand und Grenzen.

So prüfen Sie in fünf Schritten

1. Lesen Sie die laufende Fassung des Systems, jeder Erweiterung und der Laufzeitumgebung aus und notieren Sie sie mit Datum.
2. Öffnen Sie die Support-Policy des Projekts oder Anbieters und suchen Sie die beiden Fristen je Fassung; fehlt eine Angabe, notieren Sie „nicht zugesagt“ statt einer Schätzung.
3. Füllen Sie die Lebenszyklus-Tabelle aus, mit Quelle und Lesedatum in jeder Zeile; Abhängigkeiten bekommen eigene Zeilen.
4. Bestimmen Sie das früheste Datum der Tabelle und legen Sie den Umstieg davor, mit einem Zeitfenster außerhalb Ihrer Hauptsaison.
5. Fragen Sie Upgrade-Pfad, Aufwand und Preis schriftlich mit Datum an und prüfen Sie die Antwort gegen Ihre Tabelle.