Windows 11 Migration Realities: Dell Says 500M Can Upgrade, 500M Cannot

  • Thread Author
Windows users are not rushing to the Windows 11 upgrade party, and the headline numbers driving that story come straight from an investor briefing that reframes the migration as a patchwork of technical limits, economic choices, and plain user inertia. Dell’s COO told investors that roughly 500 million PCs that can run Windows 11 haven’t upgraded, and that roughly another 500 million devices can’t run Windows 11 at all under Microsoft’s hardware rules — a blunt split that adds up to a massive addressable market but also exposes how messy the transition really is.

Split graphic contrasts Windows 11 upgrade realities: 500M can upgrade; 500M cannot.Background​

Microsoft’s Windows 10 reached its official end-of-support milestone this year, creating an urgency counterpoint to the slow upgrade rate. The company’s lifecycle documentation confirms that Windows 10’s support ended on October 14, 2025, and Microsoft has offered a limited consumer Extended Security Updates (ESU) program as a bridge through October 13, 2026. Those ESU terms — including free enrollment in some circumstances and a paid option — are documented on Microsoft’s support pages. At the same time, Microsoft executives have used large-scale marketing language around Windows 11 — notably that “nearly a billion people rely on Windows 11” — language that media outlets repeated but that Microsoft did not quantify in simple, auditable terms. That ambiguity has helped fuel the contrast between the company’s platform messaging and datapoints reported by OEMs like Dell.

What Dell Actually Said — and why it matters​

The numbers, plainly stated​

  • Dell’s installed-base framing: an estimated installed Windows PC base of roughly 1.5 billion devices.
  • Of that universe, Dell’s COO Jeffrey Clarke said about 500 million devices can run Windows 11 but remain on Windows 10.
  • A comparable cohort — about 500 million devices — are, in Dell’s view, too old or otherwise incompatible to run Windows 11 under Microsoft’s current requirements.
Those figures were repeated across multiple outlets and reproduced from Dell’s Q3 earnings call. Treat them as a vendor’s market read — directional and commercially framed — not a precise global census. Dell’s motivation in an investor call is to explain market opportunity for hardware refreshes (including the new “AI PC” category); that context matters when interpreting the headline math.

How Dell’s framing reshapes the migration story​

Dell’s split converts a single narrative — “Windows 11 is being adopted” — into three actionable cohorts:
  • Devices already on Windows 11.
  • Devices that are eligible but haven’t been upgraded (the 500M “sticky” group).
  • Devices ineligible without hardware replacement (the 500M “blocked” group).
This segmentation matters for OEMs, enterprise planners, and channel partners because it separates demand that requires persuasion from demand that requires replacement. The former invites software, services, and migration support; the latter drives trade-ins and hardware sales.

Why users and businesses are sticking with Windows 10​

There are several strong, overlapping reasons adoption is slow — and most are rooted in rational trade-offs rather than ignorance.

1. Familiarity and risk calculus​

Windows 10 has been widely used for a decade and earned trust for stability and compatibility. For many enterprises, the cost and risk of testing, validating, and rolling out a new OS across thousands of endpoints is measured in months and millions of dollars. Users and IT teams often ask: If it isn’t broken, why fix it now? That calculus explains much of the “can but won’t” cohort.

2. Strict hardware requirements​

Windows 11’s baseline intentionally raised hardware and firmware expectations: TPM 2.0 (or fTPM), UEFI Secure Boot, and support for specific CPU generations, alongside minimum RAM and storage. That gate left a large swath of machines — often only a few years old — officially ineligible. For many users, the only practical path to Windows 11 is buying a new machine. This is the core reason Dell and others describe a large “can’t” bucket.

3. Lack of compelling, universal features​

For many users the new features — centered taskbar, aesthetic changes, integrated Copilot AI, and a handful of security enhancements — feel incremental versus transformative. The perceived value of switching simply isn’t high enough for a large group of consumers and businesses, especially once hardware costs and migration work are factored in. Multiple outlets have noted that Windows 11’s strong security posture and AI integration appeal to some, but they do not constitute a universal upgrade catalyst.

4. Slow enterprise adoption cycles​

