Neuerungen in PowerShell 7.5: Upgrade-Check für Teams

Solltest du auf PowerShell 7.5 wechseln?

Hinweis: Seit März 2026 ist PowerShell 7.6 (LTS) verfügbar – die neue empfohlene Version für Produktionsumgebungen mit drei Jahren Support.

PowerShell 7.5 ist seit Dezember 2024 als stabile Version verfügbar. Für viele Teams ist der Wechsel sinnvoll, wenn neue Features gebraucht werden und ein kontrollierter Rollout möglich ist.

Stand: 2026-02
Getestet mit: PowerShell 7.5 (pwsh) und einem modularen Upgrade-Check in Test-/Staging-Umgebungen.
Fokus dieses Artikels: PowerShell 7.5.
Die gezeigten Befehle sind so gewählt, dass du sie direkt in deinem eigenen Umfeld verifizieren kannst.

Kurzempfehlung nach Einsatztyp

Einsatztyp	Empfehlung
Produktive Kernsysteme mit hoher Stabilitätsanforderung	Bei PowerShell 7.4 (LTS) bleiben und 7.5 parallel evaluieren
Automatisierungsteams mit Test-/Staging-Umgebung	7.5 pilotieren, dann schrittweise ausrollen
Einzelne Admin-Workstations und Dev-Umgebungen	7.5 direkt einsetzen, wenn Modultests grün sind

Upgrade-Checkliste für PowerShell 7.5

1) Ist-Zustand sauber erfassen

$PSVersionTable.PSVersion
Get-Module -ListAvailable | Sort-Object Name, Version

Damit dokumentierst du Version und Modulbasis vor dem Wechsel.

2) Kritische Module gezielt prüfen

$requiredModules = @('Az', 'SqlServer', 'Pester')

foreach ($name in $requiredModules) {
    $module = Get-Module -ListAvailable -Name $name |
        Sort-Object Version -Descending |
        Select-Object -First 1

    [pscustomobject]@{
        Module           = $name
        InstalledVersion = if ($module) { $module.Version } else { 'nicht installiert' }
    }
}

Wenn kritische Module fehlen oder zu alt sind, zuerst die Modulstrategie klären, dann upgraden.

3) Kernskripte mit Messwerten vergleichen

$baseline = Measure-Command {
    1..200 | ForEach-Object {
        Get-Date | Out-Null
    }
}

$baseline.TotalMilliseconds

Miss vor und nach dem Wechsel dieselben Jobs. Nur so ist ein Nutzen belastbar belegbar.

Typische Risiken im Upgrade

• Unterschiede in Modulen und Abhängigkeiten werden oft spät entdeckt.
• Nicht reproduzierbare Umgebungen erschweren Ursachenanalyse.
• Fehlende Rollback-Strategie verlängert Störungen im Betrieb.

So führst du den Wechsel risikoarm ein

• Erst Pilotgruppe, dann stufenweiser Rollout.
• CI/CD-Pipeline mit Pester-Tests vor produktiven Jobs.
• Pro Skript eine klare Rückfalloption auf die vorherige Runtime.

Weiterführende Ressourcen

• Offizielle Releases: PowerShell Releases auf GitHub
• Sicherheitsfokus: PowerShell sicher einsetzen
• Cmdlet-Recherche: PowerShell Cmdlet finden
• Praxisbeispiel Automation: PowerShell und T-SQL automatisieren

Unterstützung für dein Team

Wenn du PowerShell 7.5 in deinem Unternehmen strukturiert einführen willst, findest du hier den passenden Einstieg:

• Leistungen
• Kontakt