If you set up or rebuild Windows machines often, keeping a clean, reproducible list of applications saves hours. Microsoft’s Windows Package Manager, better known as winget, makes it easy to export your installed app list and import it on another machine—or automate it entirely. In this guide, you’ll learn exactly how to export/import your app list with winget, how to keep it clean and reproducible, and how to automate the whole workflow with ready-to-use commands and scripts.

You’ll find practical examples, annotated configuration files, and troubleshooting steps that cover real-world issues like hash mismatches, Store app quirks, and multiple installer variants. Let’s get you from “fresh install” to “fully loaded” as fast and reliably as possible.

Overview of the Use Case
Why export/import your app list with WinGet?

• Plain language: You’ll capture the set of apps you use on one PC and quickly install them on another—without hunting down installers, clicking wizards, or forgetting anything.
• Keep it clean: You can prune unwanted items (bloatware, vendor updaters), pin key versions, and enforce consistent configurations across machines.

Common scenarios

• Fresh Windows installs: New PC or clean OS reinstall.
• Reproducible dev/ops environments: Set up dev boxes, lab VMs, WSL tooling, SDKs, and CLI utilities consistently.
• Bulk update/repair: Quickly restore a user’s core apps after a hardware swap or disk failure.
• CI/CD automation: Prep a build agent or test runner with exact tool versions.
• Fleet management baseline: Pair with Intune or scripts to baseline apps and then keep them updated.

Quick Reference Table
| Command | Purpose | Example Output |
|—|—|—|
| winget –info | Show WinGet version and environment | Windows Package Manager v1.7.x Desktop App Installer v1.22.x |
| winget list | List installed packages recognized by winget | Name, Id, Version, Available, Source |
| winget search vscode | Search for a package | Microsoft.VisualStudioCode (Id), Available version, Source=winget |
| winget show –id Git.Git | Show package details and installers | Id: Git.Git, Installer types, Architectures |
| winget export -o apps.json –include-versions | Export installed apps to JSON file | Creates apps.json with package identifiers and versions |
| winget import -i apps.json –accept-package-agreements –accept-source-agreements | Import and install apps from JSON | Installs packages listed in apps.json |
| winget upgrade –all | Upgrade all upgradable packages | Upgraded: 5; Skipped: 2 |
| winget source reset –force | Reset and re-index sources | Successfully reset sources: winget, msstore |
| winget pin add –id Git.Git –version 2.44. | Pin a package to a version (or range) | Successfully pinned Git.Git to 2.44. |
| winget download –id 7zip.7zip -o .\cache | Prefetch installer(s) for offline use | Downloaded 7zip.7zip to .\cache |

Key Concepts and Prerequisites
What you need

• WinGet CLI: Preinstalled on Windows 11; on Windows 10, install “Desktop App Installer” from Microsoft Store. Recommended: winget 1.6+ (1.7+ preferred) for stable import/export and pin features.
• PowerShell: Windows PowerShell or PowerShell 7 for scripting.
• Admin rights: Not every install needs elevation, but many “machine scope” installs do. Open an elevated terminal for best results.
• Internet access: Required for downloading from sources like winget and msstore, unless you’ve pre-cached installers (offline workflow).

Check your version

• Command:

  winget –info

• Tip: If you see an older version, open Microsoft Store and update “App Installer” or run:

  winget upgrade –id Microsoft.DesktopAppInstaller –source msstore

Sources and identifiers

• Sources: The default sources are typically winget (community repo) and msstore (Microsoft Store packages).
• Identifiers: Packages use a unique Id (aka PackageIdentifier) such as Git.Git or Microsoft.VisualStudioCode. Always prefer the Id rather than a display name to avoid ambiguity.

Import/export formats

• Export/import uses JSON files. You can hand-edit them to keep your list tidy.
• Winget also supports YAML-based configuration files via winget configure (useful for richer setups), but the simple “app list” import/export is JSON-driven.

Silent installs and overrides

• Most packages support –silent. For extra installer arguments (like disabling desktop icons), use –override “args”.
• Not all installer overrides are respected by all packages; test critical ones or bake them into a YAML configuration with winget configure.

