Plesk Obsidian Update: Neue Funktionen für Hosting-Anbieter

Versionsstand und Komponenten sauber trennen

Der dokumentierte Stand zum 2. Oktober 2026 lautet für das Kernprodukt Plesk Obsidian 18.0.81 Update 2. Dieses Update erschien am 29. September 2026 und behebt ein kritisches Sicherheitsproblem. Die in diesem Artikel beschriebenen neuen Panel-Funktionen gehören zum Release Plesk Obsidian 18.0.81 vom 15. September 2026; Update 1 und Update 2 enthalten dagegen dokumentierte Fehler- und Sicherheitskorrekturen.

Spätere Aktualisierungen können dennoch vorhanden sein, ohne den Kernstand 18.0.81 Update 2 zu verändern: Der Changelog führt beispielsweise Updates für Erweiterungen wie SSL It! und Let’s Encrypt vom 29. September sowie PHP-Paketupdates vom 30. September 2026 auf. Wer nur von einem „aktuellen Plesk“ spricht, lässt daher eine für Planung und Support wichtige Information aus.

Plesk trennt mehrere Aktualisierungsebenen. Plesk-Pakete bilden das Panel selbst und dessen unmittelbar zugehörige Funktionen. Daneben stehen von Plesk bereitgestellte Service-Pakete und Erweiterungen, die zusätzliche Fähigkeiten liefern oder externe Dienste anbinden können. Eine neue Versionsnummer einer Erweiterung ist deshalb kein Beleg dafür, dass auch der Plesk-Kern auf einem neuen Stand ist – und umgekehrt.

Zusätzlich betreibt jedes Hosting Panel innerhalb eines Betriebssystems weitere Ebenen: Betriebssystempakete sowie Drittkomponenten, etwa Datenbanken, PHP-Laufzeiten, Webserver und Maildienste. Deren Paketquellen, Supportzyklen und Abhängigkeiten folgen nicht zwingend dem Veröffentlichungsrhythmus von Plesk. Für einen Provider ist diese Trennung praktisch relevant, weil Fehlerbilder, Wartungsfenster und Zuständigkeiten je nach betroffener Komponente unterschiedlich ausfallen können.

In der Bestandsdokumentation sollte deshalb stets die konkrete Kombination stehen: Plesk-Version mit Update-Nummer, installierte Erweiterungsversion, Betriebssystem und relevante Laufzeitpakete. Bei Zertifikats- oder Anwendungsfunktionen gehört auch die benutzte Integration dazu. So wird etwa nachvollziehbar, ob eine Änderung aus SSL It!, einer Let’s-Encrypt-Integration oder aus dem Panel-Kern stammt. Das verhindert unklare Erwartungen bei Kundenankündigungen und vereinfacht die Eingrenzung im Support.

Wie Plesk Updates Provider betreffen

Innerhalb der Obsidian-Linie 18.0 werden Updates fortlaufend und sequenziell installiert. Einzelne Zwischenupdates lassen sich nicht überspringen. Das schafft einen definierten Aktualisierungspfad, entbindet einen Provider aber nicht von der Prüfung der eigenen Umgebung: Je mehr Kundenwebsites, individuelle PHP-Abhängigkeiten und Erweiterungen ein Server trägt, desto wichtiger ist die Frage, welche Änderung welche Dienstklasse berührt.

Plesk beschreibt automatische Aktualisierungen für eigene Updates und getrennte Optionen für mitgelieferte Drittkomponenten sowie Systempakete. Die Dokumentationsseite macht zum Standardzustand der Drittkomponenten-Option jedoch widersprüchliche Angaben. Administratoren sollten deshalb nicht von einem global gültigen Default ausgehen, sondern die tatsächlich gesetzten Optionen je Server unter Tools & Settings > Update Settings prüfen. Besondere Vorsicht ist geboten, weil neuere Komponenten mit gehosteten Websites inkompatibel sein können.

Für den Betrieb vieler Kundeninstanzen ist diese Unterscheidung ein Vorteil, wenn sie in Prozesse übersetzt wird. Panel-Korrekturen und Sicherheitsänderungen können anhand ihres Umfangs geplant werden; Komponentenwechsel erhalten dagegen eine eigene Kompatibilitätsbewertung. Ein Managed-Hosting-Angebot muss nicht jede verfügbare Paketversion sofort übernehmen. Entscheidend ist, welche Versionen zum zugesagten Stack, zur getesteten Kundenbasis und zum vorgesehenen Supportmodell passen.

