PowerShell vs CMD: Which to Use and When

Every Windows machine ships with two command lines, and new technicians ask the same thing on day one: which one do I open? The short version is that CMD reads and writes text while PowerShell passes objects around, and that one difference decides most tickets. Here's PowerShell vs CMD in plain terms: what each does well, where CMD still earns its place, and why the August 2026 WMIC removal pushed the last holdouts over.

The Short Answer

Open PowerShell for anything you'll repeat, filter, export or run on more than one machine. Open CMD when you're running a batch file, working in a recovery environment, or pasting a one-liner from an old install guide.

It's a fit question, not a ranking. Microsoft's own Windows commands reference describes both as supported shells, and says PowerShell can run Windows commands and cmdlets while the Command shell runs only Windows commands. The same page recommends PowerShell for new automation work.

So PowerShell is the bigger tool. CMD is the smaller one that still fits a few tight spaces.

Ask Leo's walkthrough covers the same ground from the desk side, including where Windows Terminal fits. Terminal is the window that hosts both shells.

Text vs Objects: The Difference That Matters

In CMD, every command prints text. If you want one value out of that text, you cut it out yourself with findstr, for /f and a guess about which column it lives in. Change the Windows language or the output format and the guess breaks.

In PowerShell, commands pass objects. An object is a record with named fields, so a process arrives with its name, ID and memory use already separated. Microsoft's pipeline documentation shows the classic case: Get-Process notepad | Stop-Process works because the second command receives the process object itself.

Here's the same question asked both ways. Which Chrome processes use the most memory?

code
tasklist /fi "imagename eq chrome.exe"

powershell
Get-Process chrome | Sort-Object WorkingSet64 -Descending | Select-Object -First 3 Name, Id, WorkingSet64

The CMD version gives you a table to read. The PowerShell version gives you a sorted answer you can pipe into Export-Csv, a report or the next command. That's the whole argument for PowerShell on a support desk: you stop parsing and start asking.

PowerShell vs Command Prompt, Side by Side

Most everyday CMD commands have a PowerShell equivalent, and PowerShell keeps aliases so the old muscle memory still works. Type dir in PowerShell and you're running Get-ChildItem. For the full cmdlet list, our PowerShell commands guide goes deeper.

Native tools like ipconfig, ping and robocopy run in both shells unchanged. If you live in ipconfig commands all day, nothing about switching shells breaks them. PowerShell can even pipe their text into Select-String, which Microsoft's pipeline page demonstrates with ipconfig.exe.

Remote work is where the gap gets wide. CMD has no built-in way to run a command on fifty machines. PowerShell has Invoke-Command, which rides on WinRM and returns each machine's result as an object you can sort by computer name.

Windows PowerShell 5.1 or PowerShell 7?

There are two PowerShells, and people mix them up constantly. One reply in the r/windows thread below comes from someone who says they work at Microsoft and still has to explain "no not that PowerShell, this PowerShell."

Windows PowerShell 5.1 is the one already on every Windows 10, Windows 11 and Windows Server machine. It runs as powershell.exe, sits on .NET Framework, and follows the Windows support lifecycle. PowerShell 7 is a separate install. It runs as pwsh.exe, sits on modern .NET, works on macOS and Linux too, and installs side by side with 5.1.

Microsoft's support lifecycle page lists PowerShell 7.6 as the current long-term release, supported until 14 November 2028. Version 7.4 reaches end of support on 10 November 2026.

For a technician, the rule is simple. Write new scripts for 7 when the modules you need work there. Keep 5.1 for older modules and for anything that must run on a machine where nobody installed 7. PowerShell 7 can load a stubborn Windows-only module with Import-Module -UseWindowsPowerShell, which runs it in a 5.1 process behind the scenes.

The replies in that April 2026 thread land on one word: compatibility. Batch files sit inside business processes nobody wants to touch, and 5.1 is wired deep into the OS.

When CMD Is Still the Right Tool

CMD isn't going anywhere, and a few jobs still belong to it.

Batch files are the first. A .bat or .cmd file runs in CMD, and plenty of installers, login scripts and vendor tools still ship as batch. Rewriting a working 20-line batch file just to say it's PowerShell buys you nothing.

Recovery is the second. When Windows won't boot and you open the Command Prompt from the recovery environment, you're in CMD. PowerShell is an optional component for Windows PE images, so don't count on it being there unless someone built it in. Tools like bcdedit, diskpart and DISM all work from that prompt.

Locked-down machines are the third. By default, Windows client editions don't run .ps1 scripts at all, and our upcoming guide on PowerShell execution policy covers how that works. Application control can also push PowerShell into Constrained Language Mode, which our WDAC guide explains. On a machine like that, a quick CMD command can be the path of least resistance for a single check.

Old documentation is the last. If a vendor KB gives you a CMD line with %VARIABLES% and caret escapes, run it in CMD. Pasting it into PowerShell changes how quotes and variables are read.

WMIC Is Gone, So PowerShell Takes Over Inventory

For years, wmic was the CMD user's way into hardware and OS details. Serial numbers, BIOS versions, disk sizes, installed models. It's now removed.

Microsoft's deprecated features list marks WMIC deprecated since Windows 10 21H1 and superseded by PowerShell. Its August 2026 update says WMIC is removed and no longer available as a Feature on Demand on Windows 11 24H2 and later. WMI itself still works. Only the command-line tool left.

The r/sysadmin replies are blunt: you don't put it back, you swap in Get-CimInstance. One commenter also flags a fair gap. Editing WMI permissions is still awkward in PowerShell, where WMIC used to just work.

The swap itself is short. wmic bios get serialnumber becomes (Get-CimInstance Win32_BIOS).SerialNumber. The same WMI classes are there, you just ask for them by property name. One more trap: Get-WmiObject isn't the answer either, because Microsoft removed the WMI v1 cmdlets from PowerShell 7.

If your asset scripts still call WMIC, they now fail on every freshly updated Windows 11 machine. That's the cleanest reason yet to move inventory checks to PowerShell. OpenFrame can run a Get-CimInstance inventory script across a client's devices and collect the output in one place.

Running One Shell From the Other

You'll often need both in the same job. A CMD line can start PowerShell with powershell -NoProfile -Command "Get-Service spooler", or pwsh -Command for version 7. A PowerShell session can hand a line to CMD with cmd /c, which is the safe way to run batch syntax you don't want PowerShell to reinterpret.

Two habits save time here. Check $LASTEXITCODE after a native tool in PowerShell, because the tool's text output tells you nothing about success. And when a CMD line full of quotes misbehaves inside PowerShell, wrap it in cmd /c rather than fighting the escaping.

If you're scripting on your own machine, the default rule holds: PowerShell for anything with a second step, CMD for the batch file you inherited.

Pick the Shell by the Job

CMD handles text, batch files and recovery prompts. PowerShell handles objects, remoting and anything you'll run twice. With WMIC gone from current Windows 11 builds, inventory and hardware checks now belong to PowerShell by default.

Next, try it on a real ticket: our guide to the trust relationship error walks through the PowerShell fix.