WPF TO AVALONIA XPF

Add macOS and Linux support to your existing WPF application

Extend your existing WPF application using Avalonia XPF. Reuse your UI layer and most of your .NET logic, without rebuilding the system.
Learn more about Avalonia XPF

"Our engagement with UXDivers was highly professional and efficient. The team demonstrated a strong ability to rapidly understand our requirements, maintained an excellent pace of execution, and delivered high-quality outcomes that supported informed and confident decision-making."

Priyanka Patil
Engineering Leader
See how we approach migrations
CUSTOMER STORIES

Trusted by teams building cross-platform experiences

Real teams. Real results. Built with Avalonia.

"UXDivers quickly understood our requirements and delivered results that drove confident decision-making"

Priyanka Patil
Engineering Leader, Bridgestone

“UXDivers is by far the best visual designers I’ve seen within the .NET development ecosystem. Their applications are stunning”

Louise Jackson
Product Manager, HAMELIN

"No one outside the Avalonia team handles these migrations better than UXDivers"

Mike James
CEO, Avalonia
Good fit
Ideal for most business applications
Proven patters, cross-platform ready, and easy to maintain.
Mature WPF codebase
MVVM or MVVM-like architecture
Limited Win32 / PInvoke usage
Clear need for macOS or Linux support
Stable UI patterns
Requires assessment
Complexities that may requiere extra effort
These factors can add complexity or impact timelines.
Heavy third-party controls (DevExpress, Telerik, Syncfusion)
DirectX or custom rendering
COM / ActiveX integrations
Tight Windows API coupling
OS-level dependencies
Migration paths

Choosing a migration path

Choosing a migration path is not a framework decision. It is a trade-off between rewrite cost, platform reach, and engineering risk.
Full Rewrite
Rebuild everything
Stay on WPF
Maintain and extend
XPF Migration
Incremental modernization
Estimated timeline
12–24 months
N/A
3–6 months
XAML reuse
0–10%
100%
70–90%
ViewModel reuse
Low
Full
High
Third-party controls
Replace
No change
Partial compatibility
Windows-specific APIs
Rewrite
No change
Must be isolated
Target runtimes
Cross-platform
Windows only
Windows, macOS, Linux
Regression risk
High
None
No risk
Development constraints
High
None
Acceptable
Initial cost
High
Low
Acceptable
Long-term flexibility
High
Low
Very good
Key differentiation

Why teams don't handle this migration in-house

WPF to XPF migrations are not difficult because of XAML. They are difficult because of everything around it.
We identify risks early
Most teams underestimate Windows-specific dependencies, control limitations, and rendering constraints. We focus on identifying these early.
We avoid unnecessary rewrites
We maximize reuse of existing XAML and ViewModels, and isolate only what needs to change.
We keep your product moving
We structure migrations so they can run in parallel with ongoing development, avoiding roadmap disruption.
We handle edge cases
The complexity is rarely in the main flow. It's in controls, integrations, and edge scenarios.
Process

Our approach

Each migration is structured to surface risk early and preserve as much of the existing codebase as possible.
Discovery

Technical assessment

Identify dependencies, risks, and constraints early. We analyse your codebase for Win32 usage, PInvoke calls, COM interop, and third-party control coverage before writing a single line of migration code.
Planning

Migration roadmap

Define what can be reused, what needs to change, and in what order. We produce a structured plan with effort estimates and clear risk areas before any implementation begins.
Validation

XPF proof of concept

Validate feasibility on target platforms with a constrained, representative slice of your application. This surfaces real-world incompatibilities early, before full migration scope is committed.
Execution

Implementation and stabilisation

Execute the migration incrementally, isolating Windows-specific APIs, replacing incompatible dependencies, and stabilising platform behaviour across Windows, macOS, and Linux.
Primary conversion

Request a WPF migration assessment

Share a few details about your application. We'll respond with a technical perspective.
No commitment required
Response within 24 hours
Initial assessment is free
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Support

Frequently asked questions

Can WPF applications run on macOS or Linux?
No. WPF is built on top of Win32 and DirectX, which are Windows-exclusive. It has no native support for macOS or Linux. Avalonia XPF provides a compatibility layer that allows WPF-based applications to run on those platforms by reimplementing the WPF rendering pipeline on top of Avalonia.
Do we need to rewrite the entire application?
Not necessarily. Avalonia XPF is designed to maximize XAML and ViewModel reuse. In practice, most teams can preserve 70–90% of their existing code. The effort is concentrated on isolating Windows-specific APIs, PInvoke calls, COM interop, and third-party control compatibility — not rewriting business logic or UI structure.
What are the main risks in a WPF to XPF migration?
The primary risks are: (1) undiscovered Win32 and COM dependencies that break at runtime on non-Windows targets, (2) third-party controls with no Avalonia-compatible equivalent, (3) custom rendering or DirectX usage that cannot be ported directly, and (4) runtime behavior differences between WPF and Avalonia XPF in edge cases. Early dependency analysis reduces most of these risks.
How much code can be reused?
XAML reuse typically ranges from 70–90% depending on the complexity of controls, custom templates, and attached behaviors used. ViewModels and business logic in pure .NET are generally fully reusable. Code tied to Windows APIs, system dialogs, or OS-level integrations must be abstracted or replaced.
When is a full rewrite a better option?
A full rewrite becomes more practical when the codebase has significant Win32 coupling throughout, relies heavily on unsupported third-party controls, uses custom DirectX rendering, or when the team wants to modernize the architecture in addition to changing the platform. For large, stable WPF codebases with MVVM patterns and limited Windows-API dependencies, XPF migration is almost always the faster path.

Still unsure?

We'll review your application setup and share a technical perspective, no commitment required.