November 2026 Deadline Looms for PowerShell 7.4 and .NET 8 — How to Avoid a Double Upgrade Scramble

Microsoft has quietly set a shared expiration date that will ripple through Windows automation environments worldwide: November 10, 2026. On that Tuesday, the PowerShell 7.4 LTS release and the .NET 8 runtime both exit support. For the first time since PowerShell became a cross‑platform tool, a major LTS version retires in lockstep with the .NET foundation it was built upon — and that alignment creates a planning opportunity many organizations will overlook if they treat the two events separately.

The date isn’t arbitrary. PowerShell’s Modern Lifecycle Policy ties support directly to the .NET release that powers it. PowerShell 7.4 shipped on .NET 8, so when .NET 8 support ends, PowerShell 7.4 support ends right alongside it. Microsoft confirmed this in its lifecycle documentation, and the latest 7.4.x patch (7.4.17) is already the final full servicing baseline before the cutoff.

For everyday users, the news might feel distant. For system administrators, DevOps engineers, and anyone running scheduled tasks, CI/CD runners, or container images that mix PowerShell 7.4 and .NET 8, the countdown has already begun. Miss the deadline and you’ll be left with unsupported engines that receive no security patches — a compliance headache and a risk nobody wants.

The concrete change: no more updates after November 10, 2026

PowerShell 7.4 was released as a Long Term Servicing (LTS) channel in November 2023, built on .NET 8.0. LTS releases usually enjoy three years of support, but because .NET 8’s support lifecycle ends on November 10, 2026, PowerShell 7.4’s lifecycle is cut short to about three years from its release, regardless of when you installed it. After that date, Microsoft will not issue security fixes, bug patches, or compatibility updates for PowerShell 7.4 — even if you have a support contract. The same rule applies to .NET 8: no more security patches.

What’s still supported? The landscape looks like this today:

Stable releases aren’t LTS; they go out of support roughly six months after the next LTS ships. *PowerShell 7.6.3 is the current LTS, but exact .NET mapping should be verified. Microsoft’s documentation notes it has been tested on .NET’s corresponding LTS.

For most production workloads, the advice from both Microsoft and the community has been to aim for the LTS path: move from 7.4 straight to 7.6, skipping the shorter-lived 7.5 branch. That way you’re on a supported engine with the longest possible runway. If you’re already on 7.5, planning a jump to 7.6 before its support window closes is prudent.

What it means for you — by audience

Home users and tinkerers

If you installed PowerShell 7.4 to run a few personal scripts or to learn, the deadline is forgiving but not trivial. You’ll need to upgrade to a supported version before November 2026. The simplest path: download PowerShell 7.6 LTS and install it alongside your current version; both can coexist. Test your scripts with the new engine, then remove 7.4. Because home users rarely have deep module dependencies or scheduled tasks, the process is usually a one‑afternoon affair. Just be aware that any scripts hard‑coded to pwsh.exe with a specific version path (like C:\Program Files\PowerShell\7\pwsh.exe) will need an edit.

Power users and developers

Developers frequently juggle multiple .NET SDKs and PowerShell versions. The shared end date for .NET 8 and PowerShell 7.4 means your project’s runtime dependencies could expire together. If you’re maintaining an application that targets .NET 8 and also invokes PowerShell automation (for builds, deployment, or tooling), you have a single cutover date to manage — but you must verify that your module dependencies work on the newer .NET runtime that comes with PowerShell 7.6.

Many popular modules from the PowerShell Gallery have already been updated, but some internal or niche modules may rely on .NET 8–specific APIs or libraries. Begin testing now in a non‑production environment: upgrade your development machine to PowerShell 7.6, run your scripts, and pay attention to errors from binary modules or assembly loading failures. The $PSVersionTable variable remains your friend — it reveals the underlying .NET version in use.

IT administrators and ops teams

This is where the real work lives. Servers, jump boxes, runbooks, build agents, container images, golden VM templates, endpoint provisioning packages — PowerShell 7.4 is embedded more deeply than many teams realize. The shared deadline with .NET 8 means a single server might need both a PowerShell engine refresh and an application runtime refresh. Coordinating these changes on the same host without turning it into two separate projects saves bandwidth and avoids configuration drift.

Key pain points:

• Scheduled Tasks and Cron jobs: A task that invokes pwsh.exe might resolve to a version‑specific path. Changing the default pwsh association after an upgrade can break everything. You’ll need a thorough inventory.
• CI/CD runners and agents: Self‑hosted Azure DevOps agents, GitHub Actions runners, or Jenkins nodes often rely on a particular PowerShell version. The same machine may also build .NET 8 applications. A coordinated image update that ships both the later .NET SDK and PowerShell 7.6 keeps the environment predictable.
• Containers: Base images tagging dotnet/runtime:8.0 or mcr.microsoft.com/powershell:lts-7.4 will stop receiving updates after the deadline. You’ll need to rebuild and redeploy.
• Windows PowerShell vs. PowerShell 7: Many enterprises still have a mix of powershell.exe (Windows PowerShell 5.1) and pwsh.exe (PowerShell 7). The end of 7.4 doesn’t touch Windows PowerShell at all — that component gets its lifecycle from Windows itself. But an inventory that conflates the two can leave legacy tasks untouched while ignoring 7.4‑specific duties.

How we got here: the lifecycle link between PowerShell and .NET

When PowerShell 6.0 arrived in 2018, it broke free from Windows and adopted the .NET lifecycle model. The reasoning: PowerShell itself is a .NET application, and its underlying runtime determines what APIs are available, how security patches apply, and which operating systems receive support. The Modern Lifecycle Policy formalized this tie, so every PowerShell release’s end date mirrors the .NET version it’s built on.