Enterprises test thoroughly for application compatibility, driver validation, and management tooling. Many delay until a migration is operationally cheap and risk-controlled. That means enterprise rollouts often lag consumer momentum by years, further depressing overall adoption velocity.

5. Alternatives and workarounds​

Some users simply choose alternatives: extend Windows 10 via ESU, switch to Linux distributions where appropriate, or continue using working hardware indefinitely. For the subset who want Windows 11 on older hardware, unsupported workarounds exist — but they carry security and warranty risks and are not recommended for business environments.

Microsoft’s “Nearly a Billion” claim: marketing shorthand or data point?​

At Ignite and associated coverage, Microsoft’s Windows leadership used large-scale language about Windows 11’s reach. Press reporting captured phrases like “nearly a billion people rely on Windows 11”, but Microsoft did not publish a single, unambiguous metric tying that phrase to a specific, publicly auditable definition (monthly active devices, daily active users, or licensed seats). Multiple regional outlets covered the language, but the ambiguity remains. That ambiguity creates two important realities:
  • From a marketing standpoint, the phrasing communicates scale and momentum.
  • From an operational and procurement standpoint, it’s insufficient for planning — organizations and analysts still need telemetry, measured device counts, or independent market-share numbers to plan migrations or budgets.
Be cautious interpreting “nearly a billion” as a precise substitute for the installed-base split Dell offered; the two are complementary but not identical.

Security implications and the ESU bridge​

What end-of-support actually means​

When Microsoft ended mainstream support for Windows 10 on October 14, 2025, it stopped delivering routine security and feature updates for the general consumer lifecycle. The company made clear that systems would continue to function, but without ongoing patches they would be progressively more vulnerable. Microsoft’s official guidance and the ESU program specifics are available on its support pages.

ESU mechanics and limits​

The Consumer Extended Security Updates program provides a practical, time-limited bridge:
  • ESU coverage extends security updates through October 13, 2026.
  • Enrollment options include a free path when syncing settings and signing in with a Microsoft account, a one-time $30 paid option, or redeeming Microsoft Rewards points.
  • ESU is security-only (no feature updates) and is intended as a transition mechanism, not a permanent solution.

Risk trade-offs for organizations and consumers​

  • Short-term mitigation: ESU buys time to plan migrations and fleet refreshes without immediate exposure to unpatched vulnerabilities.
  • Long-term exposure: ESU isn’t indefinite, and the underlying risks of running an unsupported OS accelerate over time as threat actors shift focus.
  • Cost vs. hardware replacement: For fleets of older devices, the choice is often between a year of ESU costs or capital investment in new hardware — a tough decision for constrained budgets.

OEM strategy: AI PCs, trade-ins, and the upgrade funnel​

OEMs like Dell are viewing the Windows 10-to-11 migration not just as a software transition but as a multi-year hardware opportunity. Dell explicitly pitched the existence of large groups of non-upgraded and non-upgradable devices as a runway for selling new AI-capable hardware and services. That line of reasoning is straightforward: if users must buy new machines to get Windows 11 and AI features, OEMs can monetize refresh cycles, trade-in programs, and lifecycle services. But that strategy has limits:
  • If consumers resist buying new hardware for environmental or budgetary reasons, refresh volumes can stall.
  • Aggressive upselling risks regulatory and reputational backlash if perceived as forced obsolescence.
  • The PC market’s long-term unit growth is still uncertain; OEMs can extract more profit from higher ASPs (average selling prices), but they need buyers to accept the ROI on new features like local AI acceleration.

The environmental and e‑waste angle​

Raising hardware baselines can accelerate device churn. Several analyst and advocacy voices warned early that a strict hardware gate could create environmental downstream effects: functioning hardware may be discarded not because it’s broken, but because it’s unsupported. That risk has fueled calls for better trade-in, refurbishment, and circular-economy programs to mitigate the environmental impact of forced refresh cycles. OEMs and retailers have programs, but they don’t fully neutralize the potential e‑waste surge.

Practical guidance: what consumers and IT teams should do now​

