Si estás presupuestando una migración de Xamarin a .NET MAUI en 2026, la respuesta honesta es que no hay un precio fijo — y cualquier proveedor que te dé uno sin mirar tu código está adivinando. El coste depende casi por completo de cuánta UI personalizada y código específico de plataforma tenga tu app, no de su número de pantallas. La buena noticia, directamente de la guía de Microsoft, es que no hace falta reescribir la app: los proyectos deben pasar a formato SDK-style, pero la lógica de negocio, los view models y los servicios se trasladan en gran medida intactos. El esfuerzo —y el presupuesto— se concentra en tres sitios: los custom renderers que hay que reescribir como handlers, las dependencias de terceros sin equivalente en .NET MAUI y el código nativo específico de plataforma. Esta guía explica cada factor para que dimensiones el trabajo antes de que nadie te presupueste.
Por qué no existe un precio único para una migración de Xamarin
Dos apps de Xamarin.Forms con el mismo número de pantallas pueden diferir en esfuerzo de migración en un orden de magnitud. Una pantalla que usa controles estándar y data binding se traslada casi mecánicamente. Una pantalla respaldada por tres custom renderers, un effect específico de plataforma y una dependencia abandonada en 2021 es un problema de ingeniería a medida.
Por eso las estimaciones de “coste por pantalla” engañan. La unidad de trabajo en una migración no es la pantalla, sino la cantidad de código personalizado y acoplado a plataforma que hay detrás. Dimensiona eso y podrás dimensionar el presupuesto.
El mejor predictor de esfuerzo: los custom renderers
En Xamarin.Forms, cuando un control estándar no hacía lo que necesitabas, escribías un custom renderer: código específico de plataforma que accedía al control nativo. .NET MAUI sustituye la arquitectura de renderers por handlers, más ligeros y desacoplados por diseño, pero lo bastante distintos como para que los renderers no se porten automáticamente.
Cada custom renderer de tu código es una unidad de trabajo manual: hay que reimplementarlo como handler (o adaptarlo al modelo de personalización de handlers de MAUI) y luego validarlo en cada plataforma. Si quieres un número para comprobar la lógica de una estimación de migración, cuenta tus custom renderers. Una app con unos pocos es un proyecto distinto a una con cincuenta.
Qué hace realmente el .NET Upgrade Assistant
Microsoft ofrece una herramienta gratuita, el .NET Upgrade Assistant, una utilidad de línea de comandos que actualiza apps multiproyecto de Xamarin.Forms a apps multiproyecto de .NET MAUI. Se encarga de la conversión mecánica: archivos de proyecto a SDK-style, cambios de namespaces y paquetes, y el andamiaje de la estructura de MAUI.
Es genuinamente útil, y no es una migración terminada. La propia documentación de Microsoft indica que, tras ejecutar la herramienta, en la mayoría de los casos la app requerirá trabajo adicional para completar la actualización. El Upgrade Assistant despeja el trabajo repetitivo; no resuelve los custom renderers, las dependencias rotas ni el comportamiento en tiempo de ejecución que solo aparece en un dispositivo. Presupuesta la herramienta para acelerar el arranque, no para entregar el final.
Dependencias de terceros: el mayor comodín de la estimación
El segundo factor de coste es tu lista de dependencias. Cada paquete NuGet y cada plugin de Xamarin cae en uno de tres cubos:
- Tiene versión para .NET MAUI — normalmente una subida de versión y cambios menores de API.
- Tiene un sucesor comunitario o de primera parte — un reemplazo más trabajo de integración.
- Está abandonado y sin equivalente — el caso caro, en el que reimplementas la capacidad o buscas e integras un reemplazo.
El tercer cubo es donde se disparan los presupuestos de migración, porque el trabajo se descubre a mitad de proyecto en lugar de estimarse al principio. Una auditoría de dependencias antes del presupuesto convierte ese comodín en una partida.
El coste oculto: los fallos silenciosos en tiempo de ejecución
El coste de migración más peligroso es el que ningún compilador te muestra. Un modo de fallo conocido en las migraciones automatizadas de Xamarin es el fallo silencioso en tiempo de ejecución: el proyecto compila, el IDE no reporta errores, la app se despliega en un dispositivo — y luego se comporta mal o se cierra al arrancar sin stack trace. La ruptura vive en el comportamiento en tiempo de ejecución de los handlers de plataforma, los eventos de ciclo de vida y el cableado de la inyección de dependencias que la migración reescribió sin preservar del todo la intención original.
Por eso la QA en dispositivo no es opcional y no puede recortarse para ahorrar presupuesto. Todo lo que un compilador o un agente de IA puede comprobar puede pasar mientras la app sigue rota en manos de los usuarios. Tratamos este patrón con más detalle en la deuda técnica de la IA en móvil.
Una autoevaluación para dimensionar tu migración
Antes de pedir un presupuesto, responde a esto. Cada “sí” o recuento más alto te sube en la escala de esfuerzo:
- Custom renderers — ¿cuántos? (Ninguno / unos pocos / docenas.)
- Código específico de plataforma — ¿effects, bindings nativos, implementaciones de
DependencyService? (Raro / habitual / por todas partes.) - Dependencias de terceros — ¿cuántas y cuántas siguen mantenidas? (Pocas y actuales / varias / muchas y algunas abandonadas.)
- Cobertura de tests — ¿tienes tests automatizados que detecten una regresión? (Buena / escasa / ninguna.)
- Equipo original — ¿sigue disponible alguien que entienda la app? (Sí / en parte / no — ver más abajo.)
- UWP / Windows — ¿publicas un target de Windows que deba pasar a WinUI 3? (No / sí.)
Una app con puntuación baja en todo es cuestión de semanas. Una app con puntuación alta —muchos custom renderers, dependencias abandonadas, sin tests, sin equipo original— es un proyecto de ingeniería de varios meses, y su presupuesto debe reflejar el discovery necesario para reducir el riesgo.
¿Precio cerrado o tiempo y materiales?
Un precio cerrado solo es seguro cuando ya se han eliminado las incógnitas. Eso significa haber hecho antes una fase de discovery: un inventario de custom renderers, una auditoría de dependencias y una prueba de humo del comportamiento en dispositivo. Presupuesta una app compleja o mal documentada a precio cerrado sin eso, y la estimación carga con un riesgo que no puedes ver.
La estructura de menor riesgo para la mayoría de migraciones empresariales es una fase de discovery acotada primero, que produce un plan dimensionado y una estimación defendible, seguida de la migración en sí. Pagas por certeza antes de pagar por volumen.
Si el equipo original ya no está
Muchas apps de Xamarin de 2026 han sobrevivido a las personas que las construyeron. Si nadie puede explicar por qué una pantalla se comporta como lo hace, la migración se convierte en arqueología — y el riesgo es que una migración “fiel” reproduzca fielmente errores o descarte comportamiento no documentado del que un usuario dependía.
La solución es recuperar el modelo de producto antes de migrar el código. Explicamos el método en recuperar el conocimiento de producto de un repositorio legacy y en la checklist de discovery de repositorios legacy que lo acompaña. Hazlo primero y la estimación de la migración dejará de esconder un problema de discovery dentro de un presupuesto de código.
Qué necesitaríamos para presupuestar tu migración
Si quieres un número defendible en lugar de una suposición, partiríamos de tu recuento de custom renderers, tu lista de dependencias, tu estado de Windows/UWP y tu cobertura de tests — y luego ejecutaríamos una fase corta de discovery para confirmar las incógnitas de tiempo de ejecución. Eso produce un plan dimensionado y una estimación que puedes llevar a quien aprueba el presupuesto.
Si estás valorando si migrar o no, lee la pieza complementaria sobre tus opciones realistas si sigues en Xamarin en 2026. Si ya sabes que vas a migrar y quieres dimensionarlo bien, reserva una llamada de 20 minutos o mira cómo trabajamos.
FAQ
¿Cuánto cuesta migrar de Xamarin a .NET MAUI? No hay un precio fijo, porque el esfuerzo depende de la complejidad de la app y no solo del número de pantallas. Los mayores factores de coste son la cantidad de custom renderers que hay que reescribir como handlers, las dependencias de terceros sin equivalente en .NET MAUI y el código nativo específico de plataforma. Una app pequeña con pocos custom renderers suele ser cuestión de semanas; una app empresarial grande con muchos custom renderers y dependencias abandonadas puede llevar varios meses. Dimensiona esos factores antes de pedir un presupuesto.
¿Tengo que reescribir mi app de Xamarin para pasar a .NET MAUI? No. La guía oficial de Microsoft indica que los proyectos deben pasar a formato SDK-style, pero no hace falta reescribirlos, y las soluciones multiproyecto no tienen que convertirse en un único proyecto. La mayor parte de la lógica de negocio, los view models y los servicios se trasladan con pocos cambios. El esfuerzo se concentra en la capa de UI y en el código específico de plataforma.
¿Qué hace el .NET Upgrade Assistant en una migración de Xamarin? El .NET Upgrade Assistant es una herramienta de línea de comandos que actualiza apps multiproyecto de Xamarin.Forms a apps multiproyecto de .NET MAUI. Automatiza las partes mecánicas de la conversión, pero Microsoft advierte que, en la mayoría de los casos, la app requerirá trabajo adicional para completar la actualización. Trátala como un punto de partida, no como una migración terminada.
¿Es mejor un contrato a precio cerrado o por tiempo y materiales para una migración de Xamarin? Depende de cuánto se conozca la app de antemano. Un precio cerrado solo es seguro tras una fase de discovery que inventaríe custom renderers, dependencias y código de plataforma; sin ella, la estimación carga con el riesgo de lo desconocido. Para una app compleja o mal documentada, lo habitual y de menor riesgo es un contrato por tiempo y materiales con una fase de discovery acotada primero.
Fuentes (consultadas el 14 de julio de 2026):
- Microsoft, política de soporte de Xamarin — fin de soporte el 1 de mayo de 2024.
- Microsoft Learn, Upgrade from Xamarin to .NET — proyectos SDK-style, sin reescritura, el .NET Upgrade Assistant y el “trabajo adicional para completar la actualización”.
- Microsoft Learn, Upgrade a Xamarin.Forms app to a .NET MAUI app with the .NET Upgrade Assistant.