PowerShell 7.4 Support Ends Nov. 10, 2026: Move to 7.6 LTS

Most production automation running PowerShell 7.4 should be tested directly on PowerShell 7.6 LTS before November 10, 2026—not moved to PowerShell 7.5, which reaches end of support on the same date. Use pwsh.exe for PowerShell 7 workloads and powershell.exe for Windows PowerShell 5.1 exceptions; verify the executable in every task, service, and pipeline before changing it.

Why November 10 Is a Dependency Deadline​

PowerShell 7.4 LTS, released November 16, 2023 on.NET 8, reaches end of support on November 10, 2026. PowerShell 7.5 reaches end of support that same day, so moving from 7.4 to 7.5 does not extend the support window. PowerShell 7.6 LTS, released March 18, 2026 on.NET 10, is supported through November 14, 2028, while.NET 10 is supported through November 2028. These dates come from Microsoft’s PowerShell support lifecycle and.NET support policy.
That makes the practical decision tree straightforward:

1. A workload runs on PowerShell 7.4: Test it on 7.6.
2. A dependency explicitly requires 7.5: Use 7.5 only for that documented requirement, not for additional lifecycle coverage.
3. A workload fails on 7.6 but still runs in Windows PowerShell 5.1: Keep its existing powershell.exe execution path as a documented exception while investigating replacement or remediation.
4. The execution host controls the shell: Inventory and test that host separately rather than assuming a workstation installation changes it.

Windows PowerShell 5.1 follows the lifecycle of the Windows version on which it is installed, according to Microsoft’s PowerShell lifecycle documentation. That is different from treating it as the preferred destination for new automation.
This distinction matters in the broader retirement of older PowerShell technology. WindowsForum’s reports on the PowerShell 2.0 phaseout describe a long-signaled removal that affects legacy scripts and Windows features rather than merely changing a command-line preference. Its coverage of PowerShell 7.6 also highlights packaging and release-engineering complexity, reinforcing why administrators should begin validation before the support deadline rather than plan a last-minute executable swap.

Inventory PowerShell Before Changing Production​

Use this decision-tree-led checklist on representative workstations, servers, and automation hosts.

1. Identify the engine used by each workload​

Record installed commands:

Get-Command powershell.exe, pwsh.exe -All -ErrorAction SilentlyContinue |
 Select-Object Name, Version, Source

Query each available engine directly:

powershell.exe -NoProfile -Command '$PSVersionTable'
pwsh.exe -NoProfile -Command '$PSVersionTable'

Do not rely only on PATH. Record the complete executable path used by production tasks.

2. Find scheduled tasks that call PowerShell​

Get-ScheduledTask | ForEach-Object {
 $task = $_

 foreach ($action in $task.Actions) {
 if ($action.Execute -match '(?i)(powershell|pwsh)(\.exe)?$') {
 [pscustomobject]@{
 TaskPath = $task.TaskPath
 TaskName = $task.TaskName
 Execute = $action.Execute
 Arguments = $action.Arguments
 }
 }
 }
} | Format-Table -AutoSize

For each result, decide:

• pwsh.exe running 7.4: schedule a 7.6 test.
• pwsh.exe running 7.5: document the dependency or schedule a 7.6 test.
• powershell.exe: determine whether 5.1 is genuinely required before changing it.
• Fixed executable path: preserve that path in rollback records.

Review script paths, working directories, profiles, encoded commands, and execution-policy arguments.

3. Check services​

Get-CimInstance Win32_Service |
 Where-Object PathName -Match '(?i)(powershell|pwsh)(\.exe)?' |
 Select-Object Name, State, StartName, PathName

This finds direct references. A service can also call a wrapper that launches PowerShell later, so verify the product’s configuration and logs where applicable.

4. Scan automation repositories​

Set $Root to a repository or automation share:

$Root = 'C:\Automation'

Get-ChildItem $Root -Recurse -File -Include *.ps1,*.psm1,*.psd1 |
 Select-String -Pattern @(
 '#requires\s+-Version',
 'powershell\.exe',
 'pwsh\.exe',
 'Add-PSSnapin',
 'Import-Module',
 '\bworkflow\b',
 'WindowsPowerShell'
 ) |
 Select-Object Path, LineNumber, Line

Search pipeline and deployment definitions too:

Get-ChildItem $Root -Recurse -File -Include *.yml,*.yaml,*.json,*.xml |
 Select-String -Pattern @(
 'powershell',
 'pwsh',
 'mcr\.microsoft\.com/powershell',
 '\.ps1'
 ) |
 Select-Object Path, LineNumber, Line

Matches are investigation leads, not proof of incompatibility. Prioritize entries that explicitly launch an engine or import a critical module.

5. Export module inventories​

Run this in each engine currently used by production:

Get-Module -ListAvailable |
 Sort-Object Name, Version -Unique |
 Select-Object Name, Version, Path, CompatiblePSEditions |
 Export-Csv ".\PowerShell-Modules-$($PSVersionTable.PSEdition).csv" -NoTypeInformation

Use the following compatibility matrix to direct testing:

Finding	Decision
Module imports and passes tests in 7.6	Candidate for migration
Module vendor documents 7.6 support	Validate in your environment, then migrate
Module is marked only for Desktop	Investigate before migration
Script uses Add-PSSnapin or workflow	Treat as a redesign candidate
Private binary module has no current owner	Assign ownership and test before cutover
Module works only through a compatibility mechanism	Keep as an exception until behavior and vendor support are confirmed

Microsoft documents important behavioral and feature differences in Migrating from Windows PowerShell 5.1 to PowerShell 7. Use that guidance to evaluate particular modules instead of assuming every Windows-oriented module is incompatible.

Deploy PowerShell 7.6 Through an Approved Method​

Use Microsoft’s official PowerShell installation guidance for Windows to select a supported installation method, then distribute the approved package through your organization’s software-management process.
This avoids assuming that a particular package manager, package identifier, installer type, or server configuration is available throughout the estate.
After deployment, open a new terminal and verify the intended executable:
pwsh.exe -NoProfile -Command '$PSVersionTable'
Confirm that:

• PSVersion reports the approved 7.6 release.
• PSEdition reports Core.
• The path matches the executable that scheduled tasks and services will use.
• Production jobs have not changed merely because the interactive shell changed.

Test the Runtime Change, Not Just Syntax​

Moving from PowerShell 7.4 to 7.6 also changes the underlying runtime from.NET 8 to.NET 10, as shown in Microsoft’s PowerShell support lifecycle table. Parsing a script successfully is therefore not enough.
For each workload:

1. Start 7.6 without profiles:

pwsh.exe -NoLogo -NoProfile

1. Import every required module explicitly:

Import-Module ModuleName -ErrorAction Stop

1. Run read-only operations or use a test environment first.
2. Capture errors, warnings, native-command exit codes, and output files.
3. Test under the real service account, scheduled-task identity, or automation agent.
4. Exercise credential access, network paths, remoting, proxies, certificates, APIs, and downstream parsers used by the complete job.
5. Compare resulting objects, files, logs, and system state with the 7.4 baseline.

If Microsoft’s migration guidance or the module vendor recommends Windows PowerShell compatibility, it can be evaluated with:
Import-Module ModuleName -UseWindowsPowerShell
Treat a successful import as a test result, not as proof of complete compatibility. Validate every command the workload actually uses and obtain vendor support guidance where the module is business-critical.

Check Every Execution Host Once​

Maintain one inventory covering:

• Administrator endpoints and jump servers
• Scheduled-task and service hosts
• CI/CD agents and self-hosted runners
• Automation platforms and managed runbook services
• Configuration-management systems
• Container definitions
• Remote session configurations
• Applications or vendor products that invoke PowerShell

For each host, record the engine, full executable path, version, owner, workload, modules, test result, and rollback method. The governing principle is simple: changing PowerShell on an administrator’s computer does not prove that another execution host changed.

Use a Controlled Cutover​

Migrate in exact, reversible stages:

1. Deploy PowerShell 7.6 without changing production job definitions.
2. Clone a representative job or create a non-production schedule.
3. Point only the clone to the verified 7.6 executable.
4. Run it with production-equivalent identity and permissions.
5. Compare logs, output, exit codes, and resulting state.
6. Migrate jobs in groups based on business impact.
7. Monitor each group through an agreed validation period.
8. Preserve the previous task action, pipeline definition, and executable path until validation ends.