Step-by-Step Guide

1. Verify WinGet and sources

• Check version and sources:

  winget –info
  winget source list
  winget source update

• If sources look broken or fail to update:

  winget source reset –force

2. Inventory your installed apps

• Basic list:

  winget list

• Filter for winget-aware packages only:

  winget list –source winget

• Spot candidates that may not map cleanly:

  • If an app isn’t recognized (no Id/Source), search for it:

    winget search “Vendor AppName”
    winget show –id Exact.Package.Id

3. Export your app list (and keep it clean)

• Full export including versions:

  winget export -o .\apps.json –include-versions

• Export only from the winget source (to avoid Store/system items you might not want):

  winget export -o .\apps-winget-only.json –include-versions –source winget

• Open the JSON file and review it. Remove apps you don’t want on new machines (OEM tools, vendor updaters, edge-case utilities). Keep the set lean.

4. Understand the exported JSON

A typical export file looks like this (structure may vary with winget versions):

{
“$schema”: “https://aka.ms/winget-packages.schema.json“,
“CreationDate”: “2025-01-12T14:25:37.1234567Z”,
“Sources”: [
{
“Name”: “winget”,
“Packages”: [
{ “PackageIdentifier”: “Git.Git”, “Version”: “2.44.0” },
{ “PackageIdentifier”: “Microsoft.VisualStudioCode”, “Version”: “1.93.0” },
{ “PackageIdentifier”: “7zip.7zip”, “Version”: “24.07” }
]
},
{
“Name”: “msstore”,
“Packages”: [
{ “PackageIdentifier”: “9NBLGGH4NNS1”, “Version”: “2024.1001.1.0” }
]
}
]
}

Key points:

• PackageIdentifier is the exact Id winget installs.
• Version is included when you use –include-versions for reproducibility. You can omit versions to always install latest.
• Store apps (msstore) may require Microsoft Store sign-in and can fail silently if the machine isn’t authorized.

5. Optional: curate a YAML configuration (advanced)

If you want more control (installer arguments, additional config tasks), use winget configure with YAML. This does not replace export/import JSON, but complements it for richer provisioning. Example:

file: configuration.dsc.yaml

Purpose: Reproducible environment with explicit packages and silent modes

properties:
configurationVersion: 0.2.0

resources:

Install Git silently

• resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Git
  directives:
  description: Install Git for Windows silently (no desktop icons)
  settings:
  id: Git.Git # YAML key: id -> PackageIdentifier
  source: winget # YAML key: source -> Source name
  installMode: silent # YAML key: installMode -> ‘silent’ or ‘interactive’
  version: 2.44.0

  override lets you pass installer arguments, for example:

  override: ‘/VERYSILENT /NORESTART /NOCANCEL’

• resource: Microsoft.WinGet.DSC/WinGetPackage
  id: VSCode
  directives:
  description: Install Visual Studio Code machine-wide
  settings:
  id: Microsoft.VisualStudioCode
  source: winget
  scope: machine # YAML key: scope -> ‘user’ or ‘machine’
  installMode: silent

Run with: winget configure -f .\configuration.dsc.yaml –accept-agreements

6. Import on a new machine

• Place your curated JSON on the new machine, then run an elevated terminal:

  winget import -i .\apps.json –accept-package-agreements –accept-source-agreements

• If your export included versions but you want newest on this machine:

  winget import -i .\apps.json –ignore-versions –accept-package-agreements –accept-source-agreements

• If some packages aren’t available from current sources:

  winget import -i .\apps.json –ignore-unavailable –accept-package-agreements –accept-source-agreements

7. Make installs quiet and unattended

• Global silence:

  • For many packages, winget import will choose a silent mode automatically if available. If you need to enforce silence:

    • When installing individually:

      winget install –id Git.Git –version 2.44.0 –silent –accept-package-agreements –accept-source-agreements

    • For bulk with custom overrides, consider a PowerShell loop (see Automation Tips).

8. Validate and upgrade

