Strategy Scoping
The First Decision

WPF modernization and WPF migration are different projects. Modernization keeps the app on WPF and brings it forward (.NET 10 LTS, Fluent theme, AI tooling). Migration leaves Windows-only for new platforms on a different XAML dialect. They have different scope, budget, risk, and reversibility. Naming which one you are doing is the first decision that matters in 2026.

Why It Matters

Why the Distinction Matters

The single most expensive WPF scoping mistake in 2026 is treating these as the same project. Teams budget for "modernization" and discover three months in that they are halfway through a cross-platform rewrite. Or they budget for a full migration and learn the actual trigger was solvable by upgrading to .NET 10 and turning on the Fluent theme.

The trigger picks the project. The project picks the framework.

ProjectTrigger PatternScopeReversibility
Modernization in place"WPF feels old" / "we are stuck on .NET Framework" / "the UI looks dated"Stay on WPF, upgrade .NET, adopt Fluent and AI toolingHigh: every step is incremental
Migration"We need this on Mac/Linux/web/mobile" / "MSIX deployment is blocking us"Leave Windows-only, adopt a new XAML surface, rebuild platform-specific codeLow: framework choice is sticky

If your trigger is a vibe (the app feels old), you almost certainly need modernization-in-place, not migration. If your trigger is reach (a customer needs Mac), you almost certainly need migration.

In-Place

What Modernization-in-Place Gets You in 2026

Microsoft is still shipping WPF, but the trajectory is maintenance, not active feature growth. The investment curve is flattening release over release. That is enough to make stay-on-WPF a credible 2026 path; it is not enough to call WPF a forward-looking strategy.

  • WPF on .NET 9: Introduced the Fluent theme for Windows 11 aesthetics, light/dark ThemeMode, Windows accent color support, hyphen-based ligature support. .NET 9 is Standard Term Support and reaches end of support on November 10, 2026. It is no longer a realistic target for new modernization work.
  • WPF on .NET 10: Extended Fluent style coverage (DatePicker, GridSplitter, GridView, GroupBox, Hyperlink, Label, NavigationWindow, RichTextBox, TextBox), unified clipboard API, performance improvements. .NET 10 is the current LTS, supported until November 14, 2028. This is the version any 2026 modernization should target.
  • WPF on .NET 11 Preview 3: Bug fixes (DWM crash guard, Fluent backdrop fix on Windows 10, weak event table purge fix). No new features in this preview.
  • GitHub Copilot Modernization: WPF as a first-class project type with upgrade paths from .NET Framework, .NET Core 1.x-3.x, and .NET 5+ to .NET 8 or later.

Concretely, a modernization-in-place project looks like:

  1. Upgrade .NET Framework (or end-of-life .NET versions) to .NET 10 LTS with Copilot Modernization. Do not stop at .NET 9: with end of support on November 10, 2026 and typical WPF modernization timelines measured in months, .NET 9 is a risky target by the time most teams would actually ship.
  2. Apply the Fluent theme via ThemeMode or merging the resource dictionary.
  3. Address BinaryFormatter removal per the WPF migration guide.
  4. Adopt AI-assisted tooling for ongoing development.
  5. Pay down architectural debt as a separate, lower-risk track.

The app stays on Windows. The team stays on WPF. The XAML you wrote two years ago still works.

App.xaml (WPF .NET 9+)
<!-- Apply Fluent theme at the application level -->
<Application.Resources>
  <ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary
          Source="pack://application:,,,/PresentationFramework.Fluent;component/Themes/Fluent.xaml" />
    </ResourceDictionary.MergedDictionaries>
  </ResourceDictionary>
</Application.Resources>
Only Migration

What Only Migration Solves

Modernization-in-place cannot solve any of the following. If your trigger is on this list, you are doing migration.

Cross-platform reach. WPF only runs on Windows. macOS, Linux, iOS, Android, and browser delivery all require a different framework.

Browser delivery. WebAssembly removes installer friction for many app categories. WPF does not target the browser.

