PowerShell 7.4 LTS Countdown: Why Bypassing 7.5 Is the Only Smart Move

Microsoft has marked November 10, 2026, as the support finish line for PowerShell 7.4 LTS—and, in a scheduling twist that will shape every migration plan, the non-LTS 7.5 release reaches end of life on the exact same day. The upshot is clear: moving from 7.4 to 7.5 buys you zero extra time. The only supported path forward after that date is PowerShell 7.6 LTS, which launched on March 18, 2026, and remains supported until November 14, 2028.

That shared deadline transforms what could have been a routine upgrade into a hard pivot. Organizations that still rely on PowerShell 7.4 for automation, scheduled tasks, or CI/CD pipelines now have a fixed window to inventory every execution point, test workloads against the newer runtime, and complete the cutover—or accept that their scripts will continue running without security patches after November 2026.

Here’s exactly what changed, who it affects, and the practical steps to get to the other side without breaking production.

The Support Calendar That Forced a Fork

PowerShell follows the lifecycle policy of the .NET version it’s built on. PowerShell 7.4 LTS shipped with .NET 8, whose support ends November 10, 2026, according to Microsoft’s public lifecycle documentation. PowerShell 7.5, a non-LTS release issued in April 2025, also rides on .NET 8—meaning it inherited the same end date.

PowerShell 7.6 LTS, by contrast, is built on .NET 10, which Microsoft supports through November 2028. The 7.6 release itself gets an extra 14-day grace period, pushing its official PowerShell support cutoff to November 14, 2028. That gives organizations almost exactly two years of headroom from November 2026 to plan the next upgrade.

For anyone still on PowerShell 7.4, the timeline looks like this:

The takeaway is not subtle: PowerShell 7.5 was always a short-lived stepping stone. It exists to preview features that will land in the next LTS, but it was never designed to extend security coverage beyond .NET 8. Organizations that invested time testing or deploying 7.5 now face the same cliff.

Who This Actually Affects

Home users and tinkerers who run PowerShell locally will see little disruption. They can install PowerShell 7.6 from the official GitHub releases or via winget whenever they choose. The November 2026 date is a soft deadline for them: no new security updates, but the shell will keep working.

System administrators and IT pros managing fleets of servers face a much harder problem. PowerShell 7.4 often lives inside scheduled tasks, service wrappers, configuration management agents, and remote session configurations. Every one of those touchpoints points to a specific executable path—typically pwsh.exe. Swapping the version on disk doesn’t automatically redirect those paths. A missed task can silently revert to a stale copy, leaving critical automation unpatched.

Developers and DevOps engineers who build modules or maintain CI/CD definitions need to test compatibility with .NET 10. The runtime change from .NET 8 to 10 is not just a binary replacement; it alters garbage collection, cryptography defaults, and native interop. A module that imports cleanly in 7.6 might still fail at runtime under load or with specific parameters. Microsoft’s own migration guidance warns that behavioral differences can emerge even in scripts that parse correctly.

Vendor-supported applications that embed PowerShell add another layer. If a backup agent or monitoring service hardcodes a call to a 7.4 executable, upgrading that host’s PowerShell won’t change what the application actually executes. These dependencies must be inventoried separately and, in many cases, remediated through vendor updates rather than internal scripting.

How We Arrived at Two Parallel Deadlines

PowerShell’s versioning and support model has evolved significantly since the 2016 open-source rebirth. The move to .NET Core—and later .NET 5/6/8—tied the shell’s lifecycle directly to the platform’s support calendar. Microsoft committed to an LTS release cadence roughly every two years, each one riding on a corresponding .NET LTS.

That alignment has been generally smooth. Windows PowerShell 5.1 remains a built-in component of Windows and follows the OS lifecycle, but it is frozen in time. All new development goes into the cross-platform PowerShell (version 7 and later). Administrators have been encouraged to use pwsh.exe for new automation while keeping powershell.exe for legacy dependencies only.

The surprise in this cycle is the overlapping end dates. Normally, a non-LTS release like 7.5 would outlive the previous LTS by a few months, giving teams a buffer. But .NET 8’s support term—and Microsoft’s decision not to extend 7.5 beyond that term—closed that gap. The result is a binary choice: either you move to 7.6 LTS, or you run without security updates.

There is no option to “stay on 7.4 and patch it yourself.” Microsoft does not supply out-of-band fixes for unsupported versions, and .NET 8 itself will stop receiving critical Common Vulnerabilities and Exposures (CVE) remediations after November 2026. An attacker finding a new remote code execution bug in .NET 8 after that date would have an open target on any system still running PowerShell 7.4 or 7.5.

Action Plan: Inventory, Test, Deploy, Cut Over

A safe migration starts long before anyone touches a server. The process breaks into four phases, and the most important rule is: never assume that installing a new PowerShell version on your laptop tells you anything about what will happen on an automation host.

1. Inventory every execution point. You need to know which version of PowerShell runs where—and from which exact path. Many environments have a mix of pwsh.exe and powershell.exe calls, often buried in scheduled tasks, service definitions, and CI/CD YAML files. Don’t trust the PATH environment variable; record absolute paths. Use PowerShell itself to find them:

• Enumerate tasks with Get-ScheduledTask and filter actions that call powershell or pwsh.
• Check services via Get-CimInstance Win32_Service and look for those binaries in the PathName.
• Scan your automation repositories for shebang lines, #requires -Version statements, and explicit executable references.

For each discovery, note whether the workload currently relies on 7.4, 7.5, or Windows PowerShell 5.1. The 5.1 instances don’t need to move, but they should be documented with an owner and a justification.

2. Test workloads directly on PowerShell 7.6. Install the new shell—ideally through your organization’s normal software deployment channel—without altering any production schedules or job definitions. Then clone a representative job, point the clone at pwsh.exe from the 7.6 installation, and run it with the same service account, identity, and environment variables the real job uses.

Do not rely on syntax checks or successful module imports. Run the entire workload, including credential retrieval, network hops, remoting, and any downstream parsers. Compare output objects, log files, and system state against a 7.4 baseline. If the workload passes, it’s a candidate for migration. If it fails, dig into the failure: is a module missing its binary dependency? Is a native command producing a different exit code under .NET 10? Is a compatibility shim needed?

Microsoft’s migration guidance specifically addresses common pitfalls when moving from Windows PowerShell 5.1 to 7, but many of those apply here too. Watch for modules marked only for “Desktop” edition, scripts that use Add-PSSnapin, and any dependency on -UseWindowsPowerShell compatibility mode. That mode can bridge a gap but is not a guarantee—test every command the workload actually invokes.

3. Deploy PowerShell 7.6 methodically. Once testing is underway, roll out the new version through your approved software management process. After each installation, open a terminal and run pwsh.exe -NoProfile -Command '$PSVersionTable' to verify the PSVersion, PSEdition (must be Core), and the executable path. Confirm that no silent overwrites have occurred; some package managers install side-by-side, others replace the existing pwsh.exe.

4. Execute a controlled cutover. Migrate jobs in priority order, one group at a time. For each group:

• Update the task action, pipeline definition, or runner configuration to point to the 7.6 executable.
• Run the job with production-equivalent permissions and monitor it through a full validation cycle.
• Keep the original 7.4 definition intact and ready to restore. Do not uninstall PowerShell 7.4 from a server until all its workloads have migrated or received time-limited exceptions.

After each group, compare logs and output with the pre-migration baseline. If something breaks, the fallback is immediate: revert the definition to the 7.4 executable and investigate the module, host, or runtime dependency.

What About Windows PowerShell 5.1?

Windows PowerShell 5.1 remains a built-in component, and its support is tied to the Windows version on which it runs. Do not remove or alter 5.1 simply to force workloads onto 7.6. The goal is not to eliminate powershell.exe but to ensure that every active workload points to a supported engine. 5.1 should be reserved for documented, owned exceptions—legacy scripts that cannot yet be refactored, vendor tools that hardcode the old engine, or system components that require Add-PSSnapin.

For everything else, the executable of choice should be pwsh.exe. The November 2026 deadline applies only to the cross-platform PowerShell releases; 5.1 will keep receiving patches as long as the underlying Windows OS does.

Common Missteps to Avoid

Assuming 7.5 gets you more time. It doesn’t. A workload migrated to 7.5 today must be migrated again before November 2026. The only exception is if a critical software dependency explicitly requires 7.5—in which case you document it and treat it as a temporary waypoint, not a destination.

Swapping the executable in the task action and walking away. This is the root cause of many “mysterious failure” weekends. Test under the real execution context: non-interactive, with the same environment variables, proxy settings, and certificate stores. A script that runs flawlessly in your terminal may fail when launched by Task Scheduler under a different account.

Skipping module inventories. The module that works today in 7.4 may depend on a .NET 8 library that has no .NET 10 equivalent. Run Get-Module -ListAvailable in both the 7.4 and 7.6 environments, export the results to CSV, and compare. Any module marked only for Desktop edition, or whose vendor has no documented 7.6 support, needs investigation before its dependent workloads can be migrated.

Treating container images as afterthoughts. If you run PowerShell inside Docker or Kubernetes, update the image base to one that ships 7.6. Microsoft provides official images at mcr.microsoft.com/powershell; retagging your deployment to the latest LTS image is a good start, but you must still test that your scripts behave identically inside that container.

Outlook: Two Years of Stability, Then Another Leap

The move to 7.6 LTS buys breathing room until late 2028, but it also sets a precedent. Each future LTS release is likely to follow a similar cadence: roughly two years of production support, possibly with a non-LTS preview that shares the same end date. Organizations that embed PowerShell into critical paths should treat every LTS as a two-year migration clock, not a permanent fixture.

One near-term watchpoint: .NET 10 itself reaches end of support in November 2028, so the 14-day PowerShell extension is minimal. When Microsoft begins discussing PowerShell 7.8 LTS (expected around 2028 on .NET 12), the same planning discipline will apply.

For now, the task is clear. Inventory everything. Test on 7.6 directly. Leave 7.5 on the sidelines unless a vendor forces your hand. And start before the summer of 2026, because November 10 will arrive faster than any administrator wants.