• Verify packages installed:

  winget list

• Upgrade any that are behind:

  winget upgrade –all –accept-package-agreements –accept-source-agreements

9. Keep it clean for next time

• Remove packages you no longer use, then re-export:

  winget uninstall –id Some.Old.Tool
  winget export -o .\apps.json –include-versions

• Pin mission-critical versions:

  winget pin add –id NodeJS.NodeJS –version 20.*
  winget pin list

Troubleshooting
Hash mismatch (Installer hash does not match)

• Cause: The downloaded installer changed upstream or the cache is stale.

• Fix:

  • Update sources:

    winget source update

  • Reset sources if needed:

    winget source reset –force

  • Clear winget installer cache (close open terminals first):

    $cache = “$env:LOCALAPPDATA\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalCache\Microsoft\WinGet\DefaultState”
    if (Test-Path $cache) { Remove-Item “$cache*.db” -Force -ErrorAction SilentlyContinue }

  • Retry the install or import.

Multiple installers found or architecture ambiguity

• Cause: Package has multiple installer types/architectures (x86, x64, ARM).

• Fix when installing a single package:

  winget install –id Example.App –architecture x64 –scope machine

• For imports requiring special choices, prefer a configuration YAML (winget configure) or install those specific packages in a pre-step script with explicit flags.

Source index errors or packages not found

• Fix:

  winget source update
  winget source reset –force
  winget search “Exact App Name”
  winget show –id Publisher.App

• Ensure “App Installer” is up to date from Microsoft Store.

Microsoft Store apps fail to install

• Causes: Not signed in to Store, policy restrictions, or app is user-context only.

• Fix:

  • Sign in to Microsoft Store (same account used to acquire apps).

  • Try user scope:

    winget install –id Microsoft.ToDo –scope user

Access denied or elevation prompts

• Some installers require elevation. Open Windows Terminal/PowerShell “Run as administrator” and re-run the command.

Corporate policy or firewall blocks

• Coordinate with IT to allow winget endpoints, or use an offline workflow (see Automation Tips).
• In managed environments, consider Intune’s winget integration for sanctioned packages.

Automation Tips
Automate export to version-controlled storage

• Script: Export and commit to a repo folder

  Export with versions and timestamped filename

  $ts = Get-Date -Format “yyyy-MM-dd”
  $out = “.\exports\apps-$ts.json”
  winget export -o $out –include-versions

  Optional: Keep a stable symlink or copy

  Copy-Item $out .\exports\apps-latest.json -Force

Bulk install with custom overrides using PowerShell

If you need per-package installer arguments (beyond what import supports), use a simple data file and loop:

• apps.csv:

  Id,Version,Args
  Git.Git,2.44.0,”/VERYSILENT /NORESTART”
  Microsoft.VisualStudioCode,, # leave Version empty to get latest
  7zip.7zip,24.07,”/S”

