PowerShell 7 is the cross-platform, .NET-based successor to Windows PowerShell 5.1. The most important recent changes are not new aliases or cosmetic shell tweaks: PowerShell 7.4 made native-command byte streams and Windows argument passing mainstream, 7.5 added explicit CLI-XML conversion commands and broader completion, and the 7.6 LTS line moves to .NET 10 while promoting several experimental features to supported behavior.
Whether you should upgrade depends on your scripts and modules. Check the .NET/runtime line, native-command argument and encoding behavior, module versions, installer behavior, and the documented breaking changes—not just whether a command exists in both shells.
As an Amazon Associate I earn from qualifying purchases.
PowerShell 7 at a glance
PowerShell 7 is a separate product line from Windows PowerShell 5.1. It runs on modern .NET and targets Windows, macOS and Linux, so compatibility is determined by both the operating system and the .NET runtime underneath it. A script that works in Windows PowerShell 5.1 can still need changes when it crosses platforms, invokes a native executable, loads a Windows-only module or relies on older JSON and remoting behavior.
| PowerShell release | Runtime line | Notable additions | Important qualification |
|---|---|---|---|
| 7.4 (LTS) | .NET 8; current servicing line noted on .NET 8.0.31 | Native byte-stream preservation, Windows native-argument passing, ProgressAction, updated JSON-schema engine |
Some formerly experimental native-command features became mainstream |
| 7.5 | .NET 9; PowerShell 7.5.11 is built on .NET 9.0.20 | ConvertTo-CliXml, ConvertFrom-CliXml, richer tab completion, web-cmdlet fixes, numeric BigInteger JSON |
Introduces breaking defaults and restricted-remoting help changes |
| 7.6 (LTS line) | .NET 10; PowerShell 7.6.6 is built on .NET 10.0.12 | PSResourceGet 1.2.0, PSReadLine 2.4.5, ThreadJob 2.2.0, promoted experimental features | Module-qualified ThreadJob calls may need a new module name |
The patch numbers above identify the builds documented in Microsoft’s release notes; they are not claims that every operating system receives an identical package on the same day.
#1 Best Overall
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
What is new in PowerShell 7.6
A .NET 10 LTS foundation
Microsoft documents PowerShell 7.6.6 as built on the .NET 10.0.12 runtime. For organizations standardizing on a long-term-support runtime, this is the major architectural change from the 7.5 line. Runtime support matters to compiled modules, cryptography, networking, file-system behavior and platform integration, so test the modules your automation actually loads rather than assuming a version-number change is risk-free.
Updated modules ship with the release
The 7.6 bundle includes Microsoft.PowerShell.PSResourceGet 1.2.0, PSReadLine 2.4.5 and Microsoft.PowerShell.ThreadJob 2.2.0. These versions affect package management, interactive editing and background work even when your own script contains no new 7.6 syntax.
The ThreadJob module rename is the migration detail most likely to break an otherwise working script. The Microsoft.PowerShell.ThreadJob module replaces the older ThreadJob module. If a script uses a module-qualified command, change it to Microsoft.PowerShell.ThreadJobStart-ThreadJob. Review module-qualified imports and command invocations in scheduled tasks, profiles and deployment scripts.
Experimental features promoted to mainstream
Four capabilities moved from experimental status into the normal 7.6 experience:
- PSFeedbackProvider replaces the hard-coded suggestion framework and provides feedback formatting properties through
$PSStyle.Formatting. - PSNativeWindowsTildeExpansion improves tilde expansion when Windows native commands receive paths.
- PSRedirectToVariable enables redirection to a variable.
- PSSubsystemPluginModel becomes part of the supported feature set for subsystem integration.
Promotion means these features no longer require an experimental-feature opt-in in the 7.6 line. If you previously enabled them manually, remove that workaround and retest profile code that changes feedback formatting or native path handling.
New experimental work in 7.6
PowerShell 7.6 also introduces two experimental features: PSSerializeJSONLongEnumAsNumber and PSProfileDSCResource. Experimental features can change before a later release, so avoid making production output formats or deployment contracts depend on them without an explicit compatibility plan.
macOS packaging
The macOS PKG for 7.6 is notarized and signed by Microsoft. That improves the trust and installation path on macOS, but it does not remove the need to check your operating system version, execution policy and locally installed modules.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsWhat is new in PowerShell 7.5
Explicit CLI-XML conversion cmdlets
PowerShell 7.5 adds ConvertTo-CliXml and ConvertFrom-CliXml. They make the shell’s CLI-XML serialization format available through named commands instead of requiring a less obvious serialization workflow. This is useful when a script must persist PowerShell object data, exchange it with another PowerShell process or make the conversion step visible during code review.
Rank #3
CLI-XML is PowerShell’s object serialization format, not general-purpose JSON or a language-neutral data contract. Treat deserialized values as data snapshots: methods and live provider connections do not survive serialization in the same way as the original object.
Broader and more accurate tab completion
Completion in 7.5 adds more type inference and argument completers. Microsoft specifically calls out completion scenarios for -Verb, -Scope, -Module and -Version. The practical effect is less manual typing when discovering commands, modules and versioned package operations. Completion quality still depends on the command’s metadata and the modules installed on that machine.
Web-cmdlet behavior is more predictable
Web cmdlets improve the combination of -PassThru and -OutFile. Responses expose an OutFile property, verbose output reports filenames more consistently, and fixes address request body/content-type handling and resume-size behavior. If a download script examines the returned object, logs the destination or resumes interrupted transfers, retest it on 7.5 rather than relying on output observed under 7.3 or earlier.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
BigInteger values serialize as JSON numbers
ConvertTo-Json now serializes .NET BigInteger values as JSON numbers. Consumers that previously received a quoted value may need schema or parsing adjustments. Check both sides of an API or file exchange: JSON parsers differ in how safely they represent integers larger than their native numeric range.
7.5 changes that can break automation
- File catalogs: the default
New-FileCatalog -CatalogVersionis now 2. Scripts that compare catalog formats or validate a fixed version should set the parameter explicitly. - Restricted remoting: help retrieval from network locations is blocked in restricted remoting sessions. A command that previously fetched remote help may now return no network content; provide local help or change the remoting policy deliberately.
- Windows installer memory: the installer remembers previous installation options for the next installation. On managed machines, verify the remembered choices before accepting an upgrade.
What changed in PowerShell 7.4 LTS
Native byte streams stay bytes
PowerShell 7.4 makes PSNativeCommandPreserveBytePipe mainstream. Redirecting native-command standard output to a file or piping bytes to a native command can now preserve the byte stream instead of forcing text-oriented PowerShell processing. This matters for compressed data, images, archives, cryptographic material and any protocol where a single byte changed is a corruption.
Audit scripts that combine commands such as a compiler, archiver, media tool or database client with PowerShell redirection. Decide whether the next command expects bytes or text, and test the result on each target platform because native utilities and encodings remain platform-dependent.
Windows native-command argument passing
PSWindowsNativeCommandArgPassing also became mainstream. It changes how PowerShell constructs the argument list sent to Windows native executables. Quoting, embedded spaces, empty strings, wildcard characters and trailing backslashes are the usual risk points. A command that merely prints its arguments is a useful diagnostic: run it with representative paths and values, then compare the received arguments before and after the upgrade.
Free tools Windows power users keep installed
One-click scans. No signup required.
A common parameter for progress control
PowerShell 7.4 adds ProgressAction to the common parameters. Scripts can now control progress behavior consistently where a command supports common parameters, which is useful for quiet scheduled jobs and for interactive tasks where progress should remain visible. Do not assume it changes a command that does not emit progress records.
Best Value
Test-Json uses JsonSchema.NET
Test-Json moved to JsonSchema.NET in the 7.4 line. Older Draft 4 schemas are no longer supported by that cmdlet. If validation starts failing after an upgrade, inspect the schema draft and either update the schema or use a validator that supports the required draft.
Feedback and module-loading experiments
7.4 introduced PSFeedbackProvider as an experimental replacement for the hard-coded suggestion framework. It exposes formatting properties through $PSStyle.Formatting. The release also introduced experimental PSModuleAutoLoadSkipOfflineFiles and PSCommandWithArgs. Experimental status means behavior and names can change; pin a tested PowerShell version when a production profile depends on them.
Why PowerShell 7 feels different from Windows PowerShell 5.1
The transition began before 7.4. PowerShell 7.2 added universal installers for most supported Linux distributions, Microsoft Update support on Windows, PSReadLine 2.1 Predictive IntelliSense and experimental native-command argument passing. Those changes explain why installation, update channels, command discovery and interactive completion differ from a 5.1 workstation even when the same script is run.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallThe largest compatibility boundaries are:
- Operating system and runtime: .NET APIs and platform providers are not identical across Windows, Linux and macOS.
- Native processes: argument quoting, standard-error handling, encodings and byte preservation can affect every external executable.
- Modules: a module may target Windows PowerShell, a particular .NET API or a specific PowerShell edition; bundled module versions also change across releases.
- Interactive tooling: PSReadLine and completion behavior evolve independently of the core language.
- Serialization and validation: JSON number handling, CLI-XML commands and JSON-schema support can alter data contracts.
Upgrade decision: stay on 5.1, move to 7.4, or test 7.5/7.6
| Your situation | Most defensible choice | What to verify first |
|---|---|---|
| Windows-only scripts depend on legacy snap-ins or modules that have no .NET-compatible build | Keep the affected workload on 5.1 while modernizing it | Module availability, provider behavior and replacement APIs |
| You need a supported long-term runtime and stable native byte handling | Evaluate the 7.4 LTS line | Native redirection, Windows argument passing, schema drafts and module compatibility |
| You need CLI-XML commands, newer completion or web-cmdlet fixes | Evaluate 7.5 | File-catalog defaults, restricted-remoting help and JSON consumers |
| You want the current LTS line and .NET 10 | Evaluate 7.6 | ThreadJob module qualification, bundled module versions, macOS packaging and experimental-feature assumptions |
There is no universal “latest is always safe” answer. Choose the newest line whose runtime, modules and native-command contract you have tested in the environments where the script will run.
A practical upgrade checklist
- Record the baseline. Run
$PSVersionTableon every execution host and note the PowerShell, OS and .NET values. - Inventory dependencies. Capture modules loaded by profiles, scheduled tasks, CI jobs and deployment scripts. Pay special attention to module-qualified ThreadJob commands.
- Exercise native commands. Test paths with spaces, quotes, empty arguments, non-ASCII characters and trailing slashes. Test both text output and binary redirection.
- Validate data contracts. Compare JSON containing large integers, run every
Test-Jsonschema, and test any new CLI-XML exchange with the receiving process. - Test web automation. Check
-PassThru,-OutFile, verbose logs and resumed downloads against the exact endpoints used in production. - Review policy and remoting. Confirm that restricted sessions have the local help and module content they require, since network help retrieval can be blocked in 7.5.
- Reinstall deliberately. On Windows, inspect remembered installer options before accepting a 7.5 or later installation. On macOS, use the signed and notarized 7.6 package when that line is your target.
- Roll out in stages. Run a canary host or CI matrix across the operating systems and PowerShell lines you support, then promote only after logs and output comparisons are clean.
Common symptoms after upgrading
| Symptom | Likely change | Response |
|---|---|---|
| A binary file is corrupted after a pipeline or redirect | Text-oriented processing was used where byte preservation was required | Retest with the 7.4 native byte-stream behavior and keep the data path binary end to end |
| A Windows executable receives different arguments | Native argument-passing rules changed | Log the executable’s received arguments and revise quoting or argument construction |
| A ThreadJob command is not found | The 7.6 module name changed | Use Microsoft.PowerShell.ThreadJobStart-ThreadJob for module-qualified calls |
Test-Json rejects a formerly valid schema |
JsonSchema.NET does not support the older Draft 4 schema used | Update the schema draft or select a validator that supports Draft 4 |
| A file-catalog comparison changes unexpectedly | 7.5 defaults New-FileCatalog -CatalogVersion to 2 |
Set the catalog version explicitly when interoperability requires a fixed format |
| Remote help no longer downloads | 7.5 blocks network help in restricted remoting sessions | Install or provide local help, or revise the remoting policy intentionally |
| A JSON consumer sees a number instead of a quoted integer | 7.5 serializes BigInteger as a JSON number |
Update the consumer’s schema and numeric handling before deployment |
Bottom line
PowerShell 7’s meaningful progress is in compatibility boundaries: modern .NET runtimes, safer native byte handling, revised Windows argument passing, better completion and web tooling, explicit CLI-XML conversion, and refreshed module packaging. PowerShell 7.4 is the .NET 8 LTS option, 7.5 adds tooling and serialization changes on .NET 9, and the 7.6 LTS line brings .NET 10 plus promoted mainstream features. Upgrade when those capabilities solve a real requirement, but treat native commands, modules, schemas, remoting and serialized data as testable contracts rather than assuming a drop-in replacement for Windows PowerShell 5.1.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