These steps balance security, cost, and practical constraints for most users and organizations.
  • Inventory: Produce a reliable device inventory (model, CPU generation, TPM status, BIOS/UEFI capabilities). This is non-negotiable for sound planning.
  • Test: Pilot Windows 11 on representative hardware images and validate application compatibility, drivers, and endpoint management tooling.
  • ESU planning: For devices that will remain on Windows 10 through October 13, 2026, evaluate ESU enrollment for security continuity and budget accordingly. Remember ESU is temporary and has enrollment constraints.
  • Cost analysis: Compare the total cost of ownership between paying for ESU and staged fleet refresh. Include potential productivity gains from modern hardware and AI features if these deliver measurable value.
  • Sustainability: Prioritize trade-in, refurbishment, and donation programs over landfill disposal. Work with vendors that provide certified recycling and reuse channels.
  • Alternatives: For some use cases, consider validated Linux distributions or Chrome OS Flex as a lower-cost path to extended utility for ineligible hardware — but validate application requirements first.

What this means for Microsoft, OEMs, and the broader ecosystem​

  • Microsoft: Messaging that emphasizes scale must be paired with clarity — when public phrases like “nearly a billion” are used, backing them with clear definitions helps IT buyers make decisions. Microsoft’s ESU program is a pragmatic stopgap, but the company’s longer-term policy choices (hardware gates, account requirements) shape how quickly the install base modernizes.
  • OEMs: Vendor-read narratives like Dell’s are useful to sellers because they reframe migration friction as opportunity. But OEMs must also address affordability and sustainability concerns to convert potential into actual purchases.
  • Enterprises and public sector: The slow migration highlights why large organizations should own their telemetry: public vendor statements are directional, but procurement and compliance decisions must be driven by inventory-level facts and risk assessments.

What’s verifiable — and what remains fuzzy​

  • Verifiable: Windows 10’s official end-of-support date (October 14, 2025) and the ESU program terms are published by Microsoft. Dell’s comments to investors were recorded and reported across major outlets; the basic 500M/500M split is a public claim from Dell’s earnings call.
  • Ambiguous or marketing-led: Microsoft’s phrase “nearly a billion people rely on Windows 11” is accurate as marketing language but remains ambiguous without a precise telemetry definition. Treat that phrasing as a high-level indicator of scale rather than a raw, comparable metric to Dell’s installed-base estimate.
  • Caution flagged: Dell’s 500M counts are useful directional signals but are vendor-provided estimates from an investor call; they should not be treated as auditor-style device censuses without independent corroboration or the underlying methodology disclosed.

Bottom line​

The Windows 11 migration is not a single binary moment; it’s a multiyear process shaped by hardware compatibility, cost, corporate risk tolerance, and real user preferences. Dell’s blunt 500M/500M framing crystallizes that reality: there’s a vast pool of devices that could upgrade but haven’t, and another large pool that physically can’t without replacement. Microsoft’s marketing about scale reflects platform momentum but does not negate the tangible frictions that slow mass adoption.
For consumers and IT leaders the actionable takeaway is straightforward: build an accurate inventory, quantify the security and financial trade-offs of ESU versus hardware refresh, and prioritize sustainability as part of any upgrade program. The migration’s economic and environmental consequences are as important as its technical mechanics — and they’re the parts that will determine whether the remaining Windows 10 installed base upgrades, replaces, or adopts alternatives in the years ahead.
Conclusion
Dell’s investor remarks forced a necessary reality check: the Windows ecosystem is bigger and more heterogeneous than a single headline metric suggests. The split between the “can but won’t” and the “can’t” is a pragmatic way to understand why Windows 11 adoption is slower than many expected. The path forward will be multifaceted — security patches, staged migrations, responsible hardware refreshes, and clearer vendor communication — and each organization must plan according to its own inventory, budget, and risk tolerance.

Source: techcityng.com Microsoft Says 500 Million PCs Can Upgrade to Windows 11 But Users Aren’t Interested
 

Microsoft's blunt reminder to Windows administrators — that outdated .NET runtimes are a live security and compliance risk — should be treated as a call to action, not a suggestion. Modern .NET no longer ships as a single monolithic Windows component; instead, multiple side‑by‑side runtimes can coexist on a system, and when development teams don’t recompile or republish their applications to target supported versions, vulnerable runtimes remain in production indefinitely. The result: security scans and audits increasingly flag unsupported .NET versions as open attack surfaces, and IT teams are left responsible for coordinating discovery, remediation, and safe removal without breaking business‑critical software.