Der Nutzen jüngerer Obsidian-Stände verteilt sich dabei auf mehrere Betriebsbereiche: Diagnosefunktionen können den First-Level-Support strukturieren, neue Application-Hosting-Werkzeuge erweitern Tarifoptionen, und Zertifikats- sowie Assistenzfunktionen berühren Sicherheit und Rechteverwaltung. Frühere Grundlagen und Entwicklungen der Produktlinie ordnet auch der Beitrag Plesk Obsidian 2025: Revolutionäre Neuerungen für Webhosting ein. Für die aktuelle Einführung bleibt jedoch die genaue Komponente maßgeblich, nicht allein der Produktname.

Automatisierung ist damit keine pauschale Freigabeentscheidung. Sinnvoll ist eine Trennung zwischen regelmäßiger Installation dokumentierter Plesk-Updates und bewusst gesteuerten Änderungen am Kundenstack. Vor allem bei gemeinsam genutzten Servern schützt diese Grenze davor, dass ein unbemerkter Komponentenwechsel zugleich viele voneinander unabhängige Websites betrifft. Sie ersetzt keine Tests, macht Risiken aber sichtbar und zuordenbar.

Neue Funktionen nach Hosting-Szenario

Im Shared Hosting liegt ein erster Anwendungsfall in der schnelleren Einordnung von Domainstörungen. Die in Plesk Obsidian 18.0.81 allgemein verfügbare DNS-Diagnose bündelt Prüfungen zur Auflösung, zu MX-bezogenen Aspekten, DNSSEC, Nameservern und zum Ablauf der Domain. Der lesbare Bericht im Panel kann Supportmitarbeitern helfen, DNS-, Mail- und Delegationsthemen vor einer Eskalation strukturiert zu prüfen.

Der Bericht ist jedoch eine Diagnose und keine automatische Korrektur. Insbesondere Domain-Aliase werden derzeit nicht abgedeckt. Auch wenn ein Befund auf eine fehlerhafte Delegation oder Zone hinweist, liegt die Behebung gegebenenfalls beim Registrar oder bei einem externen DNS-Betreiber. Als Supportwerkzeug ist die Funktion daher besonders nützlich, wenn Zuständigkeiten und der nächste Eskalationsschritt im Ticket klar festgehalten werden.

Ein zweites Feld ist Application Hosting für Agenturen und Entwickler. Node.js Toolkit 2.5.0 ergänzt eine zentrale Übersicht aktivierter Node.js-Anwendungen und die Ein-Klick-Konfiguration vorhandener Projekte. Die automatische Erkennung kann mehrere verbreitete Server-Frameworks sowie statische Frontends erfassen. Zusätzlich unterstützt die Erweiterung pnpm ausschließlich unter Plesk für Linux. Das reduziert wiederkehrende Einzelschritte, ist aber keine Zusage, dass jedes individuelle Deployment unverändert übernommen werden kann.

Die neue Python-Erweiterung 1.0.0 adressiert ebenfalls Linux-Systeme und stellt Python-Support pro Domain, virtuelle Umgebungen, Abhängigkeiten, Umgebungsvariablen und verschlüsselt gespeicherte Secrets bereit. Anwendungen laufen dabei als WSGI-Anwendungen über Phusion Passenger; die Berechtigung „Python support management“ lässt sich über Servicepläne und Subscriptions steuern. Daraus kann ein kontrolliertes Tarifmerkmal werden, nicht automatisch ein Ersatz für jede Python-Architektur.

Ein drittes Feld umfasst Zertifikate und Assistenzfunktionen. SSL It! unterstützt in 18.0.81 die DNS-Validierung als Alternative zur HTTP-Validierung für die genannten ext-acme- und ext-letsencrypt-Integrationen. Das ist etwa für Domains ohne offenen Port 80 relevant. Voraussetzung bleibt ein geeigneter Weg, DNS-Einträge in der tatsächlich zuständigen Zone zu setzen; die bloße Anzeige eines Records verschafft keinen Schreibzugriff.

MCP ist in 18.0.81 standardmäßig deaktiviert und kann über einen WebPros Account angebunden werden. Administratoren bestimmen in panel.ini die Benutzertypen, die MCP-Clients verbinden dürfen. Seine Eignung hängt deshalb nicht nur von der Funktion ab, sondern von Rollen, Freigaben und Protokollierung. Plattformabhängige Erweiterungsfunktionen, externe DNS-Zuständigkeit und die Architektur der Kundenanwendung entscheiden insgesamt darüber, welche Neuerung in welchen Tarif gehört.

