Rollout-Plan

Overview

Ein Rollout-Plan beschreibt, wie eine Änderung vom Test bis zur gesamten Organisation verteilt wird: Zielgruppen, Reihenfolge, Zeitplan, technische Voraussetzungen, Kommunikation, Schulung, Erfolgskriterien und Rückfalloptionen. Er gilt für neue Anwendungen, Windows-Feature-Updates, neue Microsoft-365-Funktionen ebenso wie für Sicherheitsrichtlinien wie Conditional Access.

Microsoft empfiehlt für Windows eine ringbasierte Verteilung mit drei Stufen, Preview (Planung und Entwicklung), Limited (Pilot und Validierung) und Broad (breite Verteilung). Technisch bilden Intune Update Rings, Windows-Autopatch-Gruppen und die Update-Kanäle der Microsoft 365 Apps diese Stufen ab.

Aktuelle Änderung: Für Microsoft-365-Dienste wird die Option Targeted Release eingestellt. Ab November 2026 lassen sich keine weiteren Benutzer oder Tenants mehr aufnehmen, im Januar 2027 endet Targeted Release. Microsoft empfiehlt, stattdessen Release-Präferenzen für die Zielgruppen Frontier, Standard und Deferred zu konfigurieren. Bei den Microsoft 365 Apps erhält der Semi-Annual Enterprise Channel ab Juli 2026 monatliche Funktionsupdates.

How it works

Ein Rollout-Plan folgt meist diesem Ablauf:

  1. Umfang und Ziel: Was wird eingeführt, welche Systeme und Anwender sind betroffen, woran wird Erfolg gemessen.
  2. Ringe definieren: Test (IT), Pilot (Key User aus jedem Fachbereich), Breitrollout in einer oder mehreren Wellen, Nachzügler mit Sonderanforderungen.
  3. Technische Umsetzung: Zuweisung an Entra-Gruppen, z. B. Intune-Apps, Update Rings, Autopatch-Gruppen oder Conditional-Access-Richtlinien im Berichtsmodus.
  4. Kommunikation und Schulung: Ankündigung, Anleitungen in der Knowledgebase, Ansprechpartner.
  5. Go/No-Go je Ring: Kriterien wie Fehlerquote, offene Tickets oder Rückmeldungen der Pilotgruppe.
  6. Rückfall: Wie wird pausiert oder zurückgerollt, z. B. Update Ring pausieren, App-Zuweisung entfernen.

Benefits

  • Fehler fallen in kleinen Gruppen auf, bevor sie die gesamte Belegschaft treffen
  • Key User im Pilot liefern früh Rückmeldungen aus der Praxis und werden zu Multiplikatoren
  • Klare Go/No-Go-Kriterien verhindern, dass ein Rollout aus Zeitdruck trotz Problemen weiterläuft
  • Anwender sind vorbereitet, dadurch entstehen weniger Rückfragen am Helpdesk

Practical example

Ein Hersteller von Prüfmaschinen mit 280 Mitarbeitenden führte das neue Outlook für Windows ein. Der Rollout-Plan sah zwei Wochen Test in der IT, vier Wochen Pilot mit zwölf Key Usern und danach drei Wellen nach Standort vor. Im Pilot fiel ein Add-in für die Zeiterfassung auf, das im neuen Outlook nicht lief, der Hersteller lieferte eine Webversion nach. Der Breitrollout verlief danach ohne nennenswerte Störungen.

Things to keep in mind

  • Pilotgruppen fachlich mischen, sonst bleiben Abteilungs-Sonderfälle bis zum Breitrollout unentdeckt
  • Microsoft empfiehlt, Abteilungen auf mehrere Ringe zu verteilen, damit ein Problem nie einen ganzen Bereich lahmlegt
  • Targeted Release nicht mehr neu einplanen und Release-Präferenzen für Standard und Deferred vor Januar 2027 setzen
  • Den Rückfallweg vor dem Start testen, nicht erst im Störungsfall

Conclusion

Ein Rollout-Plan senkt das Risiko jeder Einführung deutlich. Arbeite mit Ringen, festen Go/No-Go-Kriterien und einem getesteten Rückfallweg.