So I was writing a deployment script last year and a junior sysadmin on my team kept pinging me — "hey, this ForEach-Object -Parallel thing isn't working." Took me a second to realize he was running PowerShell 5 on Windows Server 2019 and wondering why the cmdlet flat-out didn't exist. That's kind of the PowerShell 7 vs PowerShell 5 situation in a nutshell. They look the same, they feel the same on the surface, but once you go digging, they're genuinely different tools.

Let me break down what actually matters here — not the marketing fluff, but the stuff that hits you in real scripts on real machines.

First, Why Do Both Still Exist?

PowerShell 5.1 is baked into Windows. It ships with it, it's always there, and it's not going anywhere. Microsoft calls it "done" — it's in maintenance mode, meaning security patches only. PowerShell 7, on the other hand, is built on .NET Core (now just .NET), which means it's cross-platform and actively developed. They coexist on the same machine without conflict, which is honestly one of the smarter decisions Microsoft has made. You can run both side by side and they don't step on each other.

To check what you're running right now, just do:

$PSVersionTable

That'll spit out your version, build, and OS. If you see PSVersion 5.1.xxx, you're on the classic. If it starts with 7.x, you're on the new hotness.

The Stuff That Actually Changes Day-to-Day

Here's where it gets real. The biggest functional difference I reach for constantly is ForEach-Object -Parallel. In PowerShell 7, you can do this:

1..10 | ForEach-Object -Parallel {
    Start-Sleep -Seconds 1
    "Done: $_"
} -ThrottleLimit 5

That runs up to 5 iterations simultaneously. On PS5, you'd have to spin up runspaces manually, which is about 40 lines of boilerplate nobody wants to write at 2am. Honestly, this feature alone converted half the sysadmins I work with.

Then there's the Ternary operator, which PS7 borrowed straight from C#:

$status = ($service.Status -eq 'Running') ? 'Online' : 'Offline'

Sounds minor. But when you're writing readable scripts that other people have to maintain, not wrapping everything in if/else blocks makes a real difference. PS5 will throw an error on that syntax. Just something to watch out for when sharing scripts across teams running different versions.

Pipeline chain operators are another one I use constantly now:

Get-Process -Name "notepad" && Write-Host "Notepad is running"
Get-Process -Name "fakething" || Write-Host "Process not found, moving on"

PS5 doesn't have && or ||. You had to do error handling with $? and separate conditionals. Small thing, but it adds up when you're chaining 10 steps together.

The Cross-Platform Angle

If you're purely a Windows shop and always will be, honestly, this matters less. But if you're managing Linux VMs, running scripts in Azure Pipelines, or doing anything in a mixed environment — PS7 is the only sane choice. PS5 is Windows-only, full stop. PS7 runs on Ubuntu, macOS, Alpine, wherever .NET runs. I've got PS7 scripts that run unmodified on a Windows admin machine and a Linux build agent. That used to require Python or Bash for cross-platform work.

Where PS7 Will Bite You Though

Here's the thing though — it's not all unicorns. Some older Windows-specific modules just don't play nice with PS7. The biggest offender? Active Directory cmdlets from the RSAT toolset and anything that depends on the Windows Compatibility layer.

PS7 has a compatibility shim you can invoke:

Import-Module ActiveDirectory -UseWindowsPowerShell

That wraps the module in an implicit PS5 remoting session in the background. It works, but it's slower and occasionally weird. Some cmdlets behave slightly differently through that layer. I've seen it silently drop properties on returned objects, which is the kind of bug that costs you an hour before you figure out what's happening.

If your entire workflow is Active Directory, Exchange on-prem, or legacy SCOM/SCCM scripting — test carefully before you commit. Don't just swap your default shell and assume everything works.

Insider Trick #1: Run PS7 from Inside PS5

You can actually call PS7 from within a PS5 session for specific blocks of code. Useful when you've got a mixed environment and a single script needs to hit both worlds:

pwsh -Command { Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 }

pwsh is the PS7 executable. powershell is PS5. Knowing that distinction saves you when you're writing scheduled tasks or calling shells from other tools — always be explicit about which one you're invoking.

Insider Trick #2: Set PS7 as Default in Windows Terminal Without Losing PS5

Windows Terminal lets you set your default profile. Go to Settings → Startup → Default Profile and point it at PowerShell 7. But keep a PS5 profile tab ready. You don't have to commit fully — just make PS7 your daily driver and keep PS5 accessible for legacy stuff. The setting path if you prefer editing the JSON directly:

Ctrl + , (in Windows Terminal) → Open JSON file

Then set your PS7 profile's GUID as the "defaultProfile" value. Takes 30 seconds and it's reversible.

So, Should You Switch?

If you're writing new scripts — yes, use PS7. The parallel processing, cleaner syntax, and active development pipeline make it worth it. If you're maintaining old scripts in a pure Windows environment touching legacy Microsoft tooling, don't rip out PS5, just add PS7 alongside it and migrate gradually.

The coexistence angle is what makes this a non-drama upgrade, honestly. You don't have to choose permanently. Just grab PS7 from the GitHub releases page or via winget:

winget install --id Microsoft.Powershell --source winget

Takes two minutes. Give it a week as your main shell and you'll stop going back. Hope this saves you from a "why doesn't this cmdlet exist" conversation at a bad hour.

Related: PowerShell 7 Download, Setup, and Commands You'll Actually Use Every Day