Funktionsvergleich für die Produktplanung

Für die Produktplanung genügt die Bezeichnung Plesk Obsidian nicht: Die hier relevanten Funktionen stammen teils aus dem Kernprodukt, teils aus separat versionierten Erweiterungen. Deshalb sollte ein Provider Funktionen nicht allein nach ihrem Nutzen bewerten, sondern jeweils Betriebssystem, Freigabemodell und technische Abhängigkeiten in den Tarifkatalog aufnehmen.

Die Übersicht trennt besonders deutlich zwischen einer Plattformfunktion und einer vermarktbaren Tarifleistung. Die DNS-Diagnose kann breit als Supportwerkzeug bereitstehen. Python gehört dagegen nur in Linux-Angebote, deren Rechteverwaltung und Supportgrenzen dafür vorgesehen sind. Bei Node.js muss der Provider die jeweilige Teilfunktion unterscheiden: pnpm ist Linux-exklusiv dokumentiert, während der Changelog die zentrale Übersicht und Autokonfiguration nicht entsprechend beschränkt.

Auch die Zertifikats- und MCP-Funktionen verlangen eine Produktentscheidung statt einer globalen Aktivierung. Bei DNS-01 entscheidet die Zuständigkeit für die Zone über die praktische Nutzbarkeit. Bei MCP ist die technische Verbindung nur ein Teil des Vorhabens; maßgeblich sind der erlaubte Personenkreis, nachvollziehbare Abläufe und die Behandlung von Aktionen mit Seiteneffekten.

DNS-Diagnose und Zertifikate im Support

Die in Plesk Obsidian 18.0.81 allgemein verfügbare DNS-Diagnose eignet sich als erste technische Einordnung eines Domaintickets. Im Panel öffnet „Troubleshoot DNS“ einen lesbaren Bericht zu DNS-Auflösung, MX-bezogenen Prüfungen, DNSSEC, Nameserver-Problemen und dem Ablaufdatum der Domain. Das verkürzt die Vorprüfung, ersetzt aber weder die Analyse der autoritativen Zone noch die Abstimmung mit Registrar oder externem DNS-Betreiber.

Für einen wiederholbaren First-Level-Ablauf sollte der Support zunächst die betroffene Hauptdomain und den Bericht erfassen, danach Zuständigkeit und Auffälligkeit zuordnen. Zeigt der Bericht etwa eine fehlerhafte Delegation, liegt die Korrektur häufig außerhalb des Panels. Wichtig ist auch die dokumentierte Grenze: Domain-Aliase werden von dieser Prüfung derzeit nicht abgedeckt.

Für die Diagnose auf der Kommandozeile dokumentiert der Changelog den folgenden Aufruf mit einer neutralen Beispieldomain. Vor dem Einsatz sollte ein Administrator die Hilfe beziehungsweise Befehlsdokumentation des tatsächlich installierten Plesk-Stands prüfen. Aus der im Changelog genannten Syntax allein lässt sich keine weitergehende Garantie über sämtliche Auswirkungen des Befehls ableiten.

plesk repair dns -n -j -check-resolution example.com

Bei Zertifikaten erweitert DNS-01-Validierung den möglichen Einsatzbereich: SSL It! kann sie in Plesk Obsidian 18.0.81 alternativ zur HTTP-Validierung für Ausstellung und Verlängerung verwenden. Das ist etwa für API- oder Mail-Domains relevant, bei denen Port 80 bewusst nicht offensteht. Plesk zeigt die benötigten DNS-Einträge an und speichert die gewählte Methode pro Domain für spätere Verlängerungen.

Der Ablauf wird jedoch nicht automatisch erfolgreich, nur weil ein Record angezeigt wird. Der Betreiber braucht Schreibzugriff auf die tatsächlich zuständige DNS-Zone oder einen passend eingerichteten Automatisierungsweg. Die mit 18.0.81 eingeführte DNS-Validierung gilt laut Changelog nur für die ext-acme- und ext-letsencrypt-Integrationen von SSL It!, nicht pauschal für jeden Zertifikatsanbieter.