If a job fails, restore its prior definition and investigate the module, host, identity, or runtime dependency. Do not remove PowerShell 7.4 until its workloads have migrated or received approved, time-limited exceptions.
Retained Windows PowerShell 5.1 workloads should have an owner, host, dependency, business justification, and replacement plan. WindowsForum’s PowerShell 2.0 retirement coverage shows why this documentation matters: legacy engines can remain embedded in automation for years when no one owns the migration.

Troubleshooting Failed Migrations​

Use the failure point to narrow the investigation:

• pwsh.exe is not found: Verify installation, the complete executable path, and the account’s environment.
• The wrong version launches: Check task actions, service command lines, runner configuration, aliases, and PATH order.
• A module is missing: Compare module inventories and follow the module publisher’s installation instructions.
• A module will not import: Check CompatiblePSEditions, binary dependencies, vendor support, and Microsoft’s migration guidance.
• Interactive testing succeeds but automation fails: Test with the actual identity, working directory, environment variables, and noninteractive settings.
• Output changed: Compare object properties and exported formats rather than checking only whether the command completed.
• A native program fails: Record $LASTEXITCODE, architecture, arguments, quoting, environment, and working directory.

Frequently Asked Questions​

Does upgrading from PowerShell 7.4 to 7.5 buy more support time?​

No. Both reach end of support on November 10, 2026. PowerShell 7.6 LTS is supported through November 14, 2028, according to Microsoft’s PowerShell support lifecycle.

Must Windows PowerShell 5.1 be removed when adopting 7.6?​

No migration plan should remove or alter 5.1 merely to force workloads onto 7.6. Use pwsh.exe for validated PowerShell 7.6 automation and retain powershell.exe only for documented Windows PowerShell dependencies. Follow Microsoft’s Windows and PowerShell servicing guidance before changing an operating-system component.

Will installing.NET 10 automatically migrate PowerShell 7.4?​

No. Treat the PowerShell deployment and each workload cutover as explicit tasks. Verify the executable and version used by every host.

Can an application remain on PowerShell 7.4 after November 10, 2026?​

It may still launch, but it will be outside Microsoft’s support window. Document and isolate any temporary exception, apply available servicing updates, assign an owner, and prioritize migration.
The safe plan is to deploy 7.6 through an approved method, test every 7.4 workload directly on it, skip 7.5 unless a dependency specifically requires it, and retain Windows PowerShell 5.1 only as an owned and documented exception.

---

References​

1. Primary source: learn.microsoft.com
   
   

   PowerShell - Microsoft Lifecycle | Microsoft Learn

   PowerShell follows the Modern Lifecycle Policy.

   learn.microsoft.com
2. Independent coverage: github.com
   
   

   Releases · PowerShell/PowerShell · GitHub

   PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

   github.com
3. Primary source: WindowsForum
   
   

   PowerShell 2.0 Retirement in Windows 11: What Admins Need to Know | Windows Forum

   For more than a decade, PowerShell 2.0 has lingered as a legacy artifact in the Windows ecosystem. Now, Microsoft is finally drawing the curtain on what was...

   windowsforum.com

 

[ChatGPT]

PowerShell 7.4 should be treated as part of a coordinated .NET 8 exit plan, not as an isolated scripting upgrade: both reach end of support on November 10, 2026. Organizations should begin inventorying PowerShell hosts, scripts, modules, build agents, containers, and .NET 8 applications now, then test the supported replacement runtime and PowerShell engine together wherever they share packaging, automation, or security dependencies.
Microsoft’s lifecycle policy ties PowerShell support to the lifecycle of the .NET version on which a PowerShell release is built. Microsoft lists .NET 8 support through November 10, 2026, and its 2026 end-of-support notice identifies that date as the cutoff. That makes the PowerShell 7.4 deadline more than a reminder to update pwsh.exe: it is a common deadline for systems that may have been budgeted, staffed, and tested separately.

November 10 Is One Date, but It Can Create Two Projects​

A typical enterprise may have a PowerShell 7.4 estate owned by infrastructure teams and a .NET 8 application estate owned by development teams. On paper, those look like distinct programs. In practice, they often converge on the same Windows servers, CI runners, container images, deployment packages, authentication modules, artifact feeds, and endpoint-security policies.
That overlap is where organizations can waste time. A team might certify an automation script under a newer PowerShell release while a separate application team refreshes the same server image for a later .NET runtime. Both teams can repeat compatibility testing, alter the same build pipeline, and inadvertently deploy mismatched dependencies.
The better planning assumption is simple: if a workload contains PowerShell 7.4, .NET 8, or both, put it on one November 2026 transition register. That register can still assign separate owners, but it should expose shared hosts and shared delivery paths before each team independently changes them.
This also matters because “PowerShell” does not identify one engine. Windows PowerShell 5.1 and PowerShell 7 are separate products. A task launched by powershell.exe remains a Windows PowerShell task; installing or testing PowerShell 7 does not silently move it to pwsh.exe. That distinction is central to any inventory exercise and has become more important as legacy PowerShell components are removed from newer Windows environments.

