A WPF migration takes as long as your three driver variables make it take: architectural complexity, platform-specific dependencies, and third-party control surface. This guide gives pattern-level effort estimates calibrated to a real WPF migration (Text-Grab: 84 C# files, 15 windows, WPF-UI controls, classic MVVM) so you can quote, scope, or budget without guessing. With AI-assisted tooling, mechanical translation runs roughly 60 to 70 percent faster than fully manual migration.
The Three Variables That Drive Every WPF Migration Estimate
1. Architectural Complexity
How many windows does the app have? How much logic lives in code-behind vs. ViewModels? Are services injected via DI or referenced as static singletons?
A clean MVVM app with constructor-injected services migrates in a fraction of the time of a code-behind-heavy app with App.Current.Services calls scattered through XAML event handlers.
2. Platform-Specific Dependencies
Each Windows-only API in your WPF app needs an abstraction layer (typically IPlatformService interfaces with platform-specific implementations under #if WINDOWS). Common ones: screen capture, hotkey registration, OCR, clipboard integration beyond standard text, file system watchers, shell integration (jump lists, taskbar progress), P/Invoke calls into Win32.
Each of these takes real engineering time. Count them honestly before quoting.
3. Third-Party Control Surface
| Control Source | Migration Effort |
|---|---|
| Standard WPF controls | Mechanical: namespace and minor property differences |
| WPF-UI / open-source theming | Light: most patterns map to WinUI surface or Uno Toolkit |
| Commercial suites (DevExpress, Telerik, Syncfusion) | Variable: needs replacement with WinUI/Uno-compatible equivalents; effort depends on which controls are used |
Commercial control suites are the single biggest source of estimate variance. Audit them first.
Pattern-Level Effort Table
All estimates assume AI-agent assistance for mechanical translation. AI coverage is the percentage the agent handles reliably with a documentation MCP grounded in current Uno Platform docs.
XAML Translation Patterns
| Pattern | Effort | AI Coverage | Notes |
|---|---|---|---|
Namespace swap (clr-namespace: to using:) | Minutes | ~100% | Fully mechanical |
Binding syntax ({Binding} to {x:Bind}) | 5-15 min/page | ~90% | Human verifies Mode, UpdateSourceTrigger |
DynamicResource to ThemeResource | Minutes | ~100% | Fully mechanical |
| Standard control mapping | Minutes/page | ~95% | Watch for property differences |
| Window to Page | 1-2 hours/window | ~60% | Architectural decision per window |
| Resource dictionaries | 30-60 min/dictionary | ~80% | Theme keys differ; verify against Uno Toolkit |
| Styles and ControlTemplates | 1-3 hours/control | ~50% | Custom templates often touch moved namespaces |
Code-Behind and MVVM Patterns
| Pattern | Effort | AI Coverage | Notes |
|---|---|---|---|
| INotifyPropertyChanged ViewModels | Mechanical | ~95% | CommunityToolkit.Mvvm or hand-rolled both work |
| ICommand to RelayCommand | Minutes/command | ~95% | Same pattern across both frameworks |
Dispatcher.Invoke to DispatcherQueue | 10-20 min/call site | ~85% | Re-review threading semantics |
| Event handlers in code-behind | Variable | ~50% | Architectural opportunity: convert to commands |
| App.xaml.cs startup to IHostBuilder | 2-4 hours | ~70% | One-time cost per project |
Platform-Specific Code
| Pattern | Effort | AI Coverage | Notes |
|---|---|---|---|
| Define IPlatformService abstraction | 30-60 min/service | ~70% | Agent generates skeleton, human owns interface |
| Implement Windows version | Same as original | ~80% | Lift existing logic behind the interface |
| Implement non-Windows versions | Variable per platform | ~30% | Real engineering: alternative APIs or graceful no-op |
| P/Invoke replacement or guard | Variable | ~40% | Some have .NET equivalents; some need conditional compilation |
| File system, clipboard, settings | 1-2 hours/service | ~70% | Use Uno Extensions Storage/Settings where possible |
Third-Party Control Replacement
| Pattern | Effort | AI Coverage | Notes |
|---|---|---|---|
| WPF-UI / open-source themes | Minutes | ~80% | Map to Uno Toolkit or Material |
| DevExpress / Telerik / Syncfusion grid | Hours to days/usage | ~30% | Replace with ItemsRepeater + custom layout, or commercial WinUI suite |
| Custom user controls (your own) | Same as page-level | ~70% | Treat as sub-projects |
A Worked Example: Text-Grab
Text-Grab is a public WPF utility with 84 C# files, 15 windows, WPF-UI controls, and classic MVVM. The migration to Uno Platform was executed in seven phases with AI-agent assistance.
| Phase | Scope | Effort | Notes |
|---|---|---|---|
| 1. Project setup | New Uno solution, dependency port, CI green on Windows | 1 week | Fixed cost |
| 2. ViewModels and services | Lift INotifyPropertyChanged types and core services | 1 week | Mostly clean; DI wiring |
| 3. XAML translation | 15 windows to pages with namespace and binding swaps | 2 weeks | Heavy AI assist |
| 4. Platform abstractions | Screen capture, hotkeys, OCR behind IPlatformService | 2 weeks | The hard part |
| 5. Theme and styles | WPF-UI theme to Uno Toolkit equivalents | 1 week | Visual verification |
| 6. Cross-target build-out | WASM and macOS builds passing | 1 week | Per-platform issues |
| 7. Verification and polish | Visual diffs, UAT, performance | 1 week | Designer + QA pass |
Total: roughly 9 engineer-weeks for an 84-file, 15-window WPF app with screen capture, hotkeys, and OCR, using AI agent assistance.
If your codebase is half that size with no platform-specific code and no commercial controls, halve the estimate. If it has 200 files, 50 windows, deep DevExpress integration, and heavy P/Invoke, multiply by 3 to 5.
Calibrating to Your Codebase
Use this back-of-envelope worksheet before quoting:
A. Architectural baseline
Count of windows / pages: ____
Estimated XAML hours = (count) * 2 hours
B. Platform-specific code
Count of Windows-only APIs in use: ____
Estimated abstraction hours = (count) * 6 hours
(1-2h interface, 1-2h Windows impl, 2-4h non-Windows impl)
C. Third-party controls
List each commercial control suite usage: ____
Estimated replacement hours per usage:
- Standard control replacement: 2 hours
- DataGrid/charting/scheduling: 1-3 days each
Total = sum of above
D. ViewModel and service port
Count of ViewModel + service files: ____
Estimated hours = (count) * 1 hour (assumes clean MVVM)
E. Fixed costs
Project setup, CI, theme port, verification: 80-120 hours
Total engineer hours = A + B + C + D + E
Apply your shop's overhead multiplier.This is a planning estimate, not a fixed-price quote. Validate by porting one representative screen end-to-end before committing to a number.
What to Do Before You Quote
- Audit the codebase honestly. Run
git ls-files | wc -lfor .cs and .xaml. Count windows. List Windows-only APIs. List commercial controls. - Pilot one screen. Use the agentic dev loop to migrate one representative page end-to-end. Measure actual hours.
- Multiply by your codebase ratio. If the pilot took 8 hours and your app has 30 pages, your XAML budget is roughly 240 hours plus overhead. Add platform-specific code and third-party control work on top.
- Add a 25 to 40 percent contingency. Migration always uncovers something. Be honest with the client or sponsor.
Run a 2-week pilot on one screen using the agentic dev loop. Start a free trial of Uno Platform Studio Pro for the App MCP runtime verification alongside the Docs MCP. Use the worksheet above to extrapolate. For incremental migration without a full project rewrite, see Uno Islands.
Subscribe to Our Blog 
Subscribe via RSS
Back to Top