Davon getrennt ist das spätere Erweiterungsupdate SSL It! 1.24.0 vom 29. September 2026. Mit dieser Version kann eine Domain ohne Hosting über das Panel oder die Kommandozeile mit einem Wildcard-Zertifikat abgesichert werden; die automatische Verlängerung erfolgt ebenfalls als Wildcard-Zertifikat. Diese Ergänzung ist kein Bestandteil des ursprünglichen Funktionsumfangs von Plesk Obsidian 18.0.81, sondern folgt dem eigenen Versions- und Veröffentlichungsstand der Erweiterung.

Application Hosting als kontrollierte Tarifoption

Application Hosting wird mit den aktuellen Erweiterungen besser als Tarifoption abgrenzbar. Das Node.js Toolkit 2.5.0 ergänzt eine zentrale Übersicht aktivierter Node.js-Anwendungen und eine Ein-Klick-Konfiguration vorhandener Projekte. Zusätzlich unterstützt die Erweiterung den Paketmanager pnpm unter Plesk für Linux. Damit kann ein Provider wiederkehrende Einrichtungsaufgaben standardisieren, ohne jede Kundenanwendung als individuellen Serverbetrieb behandeln zu müssen.

Die Projekterkennung umfasst laut Changelog unter anderem Express, Next.js, NestJS und Nuxt.js sowie statische Frontends auf Basis von React, Vue.js, Angular oder Vite. Plesk kann eine Passenger-kompatible Startdatei anlegen, hartcodierte Ports berücksichtigen und den Document Root setzen, wobei die Änderungen vor der Bestätigung angezeigt werden. Statische Frontends werden gebaut und ohne dauerhaft laufenden Node.js-Prozess ausgeliefert.

Diese Automatisierung ist hilfreich, aber kein Ersatz für ein Architekturreview. Mehrere Prozesse, Worker-Queues, besondere Reverse-Proxies, externe Secrets oder eigene Build-Pipelines können zusätzliche Betriebsregeln erfordern. Die Linux-Beschränkung gilt laut Changelog ausdrücklich für pnpm; für die zentrale Domainübersicht und die Ein-Klick-Autokonfiguration ist dort keine entsprechende Plattformbeschränkung ausgewiesen. Tarifbeschreibungen sollten diese Teilfunktionen deshalb getrennt benennen.

Die Python-Erweiterung 1.0.0 eröffnet auf Linux ein getrennt steuerbares Angebot pro Domain. Kunden können virtuelle Umgebungen anlegen, Abhängigkeiten über die Oberfläche installieren, Metadaten aus pyproject.toml ansehen und Umgebungsvariablen sowie verschlüsselt gespeicherte Secrets verwalten. Die Freigabe erfolgt über die Berechtigung „Python support management“ in Serviceplänen und Abonnements.

Technisch laufen diese Anwendungen als WSGI-Anwendungen über Phusion Passenger; die Webserver-Konfiguration erzeugt Plesk automatisch. Ein Tarif „Python Web App“ kann deshalb beispielsweise virtuelle Umgebungen, einen definierten Ressourcenrahmen und Support für klassische WSGI-Projekte enthalten. Daraus folgt nicht, dass derselbe Tarif komplexe ASGI-Stacks, dauerhaft laufende Worker oder containerisierte Spezialarchitekturen abdeckt.

Für die Einordnung älterer Funktionen und Oberflächenänderungen kann der Beitrag Plesk Obsidian: Neuerungen und Verbesserungen im Überblick ergänzend herangezogen werden. Für neue Tarife bleibt entscheidend, die Erweiterungsversion, dokumentierte Plattformgrenzen, Berechtigungen und den konkret unterstützten Anwendungstyp gemeinsam zu dokumentieren.

Updates gestaffelt in Produktion einführen

Ein Update des Hosting Panels sollte in einer Provider-Umgebung nicht mit dem ersten Klick auf dem produktiven Hauptserver beginnen. Erstelle zunächst ein Inventar aus Plesk-Versionen, Betriebssystemständen, aktivierten Erweiterungen und den darauf betriebenen Kundenanwendungen. Wichtig sind außerdem externe Abhängigkeiten wie DNS-Anbieter, Mail-Relays, Backups, eigene PHP-Pakete und Deployment-Abläufe. So wird sichtbar, welche Systeme denselben Stand haben und welche Sonderfälle getrennt behandelt werden müssen.

