SCCM to Intune Migration: How to Use Winget for App Re-packaging

Organizations across every industry are shifting from System Center Configuration Manager (SCCM) -- now Microsoft Endpoint Configuration Manager (MECM) -- to Microsoft Intune for endpoint management. The move to cloud-native device management brings real advantages: no on-premises infrastructure to maintain, native support for remote and hybrid workforces, and tighter integration with the Microsoft 365 ecosystem. But there is one part of the migration that consistently causes IT teams to stall: the application catalog.

Your SCCM environment likely has dozens or hundreds of applications configured with specific deployment types, detection methods, requirement rules, and dependencies. None of that configuration transfers directly to Intune. Every application needs to be re-evaluated, re-packaged, and re-deployed. This guide walks through how to use the Windows Package Manager (Winget) and IntuneGet to dramatically accelerate the app migration portion of your SCCM to Intune transition, turning weeks of manual re-packaging work into a streamlined, largely automated process.

The SCCM to Intune App Migration Challenge

SCCM and Intune handle application management in fundamentally different ways. Understanding these differences is the first step toward planning an efficient migration. In SCCM, applications are built around deployment types that define how an app is installed on different platforms and architectures. A single SCCM application might have multiple deployment types for x86 and x64 systems, each with its own installer, detection method, and requirements. Intune uses a flatter model where each Win32 app is a single entity with one installer package, one set of detection rules, and one set of requirement rules.

The practical impact is significant. Here is what you face when migrating your SCCM app catalog to Intune:

• Format incompatibility: SCCM applications use source files directly from network shares. Intune Win32 apps require everything wrapped in the .intunewin format using the Microsoft Win32 Content Prep Tool. Every application needs re-packaging.
• Detection rule translation: SCCM detection methods (WMI queries, complex script-based detection, enhanced detection with clauses) need to be rebuilt as Intune detection rules. Intune supports MSI product codes, file or folder checks, and registry key detection, but not the same flexible WMI and scripting options SCCM offers.
• Installer sourcing: Many SCCM deployments reference installers on internal distribution points or file shares. Moving to Intune means you need current installer files uploaded to the Intune service. If your SCCM source files are outdated, you need to re-download current versions from vendors.
• Dependency and supersedence gaps: SCCM supports complex dependency chains and supersedence relationships between applications. Intune has more limited dependency support and handles supersedence differently. These relationships need to be reviewed and restructured.
• Scale of effort: A typical enterprise SCCM environment has 100-500 applications. At 1-2 hours per application for manual re-packaging, you are looking at 200-1,000 hours of work just for the app catalog -- before testing.

Why Winget Simplifies SCCM to Intune Migration

The Windows Package Manager (Winget) changes the economics of SCCM to Intune app migration. Instead of manually downloading installers from vendor websites, creating IntuneWin packages, and writing detection rules for each application, Winget provides a standardized catalog of over 10,000 applications with verified installers, version metadata, and hash validation. The key insight is that a large percentage of your SCCM app catalog likely consists of common third-party applications that already exist in the Winget repository.

Consider a typical SCCM application catalog. Common applications like Google Chrome, Mozilla Firefox, Adobe Reader, 7-Zip, Visual Studio Code, Notepad++, VLC Media Player, Zoom, and Microsoft Teams are present in nearly every enterprise environment. All of these are available in Winget with standardized package manifests that include the exact information needed for Intune deployment: installer URLs, silent install switches, detection data, and publisher metadata.

Here is why Winget makes SCCM to Intune migration faster:

• Instant installer sourcing: No need to hunt for download links or verify file integrity. Winget provides verified installers with SHA256 hashes for every package version.
• Pre-built metadata: Winget manifests include installer type (MSI, EXE, MSIX), silent install flags, publisher info, and architecture details. This is precisely the data you need to configure Intune Win32 apps.
• Consistent packaging: Every Winget package follows the same manifest schema. Once you have a workflow for converting Winget packages to Intune apps, it works the same way for all 10,000+ packages.
• Version management: Winget tracks every published version, making it straightforward to deploy the same version you had in SCCM or upgrade to the latest release as part of the migration.

Step-by-Step Migration Process

The following process outlines how to systematically migrate your SCCM application catalog to Intune using Winget as the intermediary. This approach splits your catalog into two categories: apps that have Winget equivalents (which can be automated) and apps that require manual re-packaging.

Step 1: Export your SCCM application inventory

Start by generating a complete list of applications currently deployed through SCCM. Connect to your SCCM site server and run the following PowerShell commands to export your application catalog:

# Connect to your SCCM site
Import-Module ConfigurationManager
Set-Location "$((Get-PSDrive -PSProvider CMSite).Name):"

# Export all applications with deployment type details
Get-CMApplication | Select-Object LocalizedDisplayName, SoftwareVersion, `
  Manufacturer, NumberOfDeploymentTypes, IsDeployed, IsSuperseded |
  Sort-Object LocalizedDisplayName |
  Export-Csv -Path "C:\Migration\SCCM_AppCatalog.csv" -NoTypeInformation

# Get deployment type details for detection rule reference
Get-CMApplication | ForEach-Object {
  $app = $_
  Get-CMDeploymentType -ApplicationName $app.LocalizedDisplayName |
    Select-Object @{N='Application';E={$app.LocalizedDisplayName}},
      LocalizedDisplayName, Technology, ContentLocation
} | Export-Csv -Path "C:\Migration\SCCM_DeploymentTypes.csv" -NoTypeInformation

Write-Host "Exported application catalog to C:\Migration\"

This gives you a comprehensive list of every application in SCCM along with its deployment type technology (MSI, Script, AppV, etc.) and content source location. Keep this export as your migration tracking document.

Step 2: Match SCCM apps to Winget packages

With your SCCM app list in hand, the next step is identifying which applications have Winget equivalents. You can automate this matching process with PowerShell:

# Read the exported SCCM app list
$sccmApps = Import-Csv "C:\Migration\SCCM_AppCatalog.csv"

# Search Winget for each SCCM application
$results = foreach ($app in $sccmApps) {
  $searchTerm = $app.LocalizedDisplayName
  $wingetResult = winget search $searchTerm --accept-source-agreements 2>$null |
    Select-String -Pattern "^\S+" | Select-Object -Skip 1 -First 1

  [PSCustomObject]@{
    SCCMAppName    = $app.LocalizedDisplayName
    SCCMVersion    = $app.SoftwareVersion
    Publisher      = $app.Manufacturer
    WingetMatch    = if ($wingetResult) { "Found" } else { "Not Found" }
    WingetOutput   = if ($wingetResult) { $wingetResult.Line.Trim() } else { "N/A" }
  }
}

# Export results and display summary
$results | Export-Csv "C:\Migration\WingetMatchResults.csv" -NoTypeInformation

$found = ($results | Where-Object WingetMatch -eq "Found").Count
$total = $results.Count
Write-Host "Winget matches: $found / $total applications ($([math]::Round($found/$total*100))%)"
Write-Host "Results saved to C:\Migration\WingetMatchResults.csv"

In most enterprise environments, 40-70 percent of third-party applications will have Winget matches. The exact percentage depends on how many custom line-of-business apps you have in your catalog. Common commercial and open-source applications almost always have Winget packages.

Step 3: Deploy matched apps to Intune with IntuneGet

For every application that has a Winget match, you can use IntuneGet to deploy it to Intune in minutes instead of hours. Sign in to IntuneGet with your Microsoft Entra ID account, search for the application by name, and deploy it. IntuneGet handles the complete pipeline: downloading the installer from Winget, creating the .intunewin package, generating detection rules based on the installer type, configuring install and uninstall commands, and uploading the finished package to your Intune tenant via the Graph API.

Step 4: Verify and assign

After deploying apps through IntuneGet, verify each application in the Intune admin center. Check that detection rules, install commands, and requirement rules are correctly configured. Then assign the applications to the same user or device groups that received the apps through SCCM. Run pilot deployments to a test group before rolling out to production to validate that applications install and detect correctly in the Intune-managed context.

Using IntuneGet for Bulk App Migration

The real value of IntuneGet becomes apparent at scale. Manually re-packaging 100 applications at 1-2 hours each means 100-200 hours of work. With IntuneGet, those same 100 applications (assuming they have Winget equivalents) can be deployed in approximately 8-10 hours, including time for review and validation. That is an 80-90 percent reduction in effort for the application migration portion of your SCCM to Intune project.

IntuneGet provides several capabilities that are particularly useful during large-scale SCCM migrations:

• Full Winget catalog access: Search and deploy from the complete Winget repository of 10,000+ packages, unlike the limited subset available in Intune's built-in Winget catalog.
• Automatic detection rules: IntuneGet reads the Winget manifest to determine the installer type and generates the appropriate detection rule automatically -- MSI product code for MSI installers, file detection for EXE-based apps.
• Pre-upload permission validation: Before starting any deployment, IntuneGet verifies your Graph API permissions. This prevents the frustration of packaging an application only to discover you lack the required DeviceManagementApps.ReadWrite.All permission.
• Post-migration update management: Once your apps are in Intune, IntuneGet monitors Winget for new versions and can automatically update your deployments. Configure per-app policies for auto-update, notify-only, version pinning, or ignore.

To get started, see the Getting Started guide for initial setup, or jump directly to the SCCM Migration guide for a walkthrough tailored to organizations moving from SCCM to Intune. You can sign in and start deploying immediately -- IntuneGet is free and open source under the MIT license with no seat limits or usage restrictions.

Handling Apps Not in Winget

Not every application in your SCCM catalog will have a Winget equivalent. Custom line-of-business applications, vendor-specific enterprise software with proprietary licensing, and internally developed tools will need a different approach. Here are strategies for handling these apps:

Custom line-of-business applications

LOB apps built internally or customized for your organization will need manual packaging. Locate the source installer from your SCCM content library or internal build pipeline. Use the Microsoft Win32 Content Prep Tool to create the .intunewin package, then upload it to Intune manually. Pay close attention to detection rules -- if your SCCM detection method used a WMI query, you will need to translate that into a registry check or file existence rule that Intune supports.

Vendor-specific enterprise packages

Some enterprise applications -- particularly those with complex licensing, hardware dongles, or custom middleware dependencies -- are distributed through vendor-specific channels and are not available in Winget. For these applications, contact the vendor for an Intune-compatible installer or deployment guide. Many enterprise software vendors have updated their deployment documentation to include Intune-specific instructions as more organizations migrate from SCCM. If the vendor provides an MSI installer, Intune can deploy it directly without Win32 wrapping. MSIX-packaged applications are also natively supported in Intune.

Scripts and configuration packages

SCCM environments often include script-based packages for configuration tasks, printer deployments, drive mappings, and system tweaks. These do not translate to Intune Win32 apps. Instead, evaluate whether these tasks should move to Intune device configuration profiles, PowerShell scripts deployed through Intune, remediation scripts, or Proactive Remediations. This is an opportunity to modernize legacy scripted configurations into proper policy-based management.

Co-management Considerations

Most organizations do not migrate from SCCM to Intune overnight. Microsoft's co-management feature allows you to run both systems in parallel, gradually shifting workloads from SCCM to Intune. Understanding how co-management affects application deployment is critical for a smooth migration.

Co-management lets you switch individual workloads between SCCM and Intune independently. The workloads that affect application migration directly are:

• Client apps workload: Controls which system manages application deployments. When set to Intune, the Company Portal becomes the primary app catalog for users. Keep this on SCCM until you have migrated a critical mass of applications to Intune.
• Compliance policies workload: If your compliance policies reference specific application installations as requirements, ensure those applications are available through Intune before switching this workload.
• Windows Update policies workload: Independent of application deployment, but worth migrating early since Intune's Windows Update for Business policies offer more granular control than SCCM's software update point for most scenarios.

A recommended co-management migration sequence for applications:

1. Enable co-management and keep all workloads on SCCM initially
2. Begin deploying new applications through Intune only (do not add new apps to SCCM)
3. Use IntuneGet and Winget to migrate existing SCCM apps to Intune in batches
4. Run parallel deployments for critical apps -- deploy through both SCCM and Intune during the validation period
5. Switch the Client Apps workload to a pilot Intune group for testing
6. After successful validation, switch the Client Apps workload to Intune for all devices
7. Retire the corresponding SCCM applications once Intune deployments are confirmed working

During the co-management phase, avoid deploying the same application through both SCCM and Intune to the same device unless you are intentionally running parallel validation. Dual management of the same app can cause detection conflicts and unexpected installation or removal behavior.

Frequently Asked Questions

Conclusion

Migrating from SCCM to Intune is a significant undertaking, but the application catalog does not have to be the bottleneck. Winget provides the standardized package repository that bridges the gap between SCCM's on-premises application model and Intune's cloud-native deployment approach. By auditing your SCCM catalog, identifying Winget equivalents, and using IntuneGet to automate the re-packaging and deployment process, you can reduce the app migration effort by 60-80 percent.

For the applications that fall outside Winget's catalog, manual packaging remains necessary, but these represent the minority of most app catalogs. Combined with a well-planned co-management strategy that gradually shifts workloads from SCCM to Intune, you can execute the migration with minimal disruption to your end users and IT operations.

The move to cloud-native endpoint management is not a question of if but when. Tools like Winget and IntuneGet exist to make that transition as efficient as possible, letting your team focus on strategic improvements rather than repetitive packaging work. For a step-by-step walkthrough of deploying Winget apps to Intune, see our complete deployment guide. To understand the time savings automation brings versus manual processes, read our Winget vs manual deployment comparison.