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.

Request migration assessment

Book a call

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

Learn more about our approach

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

Book a call

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

Request assessment

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.

Request assessment

Book a call

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.

Request assessment