Engineer reviews end-of-support for .NET runtimes and remediation steps on screen.Background​

From .NET Framework to modern .NET: a structural shift​

The .NET landscape split in two decades ago when Microsoft moved from the Windows‑bound .NET Framework to the cross‑platform modern .NET family (often called .NET Core initially, now simply “.NET”). That shift changed deployment, servicing, and lifecycle management in three critical ways:
  • Modern .NET is distributed independently of the Windows operating system. Applications install or assume the presence of the runtime they need rather than relying on a single OS‑integrated runtime.
  • Multiple major and patch versions may coexist side‑by‑side. This enables compatibility for apps targeting different target framework monikers (TFMs), but it also leaves old runtimes installed long after they stop receiving security updates.
  • Applications only use newer runtimes if they are explicitly retargeted and redeployed. Simply installing a newer runtime on a host does not force older apps to run on that runtime unless the app’s build/publish settings allow roll‑forward or it is republished.
These architectural choices improved modularity, performance, and cross‑platform reach — but they also introduced operational complexity for Windows administrators tasked with reducing attack surface across servers and endpoints.

Support policy and what “unsupported” actually means​

Modern .NET follows a predictable release cadence and a formal support policy: even‑numbered major releases are Long‑Term Support (LTS) with multi‑year servicing windows; odd‑numbered releases are Standard‑Term Support (STS) with shorter lifecycles. When a .NET release reaches end of support, Microsoft stops shipping security fixes and official technical support for that runtime version. For organizations, running apps that depend on EOL runtimes means:
  • Known vulnerabilities no longer receive patches.
  • Vendors and auditors may flag unsupported components during compliance and penetration testing.
  • Technical support and incident response options are constrained.
Because patch roll‑forward and runtime selection behavior are nuanced (apps may roll forward to the latest patch in the same major version, but not always to a different major release), administrators cannot assume that installing the newest runtime automatically protects older apps. Any inventory or remediation plan must account for application‑level targeting decisions.

Why outdated .NET runtimes are dangerous now​

1. Security fixes stop at end of support​

Once a .NET version is out of support it receives no further security patches. Attackers and automated exploit scanners scan environments for known vulnerable runtimes; if an app still loads code through that runtime, attackers can target the runtime’s unresolved flaws. The risk profile for an organization therefore grows over time: newly discovered vulnerabilities affecting an unsupported runtime will remain exploitable on any host that still contains and uses it.

2. Compliance and audit headlines​

Auditors and security scanners increasingly treat unsupported runtime presence as a critical finding. Regulatory frameworks and internal security policies commonly require that components running in production receive vendor security updates. Unsupported runtimes create audit exceptions and can cause failed assessments for PCI, HIPAA, SOC2, and other controls.

3. Attack surface and lateral movement​

Legacy runtimes commonly carry older libraries, dependencies, and mitigations that newer runtimes have improved. An adversary who can run code in the context of an application that loads an EOL runtime gains a foothold on a platform with fewer defenses and unpatched weaknesses. That foothold can be used to escalate privileges or move laterally if the environment is otherwise permissive.

4. False sense of safety from “runtime presence”​

Installing the latest runtime on a server can create the illusion of protection. In practice, unless the application has been rebuilt and republished to target the newer runtime (or its roll‑forward settings permit it), the app will continue to run using the older runtime it was compiled for. Removing an old runtime without confirming all apps have been migrated can break systems; leaving it in place preserves the vulnerability.

How outdated runtimes persist in Windows environments​

Side‑by‑side installations and application targeting​

Modern .NET supports multiple runtimes in parallel. An installer or developer can leave a specific Microsoft.NETCore.App or Microsoft.AspNetCore.App directory for the precise version an app requires. This cohabitation is intentional — it avoids breaking legacy apps — but it also means outdated versions can persist indefinitely on servers or desktops where they are not actively tracked.