Prüfe danach die Abhängigkeiten je Serverklasse. Ein Kernprodukt-Update kann andere Auswirkungen haben als ein Update einer Erweiterung oder einer Drittkomponente. Auch die vom Betriebssystem bereitgestellten Pakete bleiben ein eigener Wartungsbereich. Plesk trennt diese Kategorien ausdrücklich; besonders Aktualisierungen von Drittkomponenten können Websites betreffen, wenn diese auf veränderte Versionen oder Laufzeitumgebungen nicht vorbereitet sind.

Als Nächstes empfiehlt sich eine repräsentative Pilotinstanz statt eines beliebigen Testservers. Sie sollte typische Tarifkonstellationen abbilden: etwa klassische CMS-Websites, Mail-Domains, Datenbanknutzung sowie aktivierte Node.js- oder Python-Anwendungen, falls diese angeboten werden. Der Zweck ist nicht, vollständige Gleichheit zur Produktion vorzutäuschen, sondern relevante Kombinationen aus Betriebssystem, Erweiterungen und Kundenanwendungen vorab sichtbar zu machen.

Lege für die produktive Ausbringung ein Wartungsfenster mit klarer Reihenfolge fest. Aktualisiere zunächst eine begrenzte Servergruppe, werte die Beobachtungen aus und erweitere erst dann den Rollout. Kontrolliere danach Panel-Erreichbarkeit, geplante Sicherungen, Web- und Maildienste, Zertifikatsverlängerungen sowie Fehlermeldungen der betroffenen Anwendungen. Diese Kontrollen senken Unsicherheit, sind jedoch keine Zusage für Ausfallfreiheit oder vollständige Anwendungs-Kompatibilität.

Zur Kapazitätsplanung nennt Plesk Mindestwerte von 1 GB RAM zuzüglich 1 GB Swap unter Linux und 2 GB RAM unter Windows. Für Shared Hosting wird als grobe Empfehlung 1 GB RAM je 40 bis 50 Websites genannt, sofern höchstens zehn Prozent aller gehosteten Websites eine anhaltende beziehungsweise regelmäßige Zahl von Besuchern pro Woche oder Monat aufweisen. Solche Ressourcenrichtwerte sind keine Kapazitätsgarantie und ersetzen keine Messung der eigenen Last: Datenbankaktivität, Mail-Aufkommen, Sicherheitssoftware und Anwendungsart können den Bedarf deutlich verändern.

Fehlerquellen und Sicherheitsprioritäten erkennen

Wiederkehrende Fehler entstehen meist durch ungenaue Produktgrenzen. Dokumentiere deshalb bei jeder Ankündigung die konkrete Kernprodukt- oder Erweiterungsversion. Eine Node.js- oder Python-Funktion darf nicht pauschal für Windows-Tarife beworben werden, wenn sie nur für Plesk für Linux dokumentiert ist. Ebenso ist Python Hosting mit WSGI über Passenger nicht gleichbedeutend mit einer Freigabe beliebiger ASGI-, Worker- oder Container-Architekturen.

• DNS-01 erst als Tarifmerkmal einplanen, wenn Schreibzugriff auf die autoritative DNS-Zone oder ein passender Automatisierungsweg vorhanden ist.
• Die Optionen für automatische Plesk-, Drittkomponenten- und Systempaket-Updates nicht gleichsetzen; den tatsächlich gesetzten Zustand je Server unter „Tools & Settings > Update Settings“ prüfen.
• Erweiterungen, Berechtigungen und Betriebssysteme vor der Freischaltung neuer Funktionen je Produktlinie prüfen.
• Für MCP vor einer Rollenfreigabe zulässige Nutzergruppen, Freigabewege und die Protokollierung von Aktionen festlegen.

Die Sicherheitspriorität richtet sich nicht allein nach dem Komfort des Wartungsfensters. Zum Artikelstichtag ist Plesk Obsidian 18.0.81 Update 2 vom 29. September 2026 der aktuelle dokumentierte Patchstand dieser Kernrelease-Linie; Plesk weist dafür auf ein kritisches Sicherheitsproblem hin und empfiehlt die zeitnahe Installation. Update 1 vom 21. September enthielt ebenfalls eine kritische Sicherheitskorrektur, die im Changelog ausdrücklich unter Linux geführt wird. Für Linux-Systeme sollte daher nicht bei Update 1 stehen geblieben werden.

