PowerShell 7.4 and 7.5 have reached end of support: planning an enterprise migration to 7.6 LTS

1. The lifecycle decision

Microsoft lists 10 November 2026 as the end-of-support date for PowerShell 7.4 LTS and PowerShell 7.5. Version 7.4 is built on .NET 8 LTS; version 7.5 is built on .NET 9. PowerShell 7.6 is the current LTS line, built on .NET 10, with support scheduled through 14 November 2028.

The official PowerShell repository published 7.6.10 on 10 November 2026. Separate the release date from availability in each distribution channel: Microsoft installation examples can lag behind the latest GitHub release. For a governed deployment, pin the artifact, version, architecture, source and SHA-256. Do not let a pipeline silently select “latest”.

End of support means that the branch no longer receives updates under its support lifecycle. A temporary compatibility exception may be necessary, but it needs an owner, an accepted risk, compensating controls and an exit date.

2. Define the scope: PowerShell 7 is not Windows PowerShell 5.1

PowerShell 7 does not replace Windows PowerShell 5.1. They install separately and can coexist. This matters on Windows Server, where some modules and tools still depend on .NET Framework, operating-system components or Windows PowerShell-specific behaviour.

Do not define the scope as “upgrade every Windows server”. Define it as “identify every execution of PowerShell 7.4/7.5 and migrate compatible workloads, while maintaining a controlled path for workloads that still need 5.1”.

• Administrator consoles and workstations.
• Task Scheduler jobs and maintenance scripts.
• Services, agents and processes that invoke pwsh.exe.
• CI/CD runners, configuration tools and remote automation.
• Containers and base images that include PowerShell.
• Jump servers, management hosts and automation servers.

The operational question is which executable each consumer invokes. A script calling powershell.exe may still run on 5.1; a task with an absolute pwsh.exe path may be pinned to a particular installation or location.

3. Inventory before touching the installer

The inventory should answer four questions: which version is installed, how was it installed, what invokes it and which modules does it need? An interactive session returning $PSVersionTable does not discover scheduled tasks, agents, containers or hard-coded paths.

3.1 Discover registered installations

On Windows, query the standard uninstall registry keys. Avoid Win32_Product as a discovery method: querying it can trigger Windows Installer consistency checks and it is not an appropriate fleet inventory source.

$uninstallRoots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

$powerShellInstalls = foreach ($root in $uninstallRoots) {
  Get-ItemProperty -Path $root -ErrorAction SilentlyContinue
}

$powerShellInstalls |
  Where-Object { $_.DisplayName -match '^PowerShell 7' } |
  Select-Object DisplayName, DisplayVersion, InstallLocation, Publisher

This only covers installations registered in those keys. ZIP packages, portable deployments and executables outside PATH need other discovery sources. Complement it with command resolution:

Get-Command pwsh -All -ErrorAction SilentlyContinue |
  Select-Object Name, Source, Version, CommandType

3.2 Controlled remote discovery

If WinRM is enabled and authorised, an initial inventory can run against an approved computer list. Start with a pilot group, limit concurrency to available management capacity and store results in a protected location.

$computers = Get-Content .\servers-pilot.txt |
  Where-Object { $_ -and $_ -notmatch '^\s*#' }

$inventory = Invoke-Command -ComputerName $computers -ScriptBlock {
  $roots = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
  )

  foreach ($root in $roots) {
    Get-ItemProperty $root -ErrorAction SilentlyContinue |
      Where-Object { $_.DisplayName -match '^PowerShell 7' } |
      Select-Object @{n='ComputerName';e={$env:COMPUTERNAME}},
        DisplayName, DisplayVersion, InstallLocation
  }

  Get-Command pwsh -All -ErrorAction SilentlyContinue |
    Select-Object @{n='ComputerName';e={$env:COMPUTERNAME}},
      @{n='DisplayName';e={'Command resolution'}}, Source, Version
}

$inventory |
  Export-Csv .\powershell-inventory.csv -NoTypeInformation -Encoding utf8

This is a starting snapshot, not exhaustive discovery. Reconcile it with CMDB, Intune/Configuration Manager, software inventory, script repositories, pipeline definitions, scheduled tasks and service configuration.

4. Compatibility: where the risks concentrate

Migrations are often less risky in the engine than in its dependencies: modules, native runtimes, authentication, profiles, executable paths, serialization and assumptions inherited from Windows PowerShell.