This alignment was visible in earlier releases:
- PowerShell 7.0 LTS, built on .NET Core 3.1, supported until December 3, 2022 (matching .NET Core 3.1).
- PowerShell 7.2 LTS, built on .NET 6, supported until November 12, 2024.
- Now, 7.4 LTS pairs with .NET 8 until November 10, 2026.

For administrators who previously upgraded from 5.1 to 7.2 and then to 7.4, the pattern is familiar. But the November 2026 date is notable because it’s the first time a widely‑deployed PowerShell LTS coincides exactly with a .NET LTS that many line‑of‑business applications still use. In the past, PowerShell and application runtimes often fell out of sync, letting teams upgrade one without immediately touching the other. That’s not the case anymore: the combined retirement creates a large surface of dependencies that need attention at the same time.

What to do now: a practical 5‑step migration checklist

1. Inventory every place PowerShell 7.4 runs

Before you change a single binary, know where it’s installed. On Windows, run:

Get-Command pwsh -All

That shows every pwsh.exe on the system’s PATH. Then check each script repository, deployment share, and golden image for hard‑coded paths or version‑specific launchers. Don’t forget to search for #requires -Version 7.4 statements inside .ps1 and .psm1 files — they’ll refuse to run on a newer engine unless you update them.

For scheduled tasks:

Get-ScheduledTask | ForEach-Object {
    $task = $_
    foreach ($action in $task.Actions) {
        if ($action.Execute -match 'pwsh') {
            [PSCustomObject]@{
                TaskName = $task.TaskName
                Path     = $action.Execute
                Arguments = $action.Arguments
            }
        }
    }
} | Export-Csv -Path .\ScheduledTasks.csv -NoTypeInformation

Review the CSV and flag any task that points to C:\Program Files\PowerShell\7\pwsh.exe (the 7.4 default location). After the upgrade, those tasks need to point to the newer engine path, or you can move to using an environment variable or a shim.

Also scan CI/CD pipeline definitions, Dockerfiles, cloud runbooks (Azure Automation, AWS Systems Manager), and Group Policy startup scripts. A single overlooked script can silently continue running on an unsupported engine long after you’ve declared the migration complete.

2. Identify module and dependency gaps

Run this on your current 7.4 host:

Get-InstalledModule | Format-Table Name, Version, Repository

Note which modules are community‑sourced, which are internally developed, and which ship with Windows or third‑party software. Install PowerShell 7.6 side‑by‑side, then attempt to import each critical module. Pay special attention to modules that load native binaries (*.dll): they may need a recompile for the newer .NET runtime. Use Get-Module -ListAvailable to verify the module path and version.

If you encounter failures, check the module’s GitHub repository or support channel. Many popular modules (SqlServer, Az, VMware.PowerCLI) already support 7.6. For in‑house modules, coordinate with your development team to rebuild against the .NET version that ships with 7.6.

3. Test your automation end‑to‑end on the target engine

Testing means more than running a script in a console. Replicate the exact production execution context:
- Use the same service account or managed identity.
- Run as a scheduled task, not interactively.
- If the script uses remote PowerShell (WinRM or SSH), test connectivity and authentication.
- Validate that credential stores, certificates, and environment variables are accessible.
- If your script installs modules on the fly (e.g., Install-PSResource from a feed), ensure the repository is reachable from the target host and that any proxy or firewall rules still work.

A common mistake: testing under an elevated user account that has a full profile, while the actual scheduled task runs under SYSTEM or a service account with a minimal environment. Those differences often surface only in production.

4. Choose your upgrade path and execute

For most, the destination is PowerShell 7.6 LTS. You can install it alongside 7.4 (they’ll live in separate folders) and gradually switch over. Avoid uninstalling 7.4 until all dependencies have been migrated, but don’t keep it around longer than necessary after the deadline — an unsupported engine is a liability.

Update references to pwsh.exe:
- In scheduled tasks, update the Program/script field to the new engine’s full path (e.g., C:\Program Files\PowerShell\7.6\pwsh.exe).
- In CI pipelines, update the task version or the tool installer to grab 7.6.
- For container images, change your base tag to mcr.microsoft.com/powershell:lts-7.6 or a specific version.

If your applications still require .NET 8, you have a harder problem: you may need to run a newer PowerShell engine that uses a later .NET version alongside a .NET 8 application on the same machine. This is technically possible — the .NET runtimes coexist — but test carefully for any side‑effects (e.g., module probing might pick up the wrong assembly). Better yet, plan to migrate the application to a newer .NET LTS (such as .NET 9 or 10, depending on timing) in the same window, eliminating the .NET 8 dependency altogether.

5. Lock in the final supported patch

Schedule your production cutover to include the last security patch before November 10, 2026. Microsoft typically releases updates on Patch Tuesday (second Tuesday of the month). That means the final 7.4 update will likely be October 13, 2026. Verify that your automation is receiving that update (via Windows Update, apt, yum, or your patch management tool) and that all hosts are running the same patch level before declaring the migration complete. After the deadline, any rollback to 7.4 puts you on an unsupported version with no safety net.

What to watch next

Microsoft has signaled that PowerShell 7.6 will be the next long‑term branch, but the exact .NET mapping is still being finalized; early previews align with .NET 10. The community is already discussing whether future LTS releases will again sync with .NET’s cadence — currently a new .NET LTS every two years. If that pattern holds, the next PowerShell LTS after 7.6 might appear in late 2025 and run until around 2028. Keeping an eye on the PowerShell blog and the .NET release schedule will help you avoid another last‑minute scramble. For now, front‑loading the inventory and testing work gives you the widest possible window to catch buried dependencies before they become outages. November 2026 may seem far away, but the effort to track down every engine call, module, and container base is measured in months — not weeks.