ServiceNow-Upgrade: 7 Dinge, die Sie
vor dem nächsten Release prüfen sollten

ServiceNow veröffentlicht zweimal jährlich eine neue Hauptversion – zuletzt im Rhythmus Washington, Xanadu, Yokohama. Für viele Unternehmen ist das Upgrade ein Projekt für sich: Testaufwand, Abstimmung mit Stakeholdern, Regressionstests, Hypercare nach dem Go-Live. Wer sich gut vorbereitet, macht aus einem Risiko eine Chance.

Hier sind die sieben Punkte, die wir in jedem Upgrade-Projekt als erstes prüfen.

1. Upgrade-Skipping – wo stehen Sie gerade?

ServiceNow unterstützt das direkte Upgrade über mehrere Versionen hinweg, solange bestimmte Pfade eingehalten werden. Wer noch auf einer sehr alten Version läuft, muss unter Umständen Zwischenstops einplanen. Prüfen Sie im Now Support-Portal die offiziellen Upgrade-Pfade für Ihre aktuelle Version, bevor Sie irgendetwas anderes tun.

2. Customizations inventarisieren

Das größte Upgrade-Risiko sind Customizations – also alle Anpassungen, die vom ServiceNow-Standard abweichen. Dazu gehören:

• Modifizierte Out-of-the-Box-Skripte und Business Rules
• Eigene UI-Anpassungen und Client Scripts
• Angepasste Workflows und Flow Designer-Flows
• Integrationen über REST APIs und MID Server

Nutzen Sie den Upgrade Monitor und das Upgrade Center in ServiceNow, um eine vollständige Liste aller skipped und customized Dateien zu erhalten. Das ist Ihr Startpunkt für die Risikoabschätzung.

3. Sub-Production-Instanz zuerst

Klingt selbstverständlich, wird aber in der Praxis oft unter Zeitdruck vernachlässigt: Das Upgrade immer zuerst in der Entwicklungs- oder Test-Instanz durchführen und dort vollständig testen, bevor Production angefasst wird. Planen Sie ausreichend Zeit für Regressionstests ein – mindestens zwei Wochen für mittlere Instanzen.

„Ein Upgrade auf Production ohne vorherigen Sub-Production-Test ist kein Mut – es ist ein vermeidbares Risiko."

4. Release Notes gründlich lesen

Jede neue ServiceNow-Version bringt Deprecation-Hinweise mit sich – Features, die in der aktuellen Version noch funktionieren, aber in der übernächsten entfernt werden. Wer diese Hinweise ignoriert, arbeitet gegen die Uhr. Lesen Sie die Release Notes und die Deprecation Notes gezielt auf Komponenten, die Sie aktiv nutzen.

5. Plug-in- und Store-App-Kompatibilität prüfen

Aktivierte Plugins und aus dem ServiceNow Store bezogene Apps müssen nicht automatisch mit jeder neuen Hauptversion kompatibel sein. Prüfen Sie für jede installierte App die Kompatibilitätsmatrix im Now Store – und klären Sie im Vorfeld, ob Updates verfügbar sind oder ob eine App temporär deaktiviert werden muss.

6. Stakeholder und Hypercare-Plan vorbereiten

Ein technisch sauberes Upgrade kann trotzdem scheitern, wenn die Nutzer nicht vorbereitet sind. Neue UIs, veränderte Workflows, umbenannte Felder – solche Änderungen müssen kommuniziert werden. Planen Sie:

1. Kommunikation an alle betroffenen Nutzergruppen vor dem Upgrade
2. Release Notes in einfacher Sprache für Nicht-IT-Stakeholder
3. Hypercare-Zeitraum von mindestens zwei Wochen nach Go-Live
4. Klaren Eskalationsweg für kritische Probleme nach dem Upgrade

7. Rollback-Plan definieren

Im Idealfall brauchen Sie ihn nicht. Aber ein Rollback-Plan gehört zur sorgfältigen Upgrade-Vorbereitung wie der Fallschirm zum Fallschirmsprung. Klären Sie vorab mit ServiceNow bzw. Ihrem Vertragspartner: Unter welchen Bedingungen ist ein Rollback möglich, wie lange dauert er, und wer entscheidet darüber?

ServiceNow-Upgrades auf Shared-Instanzen (Standard-Hosting) haben eingeschränkte Rollback-Optionen. Auf dedizierten Instanzen gibt es mehr Spielraum. Kennen Sie Ihre Optionen, bevor Sie sie brauchen.