"We needed macOS support, but rewriting was not an option. The real challenge was isolating Windows-specific dependencies without breaking existing workflows."
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.