---

Start With an Inventory That Finds the Actual Execution Path​

The first job is not upgrading binaries. It is discovering what launches automation, which executable it calls, which modules it imports, and what runtime or operating environment surrounds it.
On an interactive PowerShell 7.4 host, begin with these commands:

$PSVersionTable
Get-Command pwsh -All
Get-Command powershell -All
Get-Module -ListAvailable | Sort-Object Name, Version
Get-InstalledPSResource

$PSVersionTable identifies the current engine and runtime information for the session. Get-Command helps uncover whether both pwsh.exe and powershell.exe are present and where they resolve. The module commands provide a starting view of available and installed PowerShell resources, but they do not prove that every script uses only those modules.
Next, search repositories and deployment shares for explicit engine calls and version assumptions:

Get-ChildItem -Path C:\Scripts -Recurse -File -Include *.ps1,*.psm1,*.psd1 |
    Select-String -Pattern 'powershell\.exe|pwsh\.exe|#requires|Import-Module|Install-Module|Install-PSResource'

Change C:\Scripts to each managed script location. This search is deliberately broad: the immediate goal is to find scripts that force Windows PowerShell, force PowerShell 7, declare requirements, or install dependencies dynamically. Dynamic installation is especially important because it can turn a successful test into a failed production job when a repository, proxy rule, package version, or module dependency changes.
Scheduled tasks are another common blind spot. Review registered tasks and inspect their actions rather than assuming the operating system’s default association tells the story:

Get-ScheduledTask |
    ForEach-Object {
        $task = $_
        foreach ($action in $task.Actions) {
            [PSCustomObject]@{
                TaskName = $task.TaskName
                TaskPath = $task.TaskPath
                Execute  = $action.Execute
                Arguments = $action.Arguments
            }
        }
    } |
    Where-Object { $_.Execute -match 'powershell|pwsh' } |
    Format-Table -AutoSize

For each result, record the executable path, arguments, service account, script location, schedule, target systems, required modules, and rollback method. A task that calls powershell.exe is not covered by PowerShell 7.4 testing. A task that calls pwsh.exe without a full path may behave differently after a host rebuild or PATH change.
The same review should cover:

• CI runners and release agents that execute scripts during builds, tests, packaging, or deployment.
• Container definitions and base images that install PowerShell or .NET as part of image construction.
• Azure Automation runbooks and hybrid-worker arrangements that depend on a particular PowerShell environment or imported module.
• Installer packages, bootstrapper scripts, endpoint-management packages, and login scripts that carry their own assumptions about available executables.
• Server build templates and golden images that may be replicated long after their original runtime selection was forgotten.

This is the point where a runtime transition stops being theoretical. A single old container base, self-hosted runner, or scheduled task can preserve PowerShell 7.4 or .NET 8 long after desktop and server administrators believe the organization has moved on.

Put Each Workload Into a Migration Decision Matrix​

Not every script needs the same path, but every script needs an explicit decision. The useful choices are not “upgrade” or “do nothing”; they are a controlled move to a supported PowerShell and runtime combination, a compatibility test where the execution environment is intentionally retained, or a planned redesign for a dependency that cannot make the move.

Workload condition	Recommended action before November 2026
PowerShell 7.4 script runs beside a .NET 8 application or deployment tool.	Test both on the target supported runtime baseline in the same build, image, or server-validation process.
PowerShell 7.4 script is standalone but imports business-critical modules.	Test the script and its exact module set directly under the intended supported PowerShell release.
A job invokes powershell.exe rather than pwsh.exe.	Treat it as Windows PowerShell 5.1 work, document the engine deliberately, and do not count it as migrated merely because PowerShell 7 is installed.
A script depends on an older module, binary tool, or installer behavior.	Build a compatibility test case before changing production hosts; do not rely on syntax review alone.
A build runner or container image installs .NET 8 and PowerShell 7.4.	Replace and validate the entire image or runner baseline, including restore, build, test, packaging, and deployment stages.

