- WPF migration to Uno Platform is a view-layer modernization, not a rewrite. Business logic, ViewModels, and data access are 85-100% portable.
- Effort concentrates in XAML, third-party UI libraries, and platform-specific APIs. These are the axes worth measuring.
- The official Uno Platform WPF migration guidance explicitly calls out navigation, async APIs, and custom controls as the zones that need upfront research.
- A defensible estimate comes from a bottom-up model (file count, dependency count, platform coupling), not a top-down "it feels like six months."
Who this is for: Tech leads and agency principals scoping a WPF-to-Uno migration for a CFO or exec decision.
Scoping a WPF migration is where most modernization projects quietly fail. A tech lead gives a gut-feel estimate, a CFO accepts it, and six months later nobody agrees on what "done" means. This article offers a framework you can defend: six scoping axes, a 30-minute worksheet, and a phased plan you can translate into a budget.
Why WPF Migration Estimates Are Usually Wrong
WPF estimates fail for a predictable reason: teams estimate by analogy ("last migration took four months") instead of by surface area. Analogies collapse when two apps have the same window count but one uses DevExpress and the other uses stock controls, or when one app has a single P/Invoke call and the other has thirty.
The Uno Platform migration guidance is explicit that the "vast majority of your codebase will simply move across." Existing XAML structure, business logic, and view models reuse directly. The zones requiring research upfront are navigation, advanced binding, async-only modern APIs, and framework-specific capabilities. That framing tells you where to spend your estimation budget: not on the 80% that "just moves across," but on the 20% where decisions get made.
On AI-assisted migration: AI agents are shifting the cost curve in ways that are still being measured. A published Uno Platform walkthrough demonstrates the AI-assisted approach screen by screen. Practically, mechanical work gets faster; architectural work does not. Treat any "N times faster" claim as directional until your own benchmarks confirm it.
The Six Scoping Axes
Every WPF migration estimate should sit on top of six measurable inputs. These are the axes that move the number.
1Windows and Pages: Count and Complexity
Count every top-level Window, UserControl used as a screen, and dialog. Classify each as Simple (form, list, detail), Medium (composite layout, multiple bound regions), or Complex (custom rendering, canvas overlays, nested tabs). Pages are the unit of work most migrations plan around because each one gets rebuilt as an Uno Page or navigation region.
The Uno WPF migration guidance flags navigation as one of the zones that "contains substantial enough differences from WPF to require extra research upfront." Multi-window WPF apps converge to a single-window NavigationView shell in Uno Platform. That rearchitecture is an axis in its own right.
2Control Inventory and Third-Party Dependencies
List every non-standard control in your XAML. Standard WPF controls (Grid, StackPanel, TextBox, Button, ListView, ComboBox, Border, Canvas, ScrollViewer, UserControl) have direct WinUI equivalents and are near-zero effort. Third-party UI libraries are where effort concentrates.
Xaml.Behaviors.Wpf is a low-effort swap. Extended.Wpf.Toolkit is a medium-effort control-by-control mapping. MahApps.Metro, MaterialDesignInXaml, and iNKORE.UI.WPF.Modern require full replacement with Uno Material plus Uno Toolkit.
The DataGrid is the most common control with no built-in WinUI equivalent. It requires the CommunityToolkit.WinUI.Controls.DataGrid package (7.x; removed in 8.x) and some feature mapping. If your app is DataGrid-heavy, that single axis can add meaningful effort.
3Settings and Configuration Surface
WPF apps tend to store configuration in Properties.Settings.Default, App.config, or ad-hoc XML. Uno Platform's settings pattern is IWritableOptions backed by appsettings.json via Uno.Extensions.Configuration. The migration is mechanical but cascading. Every place that reads or writes settings needs to be updated, and if settings were previously synchronous, the new async patterns may ripple.
Count settings keys and the call sites that touch them. Two dozen keys read from three places is low effort. Two hundred keys written from random corners of the codebase is a project in itself.
4Platform Coupling (Win32 P/Invoke, Registry, WMI, COM)
This is the axis that most often blows up estimates. Every P/Invoke call, every registry read, every WMI query, and every COM interop surface requires abstraction behind an interface plus a platform-specific implementation (or a conditional-compilation path).
Search your codebase for DllImport, Registry., ManagementObjectSearcher, and ComImport. Each hit is an axis entry. A handful is manageable. Deep shell integration (system tray, global hotkeys, file indexing) is a signal to consider partial migration with Uno Islands rather than full port.
5Test Coverage (Forward-Portable vs. Net-New)
Unit tests against ViewModels and services port directly. The business logic layer is platform-agnostic. UI tests against WPF's automation tree do not port. Count your current test suite, bucket it by layer, and assume the UI test layer is net-new work.
6Target Platforms (Windows-Only vs. Full Reach)
Migrating to Uno Platform to stay Windows-only is a smaller scope than migrating to reach Web, Android, iOS, and macOS. Each additional target adds verification work, platform-specific code paths, and QA surface.
The Scoping Worksheet
Walk through this worksheet for 30 minutes with your senior engineer. Score each axis; sum the multipliers; apply to a baseline.
| Axis | Input | Low (1x) | Medium (2x) | High (3x+) |
|---|---|---|---|---|
| Windows/Pages count | Count top-level windows + page-level user controls | Under 10 | 10 to 30 | 30+ |
| Page complexity | Share of pages with custom rendering, canvas, nested tabs | Under 10% | 10 to 30% | 30%+ |
| Third-party UI library | Identify primary UI library | None or behaviors only | Extended.Wpf.Toolkit, WPF-UI | MahApps, MaterialDesign, Telerik, DevExpress |
| DataGrid usage | Is DataGrid the central control? | No | One or two screens | Central to most screens |
| Multi-window architecture | How many standalone windows? | 1 to 2 | 3 to 5 | 6+ |
| Settings surface | Count of settings keys + call sites | Under 20 keys | 20 to 100 | 100+ or scattered |
| Platform coupling | P/Invoke + Registry + WMI + COM call sites | 0 to 3 | 4 to 15 | 16+ or shell integration |
| Test coverage | Forward-portable test ratio | UI tests minimal | Mixed | UI-heavy |
| Target platforms | Uno targets beyond Windows | Windows only | +1 target (Web or macOS) | Full five heads |
How to use: Assign a multiplier per axis. The baseline is "namespace changes, Window to Page conversion, basic control mapping," the Tier 1 mechanical work Uno Platform migration guidance consistently flags as automatable. Multipliers stack: a 30-page app with MahApps and heavy P/Invoke is not 3x baseline. Conservative teams use additive stacking inside each cluster and multiplicative across clusters. Treat this as a working heuristic for scoping conversations, not a calibrated estimation model.
Translating the Estimate Into a Phased Plan
Once the worksheet gives you a relative-effort number, convert it to a phased calendar. Each phase produces a running build. No "big bang" cutover. That is the single biggest risk-reduction lever in a migration plan, and it is also how you write a contract that lets a CFO see progress monthly.
| Phase | Scope | Why It Goes Here |
|---|---|---|
| 0 | Assessment, dependency audit, starter kit setup | Before a single line of code moves, you need the inventory |
| 1 | Project setup, shell architecture, first page | First page seeds every subsequent page's patterns |
| 2 | Core feature pages | The screens your users spend the most time on |
| 3 | Settings migration (IWritableOptions) | Migrate once, reference from every page |
| 4 | Remaining pages | The long tail, mechanical once patterns are set |
| 5 | Navigation restructure, theme polish | Only makes sense once all pages exist |
| 6 | Platform service abstraction | Interfaces now, implementations per platform |
| 7 | Localization, cleanup, QA | Last, because it touches every string |
Red Flags That Double the Estimate
Watch for these during your 30-minute worksheet pass. Each one is a signal to add contingency, not a dealbreaker.
- Deep shell integration. System tray, global hotkeys, file indexing, start-menu integration. Uno Islands for a partial migration may be a better strategy than a full port.
- Commercial control suites (Telerik, DevExpress). No direct Uno equivalent. Requires control-by-control replacement.
- ICollectionView for filter/sort/group. No direct Uno equivalent. The recommended replacement is LINQ plus
ObservableCollectionorAdvancedCollectionView, which cascades into ViewModel changes. - Synchronous file dialogs everywhere. WPF's
OpenFileDialog.ShowDialog()is synchronous. Uno'sFileOpenPicker.PickSingleFileAsync()is async. Every caller becomes async. The cascade is usually bigger than it looks. - Multi-window architectures with implicit state sharing. If windows share state through static singletons, that architecture needs a rethink on top of the navigation rework.
- WCF or WCF Data Services. Full WCF support is not part of modern .NET. The Uno WPF migration guidance explicitly flags this as a deprecated technology to plan around.
Stacking rule: When two or more red flags stack, the honest conversation with your CFO is about contingency reserve, not about cancellation. A 30-40% contingency buffer on a migration with two red flags is defensible. Anything less is optimistic.
FAQ
Can I quote a fixed-price WPF migration?
Only for apps that score Low on every axis in the worksheet. Anything with a third-party UI library, heavy P/Invoke, or a multi-window architecture deserves time-and-materials with a capped contingency, not fixed price.
How much faster is AI-assisted migration in practice?
Mechanical work gets faster (namespace swaps, binding syntax, control remapping). Architectural work does not (window-to-page decisions, platform abstraction design, debugging silent XAML failures). The AI-assisted migration walkthrough is public, and the MCP tooling is documented. No public multiplier available as of April 2026.
What percentage of a WPF app is typically carried forward as-is?
The Uno Platform migration guidance states that the "vast majority" of the codebase moves across. Business logic and ViewModel portability runs 85-100%. The cost concentrates in XAML views (30-60% requires rework), third-party UI libraries, and platform-specific APIs.
Where should I start: hardest screen or easiest?
Easiest. The first page seeds every subsequent page's patterns (namespace conventions, shell structure, theme overrides). Starting with the hardest screen means you debug platform patterns and UX complexity at the same time.
If the worksheet gave you a number you can defend to your CFO, the next step is to map your app to the official WPF-to-Uno migration guide. It covers the architecture considerations (MVVM libraries, navigation, custom controls, data access) that your estimate depends on. For teams planning to pair this with AI assistance, the Claude Code setup guide and the Uno MCP documentation cover the tooling baseline.
Subscribe to Our Blog 
Subscribe via RSS
Back to Top