Developer responsibility vs. admin control​

Crucially, changing which runtime an application uses is primarily a development task: the app must be updated (e.g., change its TargetFramework, rebuild with a newer SDK, or publish as self‑contained). System administrators can manage host runtimes and inventory, but they cannot change the app’s compiled target. Effective remediation therefore requires cross‑functional coordination between operations, security, and development teams.

Common sources of lingering runtimes​

  • Old vendor applications that bundle specific .NET runtimes or require them.
  • Line‑of‑business (LOB) apps not actively maintained.
  • Machines used for legacy integrations or internal tooling.
  • Containers or images that still contain old runtimes in their layers.

Practical inventory and discovery — what to run first​

A disciplined inventory is the foundation of remediation. Administrators should combine host‑level discovery with application mapping.
  • On Windows and other platforms, run:
  • dotnet --list-runtimes to enumerate installed shared runtimes.
  • dotnet --list-sdks and dotnet --info to capture installed SDKs and environment details.
  • For IIS and server apps:
  • Identify worker processes and their command lines (IIS application pools, w3wp.exe).
  • Use tooling such as Process Explorer or Process Hacker to inspect loaded modules and determine if a process hosts .NET Core/ASP.NET Core code.
  • Inspect application folders for *.runtimeconfig.json files which reveal target frameworks and roll‑forward settings.
  • For large estates:
  • Use endpoint management tools (SCCM/ConfigMgr, Intune, or other RMM) to run dotnet --list-runtimes remotely and aggregate results.
  • Leverage existing vulnerability scanners and SCA tools configured to detect legacy .NET runtimes and flag EOL versions.
  • For containers and images:
  • Scan images in the registry and CI pipelines. Old runtimes in images propagate risk to every container instance.
Inventory outputs should produce a prioritized list of hosts, runtimes, and the apps that depend on them.

Remediation patterns and a recommended plan​

A structured remediation program reduces risk without causing outages. Use a phased approach.
  • Triage and risk scoring
  • Classify each runtime instance: in active use by production app, used by non‑critical tooling, or orphaned.
  • Score risk on exposure (internet‑facing vs internal), data sensitivity, and exploitability.
  • Developer coordination and application upgrade
  • Notify application owners and request a plan: retarget to a supported LTS (preferred) or STS if planned upgrades are scheduled.
  • For apps that cannot be changed quickly, request temporary compensating controls (network segmentation, WAF rules, host hardening).
  • Publish and test upgrades
  • Developers should update the TargetFramework, rebuild, and publish (or publish self‑contained builds).
  • Use canary deployments and staged rollouts with monitoring to detect behavioral changes introduced by runtime upgrades.
  • Confirm no remaining processes depend on legacy runtimes
  • After apps are upgraded and redeployed, verify on each host that the old runtime is no longer referenced in *.runtimeconfig.json files and that dotnet --list-runtimes no longer lists the old version in active use.
  • Restart services or hosts as needed to ensure processes pick up new runtimes.
  • Remove obsolete runtimes safely
  • Uninstall via the platform package manager or Windows Add/Remove Programs where available.
  • On Linux or macOS, remove the versioned directories; on Windows ensure x86 and x64 versions are addressed.
  • If automated uninstall tools are used, validate their behavior in a lab environment first.
  • Automate and prevent recurrence
  • Include runtime version checks in CI/CD pipelines and deployment gates.
  • Integrate runtime inventory into continuous compliance scans that alert on EOL versions.
  • Establish an internal policy that only approved, supported runtimes are allowed in production.

Alternative mitigations when immediate app upgrades are impossible​

  • Self‑contained deployments: publish applications that bundle the runtime they need. This removes the host runtime dependency and lets the app include a patched runtime, but it increases deployment size and shifts the responsibility to app owners to re‑publish with updated runtime patches.
  • Containerization: replace monolithic hosts with container images that are rebuilt when runtimes receive patches; scanning and image builds become the update control point.
  • Compensating network controls: isolate vulnerable hosts behind segmentation, firewall rules, or WAFs to reduce exposure while upgrades are scheduled.
  • Application allow‑listing and runtime confinement: use host hardening to restrict what legacy applications can do, and monitor process behavior for anomalies.