The destination should be selected around support and compatibility, not around the smallest visible version change. WindowsForum’s earlier coverage has pointed production automation users toward testing directly on PowerShell 7.6 LTS rather than making an intermediate move that creates another near-term lifecycle decision. The key is to validate the intended long-lived target in the environment where the script actually runs.
For .NET-hosted applications, development teams should make the equivalent decision on their supported runtime baseline. The PowerShell and application paths do not have to be technically identical, but the testing calendar should be shared when both workloads depend on the same host image, installer, container, build runner, or deployment pipeline.

---

Module Compatibility Is the Migration’s Real Center of Gravity​

PowerShell syntax is often not the hard part. The difficult failures tend to come from modules, native executables, remoting configurations, authentication libraries, package providers, and assumptions embedded in deployment wrappers.
A script may look portable because it uses standard cmdlets, while importing a module that loads a binary component or calls an external tool during execution. Another script may succeed on an administrator’s workstation but fail under a scheduled-task account that has a different module path, repository configuration, certificate store, proxy policy, or profile behavior.
Treat the following as test evidence, not informal checks:

1. Run the script under the exact target engine using the same account type and execution method as production.
2. Import every required module at the intended versions before the functional test begins.
3. Test noninteractive execution, because scheduled tasks and CI jobs do not have an administrator at a console to resolve prompts or credential issues.
4. Test installation and deployment paths, not only script output, when the automation produces installers, packages, images, or application releases.
5. Record the target executable explicitly in task definitions, runner configuration, and operational documentation.

The last item is easily overlooked. Ambiguous calls such as pwsh or powershell may work today because of PATH order or a manually installed executable. Using a managed, expected executable path and documenting it makes host rebuilds less surprising.

The Cutoff Is Also a Patch-Management Deadline​

End of support is not a license expiration date; existing workloads may continue to launch after November 10, 2026. The operational problem is that they will no longer be on a supported servicing path, leaving organizations to carry the security, compliance, and troubleshooting consequences themselves.
That makes the final supported patch cycle important. Do not schedule validation for the week before the deadline and call the project complete after a successful lab test. The production cutover should include the final supported updates available before the cutoff, followed by a confirmation that the real scheduled tasks, runners, containers, and applications use the intended versions.
There is also a timing mismatch to manage. Application teams may be accustomed to runtime upgrades driven by release planning, while infrastructure teams may treat PowerShell changes as workstation or server-tooling maintenance. November 2026 forces those schedules together. The teams do not need identical change windows, but they need a common record of affected assets and a common definition of “migrated.”

Frequently Asked Questions​

Does installing PowerShell 7.6 automatically upgrade Windows PowerShell 5.1 scripts?​

No. Windows PowerShell 5.1 and PowerShell 7 are distinct engines. Scripts or tasks that explicitly invoke powershell.exe will continue using Windows PowerShell unless their launch command is changed.

Can we wait until November 2026 to begin testing?​

That is risky. Inventory and compatibility testing take time because scripts can depend on modules, runners, containers, installers, and service-account behavior that are not visible in a simple version check.

Is this only a PowerShell 7.4 problem?​

No. The November 10, 2026 date aligns with .NET 8 end of support, so organizations should look for connected application and automation dependencies rather than manage the events as unrelated projects.

What counts as a successful migration?​

A successful migration means the real production launch path has been tested on the intended supported baseline, including its modules, credentials, task scheduler or runner configuration, packaging behavior, and final supported patch level.
The practical deadline is November 10, 2026, but the planning deadline is much earlier: the point when an organization can still discover a buried task, image, module, or build dependency without turning remediation into an outage. Teams that build one inventory for PowerShell 7.4 and .NET 8 now will have a cleaner upgrade path—and fewer surprises when support for both reaches its end.

---

References​

1. Primary source: learn.microsoft.com
   
   

   PowerShell Support Lifecycle - PowerShell | Microsoft Learn

   Details the policies governing support for PowerShell.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   PowerShell 7.4 Support Ends Nov. 10, 2026: Move to 7.6 LTS | Windows Forum

   Most production automation running PowerShell 7.4 should be tested directly on PowerShell 7.6 LTS before November 10, 2026—not moved to PowerShell 7.5...

   windowsforum.com