• install.ps1:

  Import-Csv .\apps.csv | ForEach-Object {
  $id = $.Id
  $ver = $.Version
  $args = $_.Args

  $cmd = “winget install –id "$id” –accept-package-agreements –accept-source-agreements –silent”
  if ($ver) { $cmd += ” –version "$ver“” }
  if ($args) { $cmd += ” –override "$args“” }
  Write-Host “Installing $id $ver”
  Invoke-Expression $cmd
  }

Schedule weekly updates with Task Scheduler

• Run as SYSTEM or an admin to reduce prompts.

• PowerShell command:

  $A = New-ScheduledTaskAction -Execute ‘powershell.exe’ -Argument ‘-NoProfile -WindowStyle Hidden -Command “winget upgrade –all –accept-package-agreements –accept-source-agreements”‘
  $T = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 3am
  Register-ScheduledTask -Action $A -Trigger $T -TaskName “WingetWeeklyUpgrade” -Description “Weekly winget upgrades” -RunLevel Highest

Use winget in Intune (Microsoft Endpoint Manager)

• Intune integrates with winget catalogs. You can:
  • Add “Microsoft Store app (new)” or “WinGet” apps directly from the catalog.
  • Create a baseline set matching your exported list.
  • Optionally wrap a winget configure YAML or a PowerShell script (Win32 app) for fine-grained control.

CI/CD runners (GitHub Actions/Azure Pipelines)

• Example (GitHub Actions windows-latest):

  • name: Ensure winget ready
    run: winget –info

  • name: Install toolchain
    run: winget import -i ..ci\apps.json –accept-package-agreements –accept-source-agreements

  • name: Pin critical tools
    run: |
    winget pin add –id Git.Git –version 2.44.
    winget pin add –id NodeJS.NodeJS –version 20.

Offline or semi-offline scenarios

• Prefetch installers on a connected machine:

  mkdir .\cache
  winget download –id 7zip.7zip –version 24.07 -o .\cache
  winget download –id Git.Git –version 2.44.0 -o .\cache

• Move the cache to the offline machine.

• Install directly from the cached installers (bypassing winget’s download):

  • Use vendor silent flags, e.g., 7-Zip: 7z2407-x64.exe /S

• Advanced: build a local winget source or local manifests, then:

  winget install –manifest .\local-manifests\Git.Git.yaml

  This approach is more work but keeps you inside the winget ecosystem.

Best Practices

• Keep the list minimal: Only include apps you truly want on every machine. Exclude preinstalled components, OEM utilities, and one-offs.

• Use –include-versions for reproducibility: Pin exact versions in the export for stable rebuilds (especially for toolchains).

• Add pins for business-critical tools: Use winget pin to prevent unintended upgrades.

  • Examples:

    winget pin add –id Git.Git –version 2.44.
    winget pin add –id Python.Python.3.11 –version 3.11.

• Prefer winget repository packages over Store when possible: Store apps may require user sign-in and can vary by tenant policy.

• Document installer overrides: If you need custom silent flags, keep them in a script or in a winget configure YAML to avoid surprises.

• Test on a VM first: Validate your import on a disposable VM before rolling out to your main machine or teams.

• Version-control your app list: Store apps.json in a private repository. Track changes with commits and release tags to align with machine baselines.

• Periodically prune and re-export: Remove unused software, then run:

  winget export -o .\apps.json –include-versions

• Respect licensing and security: Only install software you’re licensed to use. Review package manifests and installers and use *–accept-agreements** only when appropriate.

Conclusion
Exporting and importing your app list with winget is a fast, safe, and powerful way to make Windows setups reproducible. You can capture your current environment, curate it, and restore it in minutes—silently and consistently. With version pinning, optional YAML configuration, and automation via PowerShell, Intune, or CI/CD, you’ll keep every machine clean and aligned to your standards.

Start small: run winget export, clean the JSON, then try winget import on a VM. Once you’re happy, automate and scale it out. You’ll never go back to manual installs.

FAQ

Does winget import reinstall apps I already have?

No. If a package is already installed at the same or newer version, winget generally skips it. If you exported versions and the installed version differs, behavior can vary by package; you can follow up with winget upgrade –all or include –ignore-versions during import to always grab the latest.

Can I export only winget (non-Store) packages?

Yes. Use:

winget export -o .\apps-winget.json –include-versions –source winget

This avoids msstore items that may require user sign-in.

How do I pass custom installer switches during bulk install?

The simplest way is to install those few packages individually with:

winget install –id Publisher.App –override “YOUR_ARGS” –silent

For many packages, you can also model installer arguments in a YAML configuration using winget configure. The basic JSON import format focuses on package identity and version rather than per-package overrides.

What’s the difference between winget import and winget configure?

• import: Installs a list of packages from a JSON file—fast way to replicate app sets.
• configure: Applies a YAML configuration that can include packages plus additional settings, scripts, and installer overrides. It’s better for complex, fully reproducible environments.

Is winget safe to use with admin rights?

Yes, when used carefully. Winget pulls from trusted sources like the community repo and the Microsoft Store, and it validates installer hashes. Still, review what you install, keep sources updated, and avoid bypassing hash validation. For corporate environments, use Intune integration and sanctioned package sources.