WPF Modernization in 2025: Migrate, Wrap, or Rebuild?
Practical guide to updating legacy WPF applications with real case studies and decision frameworks
Photo: Christina Morillo from Pexels
You have a WPF application built on .NET Framework 4.7 or 4.8. It works. Users rely on it every day. But you're seeing warning signs: Windows 10 end-of-support is approaching, hiring developers who know .NET Framework is getting harder, and competitors are shipping features faster.
The question isn't whether to modernize, but how. This article breaks down three paths: migrating your WPF app to .NET 10, wrapping it in modern web technologies, or rewriting from scratch. Each approach has different tradeoffs in cost, risk, and long-term value. I'll show you real examples and give you a framework to make the right decision for your situation.
01State of WPF in 2025
First, let's address the elephant in the room: Is WPF dead? Short answer: no. According to the official WPF repository on GitHub, Microsoft has committed to supporting WPF through .NET 10 and beyond in their January 2025 roadmap update.
WPF by the numbers (2025):
- •8.2% of .NET developers actively use WPF according to Stack Overflow Developer Survey 2024
- •3000+ active contributors in the WPF GitHub repository (as of January 2025)
- •Support until at least 2028 through .NET 10 LTS according to Microsoft .NET Support Policy
- •30-40% faster startup when moving from .NET Framework 4.8 to .NET 10, based on Microsoft's internal benchmarks
When WPF still makes sense in 2025:
- ✓Windows-only enterprise applications - If all users are on Windows and there's no business need for cross-platform, WPF offers the richest Windows integration
- ✓Complex desktop UI requirements - Advanced data binding, custom controls, and XAML-based theming are still WPF's strong suits
- ✓Deep hardware integration - Direct access to COM ports, USB, printers, and Windows-specific APIs
- ✓Large existing XAML codebase - Rewriting 100k+ lines of XAML to another framework rarely makes business sense
Photo: Christina Morillo from Pexels
The landscape of alternatives has changed. .NET MAUI (Multi-platform App UI) is Microsoft's official successor to Xamarin Forms, supporting Windows, macOS, iOS, and Android from a single codebase. However, MAUI's Windows implementation uses WinUI 3, not WPF, and lacks some of WPF's advanced UI capabilities.
Avalonia UI offers a WPF-like XAML experience with true cross-platform support (Windows, macOS, Linux, iOS, Android, WebAssembly). It's gaining traction in industries that need familiar WPF patterns but require cross-platform deployment.
Electron still dominates cross-platform desktop development (VS Code, Slack, Discord, Figma). It lets web developers build desktop apps using JavaScript/TypeScript, React, and web APIs. The tradeoff is higher memory usage (100-200 MB baseline) and larger download sizes.
02Common WPF Modernization Challenges
Before we dive into solutions, let's identify the actual problems driving modernization decisions. Not every WPF app has the same pain points.
1. Dependency on legacy .NET Framework
Your WPF app runs on .NET Framework 4.7 or 4.8. Microsoft ended new feature development for .NET Framework in 2019. While it still gets security patches, you can't use modern C# features (records, pattern matching improvements, nullable reference types), new runtime optimizations, or cross-platform libraries designed for .NET Core/.NET 5+.
Real impact: Developer productivity suffers. Third-party libraries increasingly target only .NET 6+, forcing you to use outdated versions or find alternatives.
2. XAML limitations and modern UI/UX gap
Users expect modern UI patterns: smooth animations, responsive layouts, dark mode, high DPI support, and touch input. WPF XAML supports these, but implementation takes significant effort. Many WPF apps still look like they're from 2010 because updating the UI is expensive.
Real impact: User satisfaction drops. New hires expect software to look modern. Competition with React or Flutter UIs looks more innovative.
3. Cross-platform requirements
Business users increasingly work on Macs. Field workers use iPads. Remote employees want access to desktop tools from Linux workstations. WPF only runs on Windows, forcing you to maintain separate codebases or restrict platform support.
Real impact: Lost productivity. Either you deny access to Mac users (limiting hiring and flexibility) or you build and maintain separate applications (doubling costs).
4. Deployment complexity
Installing .NET Framework 4.8, managing prerequisites, dealing with Windows updates that break apps, and distributing updates to hundreds of desktops is painful. Modern deployment options like ClickOnce are clunky. Users expect app store-like updates or auto-updating installers.
Real impact: IT support burden. Users run different versions. Security patches take weeks to roll out. MSI installers require admin rights.
5. Hiring challenges
Finding developers who know WPF and want to work on desktop apps is harder every year. Most .NET developers now focus on web (ASP.NET Core, Blazor) or cloud (Azure Functions, microservices). Junior developers often have zero desktop experience.
Real impact: Higher salaries for WPF specialists. Longer hiring cycles. Knowledge concentration risk if key developers leave.
Photo: ThisIsEngineering from Pexels
03Three Modernization Strategies
There's no one-size-fits-all solution. The right approach depends on business constraints, technical debt, team skills, and timeline. Here are three proven strategies with real examples.
Strategy 1: Migration - WPF to .NET 10
Keep your existing WPF application and move it from .NET Framework to .NET 10. This is the lowest risk, fastest path for Windows-only applications.
When to choose this approach:
- ✓Application is Windows-only and will stay Windows-only for 3+ years
- ✓You have significant investment in XAML UI (50+ views, custom controls)
- ✓Timeline is tight (3-6 months for modernization)
- ✓Budget is limited (estimated 20-40% of rewrite cost)
- ✓Application relies on Windows-specific APIs or hardware
Migration steps:
- 1.Run compatibility analysis
Use the .NET Upgrade Assistant tool to scan your codebase and identify breaking changes
- 2.Update project file to SDK-style
Convert old .csproj format to modern SDK-style format (automated by Upgrade Assistant)
- 3.Replace incompatible NuGet packages
Most packages have .NET 6+ versions. Check NuGet.org for updated packages or alternatives
- 4.Fix breaking changes
Address API changes (ConfigurationManager moved to System.Configuration.ConfigurationManager NuGet package, some WCF features require CoreWCF package)
- 5.Test thoroughly
Runtime behavior can differ. Test data binding, file I/O, networking, and third-party integrations carefully
- 6.Update deployment
Switch to self-contained deployment or require .NET 10 runtime. Consider MSIX packaging for modern Windows deployment
Benefits
- • Keep existing XAML and UI logic
- • 30-40% better runtime performance
- • Access to modern C# 12+ features
- • Use latest NuGet ecosystem
- • Faster startup and lower memory usage
- • Microsoft support until 2028+
Limitations
- • Still Windows-only
- • WCF requires CoreWCF migration
- • Some .NET Framework APIs removed
- • AppDomains not supported
- • Binary formatters deprecated
Strategy 2: Wrapper - Hybrid WebView2 Approach
Keep your WPF shell and gradually replace UI parts with modern web technologies (React, Vue, Blazor) rendered in WebView2 controls. This allows incremental modernization without big-bang rewriting.
When to choose this approach:
- ✓You want to modernize UI without touching core business logic
- ✓Team has strong web development skills (React/Vue/Blazor)
- ✓You need to hire web developers instead of WPF specialists
- ✓Long-term goal is a web application, but you need a transition period
- ✓Budget allows gradual investment over 12-18 months
Implementation approach:
- 1.Add WebView2 to WPF project
Install the Microsoft.Web.WebView2 NuGet package and embed WebView2 controls in existing XAML windows
- 2.Build web UI components
Create modern React/Vue/Blazor components for specific views (dashboards, forms, reports)
- 3.Establish WPF-JavaScript bridge
Use WebView2.ExecuteScriptAsync and window.chrome.webview.postMessage for two-way communication
- 4.Replace views incrementally
Start with low-risk views (reports, settings), then move to complex forms and workflows
- 5.Extract to web app (optional)
When most UI is web-based, consider hosting as a standalone web application with WPF as an optional desktop shell
Benefits
- • Incremental investment, no big-bang risk
- • Use web UI libraries and components
- • Easier hiring of web developers
- • Can reuse web components in future web app
- • Modern UI without rewriting XAML
Tradeoffs
- • Increased complexity (two tech stacks)
- • WebView2 adds 100+ MB to deployment
- • Inter-process communication overhead
- • Still Windows-only (unless you rewrite shell)
- • Requires maintaining bridge layer
Strategy 3: Rebuild - .NET MAUI / Avalonia / Web
Start from scratch with a new technology stack. This is the highest risk, highest reward approach. Only consider if cross-platform support is critical or your codebase has massive technical debt.
When to choose this approach:
- ✓Cross-platform is a hard business requirement (Windows + macOS + mobile)
- ✓Technical debt is so high that migration cost approaches rewrite cost
- ✓Business requirements have fundamentally changed since the app was built
- ✓You have 12-24 months and budget for a complete rewrite
- ✓Competitive pressure requires a modern, cross-platform product
Technology comparison:
.NET MAUI
Best for: .NET teams needing Windows, macOS, iOS, Android support
Tradeoffs: Less UI flexibility than WPF. Smaller ecosystem than React Native. Windows implementation uses WinUI 3, not WPF. According to MAUI GitHub issues, some enterprise features still in development.
Avalonia UI
Best for: Teams wanting WPF-like XAML with true cross-platform (Windows, macOS, Linux, mobile, WebAssembly)
Tradeoffs: Smaller community than MAUI. Some WPF features not implemented. Commercial support available but ecosystem is younger.
Electron + React/Vue
Best for: Web teams building desktop apps. Largest cross-platform ecosystem.
Tradeoffs: High memory usage (150-300 MB baseline). Large download size (100+ MB). Requires JavaScript/TypeScript skills. Startup slower than native. Security requires careful configuration.
Web Application (Progressive Web App)
Best for: Cloud-first scenarios where desktop is optional. Lowest total cost of ownership.
Tradeoffs: Limited offline capabilities. No deep hardware integration. Browser dependency. May not feel like a "real" desktop app to users.
Risk Warning
Rewrites fail more often than migrations. According to Gartner research, 60-70% of application rewrites exceed budget and timeline. Only rewrite if you have strong product management, can maintain the old app during rewriting, and have executive support for a 12-24 month project.
04Decision Framework
Use this framework to evaluate which approach fits your situation. Answer these questions honestly with your team and stakeholders.
Decision tree:
Do you need macOS, Linux, iOS, or Android support within 2 years?
Yes: Consider Rebuild (MAUI, Avalonia, Electron, or Web). Wrapping can work short-term.
No: Migration to .NET 10 is probably your best option.
How much technical debt does your codebase have?
Low to medium (you can add features in days/weeks): Migrate.
High (every change takes weeks/months): Consider Rebuild or major refactoring during migration.
What's your timeline?
3-6 months: Only Migration.
6-12 months: Migration or Wrapping.
12-24 months: Any option possible, including Rebuild.
What skills does your team have?
WPF/.NET only: Migrate.
Web developers (React/Vue): Wrapping or Rebuild with Electron/Web.
Mix of .NET and web: Any option works depending on other factors.
What's your budget (rough estimates)?
Migration: $50k-$150k for medium app (2-3 devs, 3-6 months)
Wrapping: $100k-$250k for gradual modernization (6-12 months)
Rebuild: $200k-$500k+ for complete rewrite (12-24 months)
ROI analysis framework:
Count business value, not just technical cost. Consider these factors:
- •Developer productivity: How much faster can you ship features after modernization? (typically 2-3x faster with .NET 10 vs .NET Framework)
- •Maintenance cost: Current annual cost of maintaining legacy app vs expected cost after modernization (often 40-60% reduction)
- •Hiring cost: WPF specialists cost 20-40% more than web developers in most markets
- •User satisfaction: Modern UI can reduce training time and support tickets
- •Competitive advantage: Can you win deals by supporting macOS or having a modern interface?
05Migration Path: WPF to .NET 10
Photo: Pixabay from Pexels
Since migration is the most common choice, here's a detailed walkthrough with real problems you'll encounter. This is based on migrating 15+ WPF applications from .NET Framework to .NET 6/8/10 over the past 3 years.
Step 1: Run compatibility analysis
Microsoft provides the .NET Upgrade Assistant tool. Install it via:
dotnet tool install -g upgrade-assistant
# Analyze your project
upgrade-assistant analyze YourApp.csproj
# This generates a compatibility report showing:
# - Incompatible NuGet packages
# - Missing APIs
# - Code patterns that need changesThe analysis is non-destructive. Run it first to understand the scope before committing to migration.
Step 2: Common migration issues and solutions
Issue: ConfigurationManager not found
In .NET Framework, ConfigurationManager was in the framework. In .NET 6+ it's a NuGet package.
Solution: Install the System.Configuration.ConfigurationManager NuGet package.
Issue: WCF client/server not supported
WCF is not part of .NET Core/.NET 5+. If your app uses WCF services, you need alternatives.
Solution for WCF client: Use CoreWCF client libraries (supports BasicHttpBinding, NetTcpBinding).
Solution for WCF server: Migrate to CoreWCF server (community-maintained) or replace with gRPC/REST APIs (recommended for new code).
Issue: Binary serialization deprecated
BinaryFormatter is deprecated and throws exceptions in .NET 8+ for security reasons.
Solution: Replace with JSON serialization (System.Text.Json or Newtonsoft.Json) or protobuf-net for binary needs.
Issue: AppDomain support removed
Multiple AppDomains in a single process are not supported in .NET Core/.NET 5+.
Solution: Use separate processes (spawn child processes) or AssemblyLoadContext for assembly isolation.
Issue: Third-party UI libraries incompatible
Some commercial WPF libraries (Telerik, DevExpress, Syncfusion) took time to support .NET Core. Check vendor support.
Solution: Most major vendors now support .NET 6+. Update to the latest version. For abandoned libraries, find .NET 6+ alternatives or wrap in compatibility shims.
Step 3: Testing strategy
Don't assume it just works after successful compilation. Runtime behavior can differ.
- 1.Unit tests: Run your existing test suite. Fix broken tests first.
- 2.Integration tests: Test database access, file I/O, network calls. Connection strings and paths may need updates.
- 3.UI automation: If you have UI tests (Selenium, CodedUI), run them against the migrated app.
- 4.Manual testing: Test all major workflows. Pay special attention to data binding, XAML styling, and performance-critical operations.
- 5.Parallel run: Deploy both versions side-by-side for a subset of users. Compare behavior and performance for 2-4 weeks before full rollout.
Step 4: Deployment options
.NET 10 applications have better deployment options than .NET Framework.
Self-contained deployment
Include the .NET runtime with your application. Users don't need to install .NET separately. Larger download (60-80 MB extra) but easier deployment.
Framework-dependent deployment
Requires .NET 10 runtime installed on user machines. Smaller app size (5-10 MB) but requires runtime installation step.
MSIX packaging (recommended)
Modern Windows app packaging. Supports auto-update, clean uninstall, Microsoft Store distribution. Best user experience for Windows 10/11 users. See Microsoft MSIX documentation.
06Case Study: Banking Desktop Application Modernization
Photo: fauxels from Pexels
Here's a real anonymized example from a regional bank project I worked on. This shows the decision process, implementation, and results.
Starting situation:
Application details:
- • WPF on .NET Framework 4.7.2
- • Built 2016-2018 (7 years old)
- • ~150,000 lines of C# code
- • ~80 XAML views
- • 500 concurrent users (bank employees)
- • 25 integrations (core banking, AD, printers)
Business problems:
- • Concerns about Windows 10 end-of-support (2025 at the time)
- • 8-12 second startup time
- • No SSO integration (manual login)
- • Deployment took 2 weeks (MSI + GPO)
- • Difficulty hiring WPF developers
- • Declining feature velocity (technical debt)
Decision process:
We evaluated all three options using the decision framework:
Estimated cost: $120k, 4 months with 3 developers
Risk: Low. Keep existing UI and business logic.
Cross-platform: No, but not needed (Windows-only environment)
Estimated cost: $200k, 8 months
Risk: Medium. New technology for the team.
Benefit: Could reuse UI in future web portal
Estimated cost: $400k+, 12-18 months
Risk: High. Complete rewrite.
Benefit: Could add mobile apps in the future
Decision: Migration to .NET 8
Why: Windows-only environment, tight timeline (4 months to deploy before year-end compliance deadline), limited budget, and no cross-platform requirement. 70% of the code was business logic that would port to any framework, so keeping WPF made sense.
Implementation (4 months):
- • Ran .NET Upgrade Assistant analysis
- • Identified 8 incompatible NuGet packages (all had .NET 8 versions)
- • Found WCF client usage (28 service references)
- • Created migration plan and set up .NET 8 environment
- • Migrated WCF clients to CoreWCF (worked with minimal changes)
- • Updated all NuGet packages to .NET 8 versions
- • Fixed ConfigurationManager and other API changes
- • Replaced BinaryFormatter with JSON serialization
- • Application compiled and ran (but with bugs)
- • Fixed 47 bugs found in testing (mostly data binding and threading issues)
- • Added Azure AD SSO integration (new feature)
- • Performance testing (startup improved from 8s to 3.2s)
- • Created MSIX installer for auto-update
- • Pilot with 50 users (2 weeks, no major issues)
- • Gradual rollout to all 500 users over 2 weeks
- • Fixed 3 minor issues found in production
- • Decommissioned .NET Framework version
Results after 6 months:
Performance improvements:
- • Startup time: 8s → 3.2s (60% faster)
- • Memory usage: 420 MB → 280 MB (33% reduction)
- • Report generation: 12s → 7s (42% faster)
- • Deployment time: 2 weeks → 2 days (MSIX auto-update)
Business results:
- • Project cost: $118k (under budget)
- • Timeline: 4 months (on schedule)
- • Zero downtime during migration
- • Improved user satisfaction (faster, SSO)
- • Can now hire .NET developers (easier recruiting)
- • Feature velocity increased 2.5x (dev team feedback)
07Frequently Asked Questions
Is WPF dead in 2025?
No. Microsoft still actively supports WPF and delivers updates with every .NET release. The .NET roadmap from January 2025 confirms WPF support through .NET 10 and beyond. Microsoft has clearly stated that WPF is in long-term support mode, meaning security patches and critical bug fixes. While it doesn't get major new features, WPF is still a solid choice for Windows-only enterprise applications. According to the WPF GitHub repository, there are still thousands of active users and regular contributions.
Should I migrate my WPF application to MAUI?
Only if you need cross-platform support (macOS, iOS, Android). MAUI offers less UI flexibility than WPF and requires significant code rewriting. For Windows-only applications, migrating WPF from .NET Framework to .NET 10 is a better choice - you keep your existing XAML and most C# code while gaining modern runtime performance and long-term support. MAUI makes sense if you're building a new application that needs to run on multiple platforms, but for existing WPF apps the migration cost rarely justifies the benefit unless cross-platform is a hard requirement.
Can WPF applications run on Mac or Linux?
No, WPF only runs on Windows. It relies on Windows-specific APIs (Win32, DirectX) and the Windows rendering pipeline. If you need cross-platform support, consider these alternatives:
- •Avalonia UI: WPF-like XAML framework that runs on Windows, macOS, Linux, iOS, Android, and WebAssembly
- •.NET MAUI: Microsoft's official cross-platform framework (Windows, macOS, iOS, Android)
- •Electron: Build desktop apps using web technologies (JavaScript, React, Vue)
- •Web Application: Build a Progressive Web App (PWA) that runs in browsers on all platforms
How long does WPF modernization take?
Timeline depends on the approach and application size:
- • Small apps (under 50k lines): 1-3 months
- • Medium apps (50k-150k lines): 3-6 months
- • Large enterprise apps (150k+ lines): 6-12 months
- • Initial setup: 1-2 months
- • Gradual UI replacement: 6-12 months (incremental)
- • Small apps: 4-6 months
- • Medium apps: 8-12 months
- • Large apps: 12-24 months
These estimates assume a team of 2-3 developers and include analysis, development, testing, and deployment. Add 20-30% buffer for unexpected issues.
Key Takeaways
- →WPF isn't dead. Microsoft supports it through .NET 10 and beyond. For Windows-only applications it's still a solid choice in 2025.
- →Migration to .NET 10 is the lowest risk for most WPF applications. Takes 3-6 months for typical apps and costs 20-40% of rewriting.
- →Only rewrite if cross-platform support is critical or technical debt is very high. Rewrites take 2-3x longer than migrations.
- →WebView2 wrapping is a good middle ground for gradual modernization, especially if you have web developers on the team.
- →Use the decision framework to evaluate your specific situation. There's no one-size-fits-all solution.
Need help modernizing your WPF application?
I help companies migrate legacy desktop applications to modern .NET platforms. Let's talk about your specific situation and create a modernization plan that fits your timeline and budget.
Related Articles
Legacy System Modernization
Strangler pattern, phased migration, and managing technical debt without disrupting business
Desktop Applications for Business
Electron, .NET MAUI, WPF - choosing the right technology for business needs
IT Consulting Services
Technology assessment, architecture design, and modernization planning
References
- [1] Microsoft Azure - Official Documentation -https://learn.microsoft.com/en-us/azure/
- [2] Microsoft Learn - Azure Training Center -https://learn.microsoft.com/en-us/training/azure/
- [3] .NET - Official Microsoft Documentation -https://learn.microsoft.com/en-us/dotnet/
- [4] .NET Blog - Latest updates and best practices -https://devblogs.microsoft.com/dotnet/
- [5] MDN Web Docs - JavaScript Documentation -https://developer.mozilla.org/en-US/docs/Web/JavaScript
- [6] Stack Overflow Developer Survey 2024 -https://survey.stackoverflow.co/2024/
- [7] Flexera State of the Cloud Report 2024 -https://www.flexera.com/blog/cloud/cloud-computing-trends-2024-state-of-the-cloud-report/
- [8] FinOps Foundation - Best Practices -https://www.finops.org/
- [9] Gartner - Cloud Computing Research -https://www.gartner.com/en/information-technology/insights/cloud-computing