If you are budgeting a Xamarin to .NET MAUI migration in 2026, the honest answer is that there is no fixed price — and any vendor who gives you one before looking at your code is guessing. The cost is driven almost entirely by how much custom UI and platform-specific code your app carries, not by its screen count. The good news, straight from Microsoft’s own guidance, is that you do not need to rewrite the app: projects need to become SDK-style, but business logic, view models, and services largely move across intact. The effort — and the budget — concentrates in three places: custom renderers that must be rewritten as handlers, third-party dependencies with no .NET MAUI equivalent, and platform-specific native code. This guide explains each driver so you can scope the work before anyone quotes you.
Why there is no single price for a Xamarin migration
Two Xamarin.Forms apps with the same number of screens can differ in migration effort by an order of magnitude. A screen that uses stock controls and data binding moves across almost mechanically. A screen backed by three custom renderers, a platform-specific effect, and a dependency that was abandoned in 2021 is a bespoke engineering problem.
That is why “cost per screen” estimates are misleading. The unit of work in a migration is not the screen — it is the amount of custom and platform-coupled code behind it. Scope that, and you can scope the budget.
The single best predictor of effort: custom renderers
In Xamarin.Forms, when a stock control could not do what you needed, you wrote a custom renderer — platform-specific code that reached into the native control. .NET MAUI replaces the renderer architecture with handlers, which are leaner and decoupled by design but different enough that renderers do not port automatically.
Every custom renderer in your codebase is a unit of manual work: it has to be re-implemented as a handler (or mapped onto MAUI’s handler customization model) and then validated on each platform. If you want one number to sanity-check a migration estimate, count your custom renderers. An app with a handful is a different project from one with fifty.
What the .NET Upgrade Assistant actually does
Microsoft ships a free tool, the .NET Upgrade Assistant, a command-line utility that upgrades multi-project Xamarin.Forms apps to multi-project .NET MAUI apps. It handles the mechanical conversion — project files to SDK-style, namespace and package changes, and the scaffolding of the MAUI structure.
It is genuinely useful, and it is not a finished migration. Microsoft’s own documentation states that after running the tool, in most cases the app will require additional effort to complete the upgrade. The Upgrade Assistant clears the repetitive work; it does not resolve custom renderers, broken dependencies, or the runtime behaviour that only surfaces on a device. Budget for the tool to accelerate the start, not to deliver the finish.
Third-party dependencies: the estimate’s biggest wildcard
The second cost driver is your dependency list. Every NuGet package and Xamarin plugin falls into one of three buckets:
- Has a .NET MAUI version — usually a version bump and minor API changes.
- Has a community or first-party successor — a swap plus integration work.
- Is abandoned with no equivalent — the expensive case, where you either reimplement the capability or find and integrate a replacement.
The third bucket is where migration budgets overrun, because the work is discovered mid-project rather than estimated up front. A dependency audit before the quote turns this wildcard into a line item.
The hidden cost: silent runtime failures
The most dangerous migration cost is the one a compiler never shows you. A well-known failure mode in automated Xamarin migrations is the silent runtime failure: the project compiles, the IDE reports no errors, the app deploys to a device — and then misbehaves or crashes on launch with no stack trace. The break lives in the runtime behaviour of platform handlers, lifecycle events, and dependency-injection wiring that the migration rewrote without fully preserving the original intent.
This is why device QA is not optional and cannot be skipped to save budget. Everything a compiler or an AI agent can check may pass while the app is still broken in the hands of users. We covered this pattern in more depth in AI technical debt in mobile.
A self-assessment to scope your migration
Before you ask for a quote, answer these. Each “yes” or higher count moves you up the effort scale:
- Custom renderers — how many? (None / a few / dozens.)
- Platform-specific code — effects, native bindings,
DependencyServiceimplementations? (Rare / common / everywhere.) - Third-party dependencies — how many, and how many are still maintained? (Few and current / several / many and some abandoned.)
- Test coverage — do you have automated tests that can catch a regression? (Good / thin / none.)
- Original team — is anyone who understands the app still available? (Yes / partially / no — see below.)
- UWP / Windows — do you ship a Windows target that must move to WinUI 3? (No / yes.)
An app that scores low across the board is a matter of weeks. An app that scores high — many custom renderers, abandoned dependencies, no tests, no original team — is a multi-month engineering project, and its budget should reflect the discovery required to de-risk it.
Fixed price or time-and-materials?
A fixed price is only safe when the unknowns have already been removed. That means a discovery pass — a custom-renderer inventory, a dependency audit, and a device-behaviour smoke test — has been done first. Quote a complex or poorly documented app fixed-price without that, and the estimate is carrying risk you cannot see.
The lower-risk structure for most enterprise migrations is a capped discovery phase first, producing a scoped plan and a defensible estimate, followed by the migration itself. You pay for certainty before you pay for volume.
If the original team is gone
Many 2026 Xamarin apps have outlived the people who built them. If no one can explain why a screen behaves the way it does, migration turns into archaeology — and the risk is that a “faithful” migration faithfully reproduces bugs or drops undocumented behaviour that a user depended on.
The fix is to recover the product model before you migrate the code. We wrote the method up in recovering product knowledge from a legacy repository and the companion legacy repository discovery checklist. Do that first, and the migration estimate stops hiding a discovery problem inside a coding budget.
What we would need to quote your migration
If you want a defensible number rather than a guess, we would start from your custom-renderer count, your dependency list, your Windows/UWP status, and your test coverage — then run a short discovery pass to confirm the runtime unknowns. That produces a scoped plan and an estimate you can take to a budget owner.
If you are weighing whether to migrate at all, read the companion piece on your realistic options if you are still on Xamarin in 2026. If you already know you are migrating and want it scoped properly, book a 20-minute call or look at how we work.
FAQ
How much does a Xamarin to .NET MAUI migration cost? There is no fixed price, because effort is driven by app complexity rather than screen count alone. The largest cost drivers are the number of custom renderers that must be rewritten as handlers, third-party dependencies that have no .NET MAUI equivalent, and platform-specific native code. A small app with few custom renderers is typically a matter of weeks; a large enterprise app with many custom renderers and abandoned dependencies can run to several months. Scope the drivers before asking for a quote.
Do I have to rewrite my Xamarin app to move to .NET MAUI? No. Microsoft’s official guidance is that projects need to become SDK-style, but they do not need to be rewritten, and multi-project solutions do not need to become a single project. Most business logic, view models, and services move across with little change. The effort concentrates in the UI layer and platform-specific code.
What does the .NET Upgrade Assistant do in a Xamarin migration? The .NET Upgrade Assistant is a command-line tool that upgrades multi-project Xamarin.Forms apps to multi-project .NET MAUI apps. It automates the mechanical parts of the conversion, but Microsoft states that in most cases the app will require additional effort to complete the upgrade. Treat it as a starting point, not a finished migration.
Is a fixed-price or time-and-materials contract better for a Xamarin migration? It depends on how well the app is understood up front. A fixed price is only safe after a discovery pass that inventories custom renderers, dependencies, and platform code; without that, the estimate carries the risk of the unknowns. A time-and-materials engagement with a capped discovery phase first is usually the lower-risk structure for a complex or poorly documented app.
Sources (accessed 14 July 2026):
- Microsoft, Xamarin support policy — end of support 1 May 2024.
- Microsoft Learn, Upgrade from Xamarin to .NET — SDK-style projects, no rewrite required, the .NET Upgrade Assistant, and “additional effort to complete the upgrade.”
- Microsoft Learn, Upgrade a Xamarin.Forms app to a .NET MAUI app with the .NET Upgrade Assistant.