Mobile tier reuse. Sharing ViewModels, services, and a substantial portion of XAML with iOS and Android requires a cross-platform framework. A practical caveat: most WPF line-of-business apps are forms-over-data with no service or API layer. The data access lives directly behind the UI. Cross-platform reuse depends on first extracting that layer, and that extraction work is a real (and often understated) line item in any cross-platform business case.

MSIX or installer fatigue. When deployment is the bottleneck, browser or per-platform stores often beat fixing MSIX.

Hardware that is not Windows. Linux desktops, kiosk devices, and embedded targets run a different runtime story.

If none of these apply, you do not need migration. You need modernization.

Cost & Risk

Cost and Risk Profile

DimensionModernization in PlaceMigration
Typical effortDays to a few weeks per upgrade phase2 to 18 months depending on size and platform breadth
ToolingCopilot Modernization, .NET upgrade toolsCross-platform framework, agentic dev loop, runtime verification
Risk profileLow: every step ships independentlyMedium to high: framework choice is sticky
Team changeSame team, same skillsSame .NET skills, new XAML dialect, new platform-specific code
ReversibilityHighLow once the new XAML surface is adopted

Migration is not always more expensive in total, but it is always more expensive to course-correct. That is why naming the project up front matters.

The 2026 Shift

Migration is more expensive than modernization, but the gap has narrowed sharply. AI-assisted dev now absorbs a large share of the mechanical work (namespace swaps, binding rewrites, control mapping, boilerplate XAML translation). What used to be the dominant cost line is now compressed. The cost of "more expensive" is no longer the cost it was. See .NET Agent Skills and Migrate Your First WPF Screen with AI Agents for the pattern.

Decide

How to Decide This Week

Three questions, in order:

  1. Is there a real platform-reach trigger? A specific customer asking for Mac. A regulatory requirement to ship on Linux. A product mandate to deliver via the browser. If the answer is no, you are doing modernization.
  2. Is there a real deployment trigger? MSIX is blocking enterprise rollout. Per-machine install is blocking inside-the-firewall adoption. If yes, that justifies migration. If no, modernization.
  3. Is there a tooling or talent trigger? New hires expect Hot Reload, runtime designers, AI-assisted dev. Modernization can deliver Hot Reload and Copilot. Runtime visual designers across platforms (e.g., Hot Design) and runtime verification via MCPs require a framework that ships them. This sometimes tips the answer toward migration, but rarely on its own.

If two or three of these are yes, migration. If only one is yes and it is the third, run a 2-week pilot before committing.

Stay on WPF

What "Stay on WPF" Looks Like in 2026

For many WPF applications in production today, the right answer is to stay on WPF. The case is straightforward, with one honest caveat:

  • WPF is being shipped, but the trajectory is maintenance. .NET 9 added the Fluent theme. .NET 10 (LTS, supported until November 2028) extended Fluent coverage and added clipboard and performance work. .NET 11 Preview 3 is bug fixes only. Treat WPF as supported and stable, not as a roadmap framework.
  • The tooling story has caught up. Visual Studio Hot Reload, Copilot Modernization, and the Live Visual Tree all support WPF.
  • The Fluent theme closes most of the visual-modernization complaint.
  • The .NET 10 LTS upgrade closes the security and performance complaints for the next two-plus years.

If you do not have a platform-reach or deployment trigger, modernization-in-place is the cheapest, lowest-risk answer. Spend the migration budget on architectural debt instead.

Migrate

What "Migrate" Looks Like in 2026

If migration is the right call, the credible 2026 targets are WinUI 3 (Windows-only modernization to a new XAML), Uno Platform (cross-platform on the WinUI 3 API surface across six platforms), independent cross-platform XAML stacks (with their own dialects and optional commercial WPF-compatibility forks), and .NET MAUI for mobile-first apps that do not need Linux.

The full comparison table and decision tree are in the companion article: WPF Modernization in 2026: A Source-Backed Decision Guide.

Get Started

If you are leaning migration, port one representative screen end-to-end using the agentic dev loop (Migrate Your First WPF Screen with AI Agents) before committing to a framework.

Sources & References