Tools and commands every Windows admin should know​

  • Inventory
  • dotnet --list-runtimes
  • dotnet --list-sdks
  • dotnet --info
  • Process and module inspection
  • Process Explorer (Sysinternals) to view modules and command lines
  • Get-Process and Get-WmiObject/Get-CimInstance in PowerShell for remote checks
  • Uninstall and cleanup
  • Windows Add/Remove Programs for installed runtime packages
  • Microsoft’s .NET Core Uninstall Tool for supported removable versions (test before mass use)
  • Manual removal of C:\Program Files\dotnet\shared{product}{version} entries where safe and validated
  • CI/CD and build
  • Update <TargetFramework> in project file and run dotnet publish with appropriate -r or --self-contained flags if choosing self‑contained deployment
  • Audit and detection
  • Integrate runtime checks into vulnerability management scans
  • Adjust scanning rules to detect presence of known EOL runtimes and surface them as critical findings

Operational and business considerations​

Testing burden vs. security urgency​

Upgrading runtime versions can introduce behavioral changes — from garbage collector tweaks to JIT differences — that require regression testing. Organizations must balance the risk of leaving a vulnerable runtime in production against the operational cost and complexity of testing and revalidation. Use risk‑based prioritization: internet‑exposed, data‑sensitive, or critical services should be first.

Vendor and third‑party constraints​

Many commercial off‑the‑shelf (COTS) products bundle or require specific .NET versions. Administrators must coordinate with vendors for supported upgrade paths, request fixes, or use compensating controls until vendors provide updated releases.

Legal and compliance implications​

For regulated industries, running unsupported software components can trigger compliance violations. Mitigation plans and documented timelines will help during audits, but long‑term resolution (upgrading or decommissioning) is usually required.

Best practices to prevent future accumulation of outdated runtimes​

  • Adopt a runtime lifecycle policy that mirrors the vendor support policy (favor LTS for production).
  • Enforce publisher updates and patch management that include both OS and runtime patching.
  • Integrate runtime checks and remediation into the SDLC and CI/CD pipelines so that published artifacts do not rely on EOL runtimes.
  • Maintain an internal catalog mapping applications to required runtime versions and owners — this makes coordination faster when an EOL date approaches.
  • Prefer self‑contained or containerized deployment strategies for third‑party apps where vendor updates are slow or unavailable. These approaches push the responsibility for runtime updates upstream to the publisher or into CI pipelines.

Notable limitations and unverifiable claims​

  • Publicly available telemetry on the exact number or percentage of organizations still running specific EOL .NET versions is fragmentary. While security scanning vendors and Microsoft telemetries indicate a meaningful footprint of outdated runtimes across enterprises, any absolute counts cited outside a vendor’s proprietary dataset should be treated as estimates.
  • The operational impact of moving an entire estate off a specific runtime varies dramatically by organization size, mix of third‑party software, and change control maturity. The remediation timelines discussed here are prescriptive guidance; real‑world timelines should be adjusted to reflect local constraints and risk appetites.
  • Some legacy applications may rely on runtime behavior that cannot be easily replicated on newer releases. In those narrow cases, containment or isolation may be the only practical interim remedies until a longer‑term rebuild or replacement is possible.

Conclusion​

Outdated .NET runtimes are no longer an abstract maintenance problem — they are a measurable security and compliance liability. The modern .NET deployment model gives developers flexibility but places the burden of application retargeting squarely on development teams. System administrators must therefore lead with rigorous inventory, prioritized risk assessment, and cross‑team remediation programs: identify which hosts and apps use unsupported runtimes, coordinate upgrades or compensating controls with developers and vendors, verify that no process depends on legacy versions, and then remove obsolete runtimes from production systems.
A clear policy, automated inventory, and a well‑orchestrated remediation cadence will convert scattered, lingering runtimes into a managed, low‑risk part of your Windows infrastructure. Acting now reduces the attack surface, limits audit exposure, and makes future maintenance predictable — all essential outcomes for secure, resilient Windows operations.

Source: Techzine Global Outdated .NET makes Windows environments vulnerable
 

Back
Top