4.1 Modules, editions and native dependencies

Record loaded modules, source paths, validated versions and native dependencies. Pay particular attention to internal modules, binary modules, .NET Framework dependencies and modules that install their own prerequisites.

Get-Module -ListAvailable |
  Sort-Object Name, Version |
  Select-Object Name, Version, PSEdition, CompatiblePSEditions, Path

A successful Import-Module is not enough. Exercise the operations the automation actually performs: authentication, permissions, connections, pagination, serialization, date formats, native calls and error handling.

4.2 ThreadJob change

In PowerShell 7.6, the ThreadJob module is replaced by Microsoft.PowerShell.ThreadJob. The Start-ThreadJob cmdlet keeps its name; however, scripts that import or invoke the module using its qualified name should be reviewed.

Get-ChildItem .\automation -Filter *.ps1 -Recurse |
  Select-String -Pattern 'ThreadJob\\Start-ThreadJob|Import-Module\s+ThreadJob'

Treat matches as review signals, not proof of incompatibility. Validate using the same host, service account, profiles, execution policies and operational context that will run the workload.

4.3 Windows PowerShell Compatibility

Some legacy modules can run through the compatibility layer, which uses a local Windows PowerShell process. Do not assume full equivalence: object serialization, sessions, performance and functional behaviour can differ. For each legacy dependency, decide whether it remains temporarily on 5.1, runs through compatibility or is replaced.

5. Recommended deployment model

Use deployment rings and separate the runtime change from script logic changes. Do not update PowerShell, modules, credentials and automation logic at the same time; if something fails, attribution becomes difficult.

5.1 Select the right artifact

• Windows Server: Microsoft identifies MSI as suitable for server and enterprise deployment scenarios. Select the correct architecture and approved installer properties.
• Windows client: WinGet is supported, but availability and format depend on the platform and source. Verify the package actually offered.
• Linux: use the repository and package for the supported distribution; pin version and origin in configuration management.
• ZIP: useful for lab and advanced side-by-side scenarios, but PATH, shortcuts, updates and prerequisites become manual responsibilities.

For reproducibility, retain the approved installer, SHA-256, version, architecture, download source, installation options and change identifier. Installation documentation and feeds may show a different version from the latest GitHub release: record which one you chose and why.

# Verify the package hash before distribution
Get-FileHash .\PowerShell-7.6.10-win-x64.msi -Algorithm SHA256

# Confirm the version after installation
& "$env:ProgramFiles\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command '$PSVersionTable | Format-List'

For MSI, properties such as USE_MU, ENABLE_MU, ENABLE_PSREMOTING, REGISTER_MANIFEST and ADD_PATH affect the installation result and subsequent operation. Do not enable remoting or change PATH fleet-wide without a security and operations decision.

6. Validation and rollback

Validation must observe the service that runs the script, not just whether pwsh.exe starts. For each critical automation, record exit code, duration, errors, functional result and external dependencies.

1. Startup with -NoProfile and expected version.
2. Module import under the actual service account.
3. Authentication to required endpoints and resources.
4. Read/write access to required paths and stores.
5. Error handling, exit codes and logging.
6. Scheduled and remote execution, not just interactive execution.
7. Performance within the agreed baseline.

Before changing anything, retain the exact previous package, installation options, modules and configuration. A conventional MSI upgrade can replace the previous version: do not assume rollback is a PATH change. Define the reinstall or image-restore method, any restart impact, observation period and who can approve reversal.

If you need side-by-side comparison of PowerShell 7 builds, a separate ZIP installation can be useful in a lab. Do not turn it into a permanent production mechanism without explicitly managing PATH, tasks, services and updates.

7. Change runbook

8. Primary sources and verification notes

1. Microsoft Learn — PowerShell Support Lifecycle. Support dates, LTS/Stable channels and supported platforms.
2. PowerShell/PowerShell — Release v7.6.10. 10 November 2026 release, official artifacts and hashes.
3. Microsoft Learn — Installing PowerShell on Windows. MSI, MSIX, WinGet, ZIP, upgrades and Windows PowerShell 5.1 coexistence.
4. Microsoft Learn — What's New in PowerShell 7.6. Documented changes, including ThreadJob.
5. PowerShell/PowerShell — Releases. Release history and artifacts.

Document review: 11 November 2026. This is a documentation-reviewed migration framework, not a claim of validation across a production fleet. Test commands in a representative environment before production use.