Der Changelog führt im September außerdem kritische Sicherheitskorrekturen für Node.js Toolkit 2.5.0 vom 14. September 2026 und Site Import 1.12.2 vom 23. September 2026 auf. Prüfe deshalb immer, ob die jeweils betroffene Komponente installiert ist, und behandle Panel-Kern, Erweiterungen, PHP-Pakete und weitere Add-ons als getrennte Patchpfade. Ein späterer Erweiterungs- oder PHP-Stand ersetzt kein ausstehendes Kernprodukt-Update.

MCP verdient einen begrenzten Pilotbetrieb statt einer sofortigen breiten Aktivierung. Die Funktion ist standardmäßig deaktiviert; Administratoren können in panel.ini festlegen, welche Benutzertypen MCP-Clients verbinden dürfen. Lege vorab fest, welche Aufgaben unterstützt werden sollen, wer Änderungen prüfen darf und wie auffällige oder unerwünschte Aktionen nachvollzogen werden. Eine KI-Anbindung ersetzt weder Rollenmodelle noch Change Management oder technische Reviews.

Warnung: Drittkomponenten sollten nicht allein wegen einer verfügbaren neueren Version unkontrolliert in alle Kundenumgebungen gelangen. Plesk weist auf mögliche Inkompatibilitäten mit gehosteten Websites hin; zugleich enthält die aktuelle Dokumentationsseite widersprüchliche Angaben dazu, ob die entsprechende Automatik standardmäßig aktiv ist. Prüfe daher je Server unter Tools & Settings > Update Settings die gesetzten Optionen und plane für verbreitete Laufzeiten und Plugins eine abgestufte Freigabe mit einer repräsentativen Pilotgruppe.

Upgrade oder Servertransfer entscheiden

Die Wahl zwischen In-Place-Upgrade und Servertransfer beginnt mit dem Ist-Zustand, nicht mit der gewünschten Obsidian-Version. Ein Upgrade auf demselben Server setzt voraus, dass Betriebssystem und installierte Plesk-Ausgangsversion für den vorgesehenen Weg unterstützt werden. Prüfe zusätzlich die verwendeten Erweiterungen, eigene Anpassungen und den verfügbaren Platz für Sicherungen. Ein technisch möglicher Updatepfad ist noch keine Aussage darüber, dass er für jede Kundenlandschaft passend ist.

Für Plesk Onyx nennt die Upgrade-Dokumentation direkte Wege zu Obsidian für die Versionen 17.0, 17.5 und 17.8. Ältere oder nicht passend unterstützte Ausgangsumgebungen können einen Transfer auf einen neuen Obsidian-Server erforderlich machen, sofern die Ausgangsversion migrierbar ist. Der Transfer schafft dabei die Möglichkeit, Betriebssystem, Ressourcenlayout und Erweiterungsbestand getrennt vom Altsystem vorzubereiten.

Ein neuer Zielserver ist besonders prüfenswert, wenn das vorhandene Betriebssystem sein Supportende erreicht, die Plattform über lange Zeit individuell verändert wurde oder mehrere große Versionssprünge zusammenkommen. Die Systemanforderungen von Plesk liefern dabei nur die Untergrenze der Planung. Für die Zielgröße zählen ebenso Website-Zahl, Mailboxen, Datenbanken, Sicherheitsdienste, Backup-Aufbewahrung und die erwartete Last nach der Migration.

Beim Upgrade durch Transfer wird die bestehende Umgebung auf einen Server mit installiertem Plesk Obsidian verschoben. Voraussetzung ist laut Upgrade-Dokumentation, dass das Betriebssystem des Zielservers unterstützt wird und die installierte Ausgangsversion eine Migration zu Obsidian erlaubt. Ob dieser Weg verfügbar ist, sollte deshalb vor der Planung anhand der konkreten Quellversion geprüft werden.

Für eine aktuelle, unterstützte und überschaubare Installation ist zeitnahes Patchen nach Inventar und Pilotierung meist der naheliegende Weg. Bei neuen Erweiterungen oder Linux-spezifischen Angebotsfunktionen ist eine gezielte Pilotphase sinnvoll. Wenn Betriebssystem-Support, Ausgangsversion oder technische Altlasten den Weg begrenzen, sollte zunächst eine Migration vorbereitet werden. Welche Variante geeignet ist, ergibt sich aus Supportstatus, Kompatibilität und Betriebsmodell – nicht aus einer pauschalen Produktivfreigabe.