Cuándo no conviene migrar una aplicación de Windows a la Web: una tabla de decisión y la solución realista de la "división"

«Ya va siendo hora de migrar a la Web la aplicación Windows que usamos internamente» — este tipo de consulta aumenta año tras año. Aunque suele ser una motivación razonable, cuando profundizamos en los detalles, no son pocos los casos en los que el equipo está a punto de migrar por completo a la Web una aplicación que, precisamente por eso, se volvería más difícil de usar y más costosa.

Para que quede claro desde el principio, este artículo no defiende la postura de «nunca migres a la Web». Hay muchas situaciones —el uso desde varias sedes, la reducción de la gestión de equipos— en las que la migración a la Web es claramente la decisión correcta. El problema aparece cuando se aplica sin distinción la ecuación «modernización = migración a la Web» incluso a aplicaciones cuya naturaleza no encaja con la Web. En este artículo organizamos cómo distinguimos, en el trabajo real de desarrollo Windows por encargo, los casos en los que es mejor no migrar a la Web, y presentamos la división como solución realista frente a la disyuntiva de todo Web o todo Windows.

1. La conclusión primero (tabla de decisión)

La clave está en evaluar no la aplicación como un todo, sino cada función o característica que posee, por separado.

Dicho esto, adelantamos la conclusión.

• En una solicitud de «queremos migrar a la Web» suelen mezclarse tres problemas distintos: la molestia de la distribución, las restricciones sobre dónde se puede usar la aplicación y la obsolescencia tecnológica. Cada uno tiene una solución diferente, y la migración a la Web es la única salida solo para una parte de ellos (capítulo 2).
• En aplicaciones con integración de dispositivos, procesamiento de archivos locales u operación sin conexión, es más seguro no migrar esa parte a la Web. Por razones de seguridad, los navegadores restringen deliberadamente el acceso a los recursos locales; esto no es un defecto de la Web, sino una decisión de diseño¹. Existen soluciones alternativas, pero traen consigo otros costos: limitaciones de compatibilidad entre navegadores y una operación más compleja (capítulos 3 a 5).
• Migrar a la Web es una reconstrucción, no una portación. Los activos de pantalla existentes no se pueden trasladar tal cual, y una vez terminado el proyecto aparece un nuevo costo continuo: la operación del servidor. Si la estimación no parte de esta premisa, el plan se desmorona a mitad de camino (capítulo 7).
• La solución realista es la división. Lleve a la Web la visualización, la agregación y los informes; mantenga en Windows la integración con dispositivos y la entrada de datos en el terreno; y conecte ambas partes con una API y una base de datos comunes. Así se puede empezar con un alcance menor que una migración total y avanzar en orden de impacto (capítulo 8).

2. Desglosar lo que realmente significa «queremos migrar a la Web»

Cuando recibimos una consulta sobre migración a la Web, lo primero que hacemos es desglosar la solicitud. Detrás de las palabras «queremos pasarlo a la Web» suele haber uno (o varios) de estos tres motivos.

(1) Queremos eliminar la molestia de la distribución y las actualizaciones. El problema típico es «cada vez que sacamos una nueva versión, tenemos que ir instalándola equipo por equipo». La migración a la Web sin duda lo resuelve, pero también se puede resolver sin migrar a la Web. Cambiar a un método de distribución con actualización automática, como ClickOnce o MSIX, permite reducir el trabajo de distribución a casi cero sin dejar de ser una aplicación Windows. Lo explicamos en detalle en «Cómo elegir el método de distribución de una aplicación Windows». Si la molestia de la distribución es el único motivo, la migración a la Web es una inversión excesiva.

(2) Queremos poder usarla desde cualquier lugar y desde cualquier equipo. El uso desde varias sedes, el acceso desde una visita a un cliente o desde casa, la consulta desde una tableta: aquí es donde la migración a la Web realmente brilla. Pero incluso en este caso conviene distinguir entre «queremos usar todas las funciones desde cualquier lugar» y «solo queremos ver los datos desde cualquier lugar». En la práctica suele tratarse de lo segundo, y en ese caso basta con una arquitectura dividida (capítulo 8) que traslade a la Web únicamente la parte de visualización y agregación.

(3) Queremos dejar atrás una tecnología antigua. El motivo suele ser «la persona que la construyó ya no está en la empresa» o «nos preocupa seguir dependiendo de .NET Framework». Es una inquietud legítima, pero la solución no tiene por qué ser la migración a la Web. Si de todos modos hay que reconstruirla, y la naturaleza del trabajo se presta al escritorio, existe la opción de reconstruirla como aplicación Windows sobre la versión más reciente de .NET (tabla de decisión para elegir entre WinForms, WPF y WinUI). Conviene tener presente además que pasarse a la Web no libra de la obsolescencia. El caso de un sistema Web interno construido exclusivamente para IE, que quedó varado cuando IE dejó de existir, es un ejemplo reciente y conocido («Prolongar la vida de un sistema Web interno dependiente del modo IE y su estrategia de salida»). Las aplicaciones Web también requieren mantenimiento para seguir el ritmo de los cambios en los frameworks y los navegadores: «migrar a la Web» no equivale a «liberarse del mantenimiento».

Al desglosar la solicitud de esta manera, queda claro qué se resuelve únicamente migrando a la Web, qué se puede resolver de otras maneras y qué no se resuelve ni siquiera migrando a la Web. A partir de ahí, conviene revisar si la aplicación tiene alguna función que corresponda a los «casos en los que es mejor no migrar a la Web» que se describen a continuación.

3. Caso 1: Conexión directa con dispositivos o periféricos

La comunicación con equipos de fabricación, la captura de datos desde instrumentos de medición o de inspección, básculas o lectores de código de barras conectados por puerto serie (RS-232C), el control detallado de impresoras especiales: las aplicaciones con funciones que dialogan directamente con el hardware son, por estructura, un mal candidato para migrar esa parte a la Web.

La razón es simple: el código que se ejecuta en el navegador corre dentro de un entorno aislado llamado sandbox. Sería un problema que, con solo abrir una página Web, esta pudiera tocar libremente los archivos o los dispositivos del equipo, así que el navegador bloquea deliberadamente el acceso a los recursos locales. Esto no es un defecto de la Web, sino el propio diseño de seguridad. Por ejemplo, incluso en Blazor WebAssembly, que permite escribir un cliente Web en C#, el código se ejecuta dentro del sandbox de seguridad del navegador, y el acceso al sistema de archivos o la apertura de conexiones de red arbitrarias generan una PlatformNotSupportedException¹. Lo que se puede hacer queda limitado al alcance de las capacidades del propio navegador².

Se podría objetar que «con la Web Serial API o WebUSB el navegador puede hacer comunicación serie». Es cierto que existen, pero el soporte de navegadores es limitado. La Web Serial API funciona en navegadores basados en Chromium (Chrome, Edge, etc.) y, desde Firefox 151, publicado en mayo de 2026, también en la versión de escritorio de Firefox, pero Safari sigue sin soportarla (y en móviles, Chrome para Android solo ofrece soporte parcial para serie vía Bluetooth), mientras que WebUSB sigue limitado a Chromium³. Además de restringir la mayor ventaja de la migración a la Web —«poder usarla desde cualquier navegador»—, al conectar el dispositivo (al menos la primera vez, o cada vez que se añade un equipo) el usuario debe seleccionarlo y autorizarlo mediante un cuadro de diálogo del navegador, lo que en la práctica suele hacer que esta vía no compense como mecanismo de integración de dispositivos para un sistema empresarial.

También existe la opción de sortear esto con una arquitectura de «aplicación Web más un agente de integración residente en cada equipo», pero se trata de una configuración en la que, al final, sigue habiendo un programa Windows que requiere distribución y actualización. Esto no es malo en sí mismo —de hecho, es una variante de la arquitectura dividida del capítulo 8—, pero conviene dejar claro desde la etapa de planificación que esto no es lo mismo que la expectativa inicial de que «migrar a la Web significa no tener que instalar nada en los equipos».

Para el diseño de la parte de integración con dispositivos, consulte también «Buenas prácticas para verificar y mostrar el estado de dispositivos externos».

4. Caso 2: Integración profunda con archivos locales u otras aplicaciones

El segundo caso más frecuente es aquel en el que trabajar con archivos del equipo o con otras aplicaciones constituye el núcleo del proceso de negocio.

• Monitorear una carpeta compartida o local y procesar automáticamente los archivos que se depositan en ella
• Convertir, renombrar o clasificar de forma masiva cientos o miles de archivos
• Abrir Excel y ensamblar informes mediante COM, o integrarse con macros de Excel existentes
• Intercambiar datos con otras aplicaciones de negocio mediante archivos o comunicación entre procesos

Como regla general, el acceso a archivos desde el navegador se limita a «los archivos que el usuario selecciona en el momento mediante un cuadro de diálogo». No es posible el acceso masivo sin intervención del usuario, ni el monitoreo de tipo residente que sigue funcionando aunque el navegador esté cerrado. Las incorporaciones recientes, como la File System Access API, permiten el acceso a nivel de carpeta previamente seleccionada por el usuario, e incluso existe una API experimental (FileSystemObserver) que vigila los cambios dentro de esa carpeta mientras la página permanece abierta, pero ambas están limitadas a navegadores basados en Chromium⁴ y arrastran el mismo problema de «restringir los navegadores compatibles» que la integración con dispositivos. En cuanto a abrir y controlar desde el navegador otro proceso local, como Excel, sencillamente no existe ninguna vía para hacerlo.

Migrar este tipo de función a la Web exige cambiar el flujo de trabajo hacia algo como «el usuario sube los archivos al servidor y este los procesa». Si el negocio puede funcionar así, es una opción válida; pero si existen circunstancias como manejar habitualmente archivos del orden de gigabytes, procesar localmente datos que no pueden salir de la empresa, o estar fuertemente acoplado a activos de Excel, resulta más razonable —tanto para quien la construye como para quien la usa— mantener esa parte como aplicación Windows (o, para procesos desatendidos como el monitoreo de carpetas o el procesamiento por lotes, como un servicio de Windows). Un punto que sí requiere cuidado es dónde se ubica la integración COM con Excel: Microsoft desaconseja y no ofrece soporte para automatizar Office desde entornos desatendidos y no interactivos, como los servicios⁵, de modo que el código que maneja Excel automáticamente debe residir en la aplicación de escritorio que usa un usuario con sesión iniciada, o bien sustituirse por lectura y escritura mediante una biblioteca basada en Open XML que no abra Office en absoluto. Tratamos cómo construir la integración con Excel en «Cómo construir la salida de informes de Excel» y el monitoreo de carpetas en «Los fundamentos seguros de FileSystemWatcher».

5. Caso 3: Uso en el terreno con red inestable, en operaciones que no pueden detenerse

Por su propia estructura, una aplicación Web da por supuesto que la conexión de red está activa. Esto vale, por supuesto, para las aplicaciones Web con renderizado del lado del servidor, pero también para Blazor Server, tan popular en el mundo C#: como cada operación de la interfaz se procesa a través de una conexión permanente con el servidor, la aplicación deja de funcionar en cuanto se corta la conexión. La documentación oficial indica explícitamente que no hay soporte sin conexión².

Esto se convierte en un problema en entornos como los siguientes.

• Fábricas, almacenes, sitios al aire libre: la señal Wi-Fi se bloquea por estanterías metálicas o maquinaria, y los cortes momentáneos son cosa de todos los días
• Líneas que no pueden detenerse: basta con que la pantalla de registro o de instrucciones se congele unos minutos para afectar la producción o los envíos
• Sedes con conexión débil o inestable: oficinas temporales que dependen de datos móviles, embarcaciones, zonas montañosas, etc.

Una aplicación Windows nativa se puede diseñar sin dificultad para mantener los datos localmente, seguir funcionando sin conexión y sincronizarse una vez restablecida la red. El propio Microsoft cita el funcionamiento sin conexión como una razón para elegir una aplicación nativa⁶. También es técnicamente posible dotar a una aplicación Web de capacidad sin conexión mediante una PWA (service worker) o un diseño que mantenga los datos del lado del cliente, pero construir eso —incluyendo la sincronización y la resolución de conflictos— exige una inversión adicional considerable, que va en sentido contrario a la expectativa inicial de que «migrar a la Web abarataría las cosas».

El criterio decisivo es: «si la red se cae durante 30 minutos, ¿ese proceso puede esperar?». Si no puede esperar, al menos la pantalla que sostiene ese proceso debería funcionar de forma local.

6. Caso 4: La entrada rápida y masiva de datos por teclado es el centro del trabajo

La captura de comprobantes, el registro de inspección y despacho, las pantallas de atención en un call center: son trabajos en los que alguien pasa todo el día frente a esa pantalla, tecleando grandes volúmenes de datos. En esta área, la interfaz de escritorio alcanza un grado de refinamiento muy alto, y es precisamente donde la migración a la Web suele hacer que la calidad percibida caiga.

• Latencia de respuesta: en modelos conectados al servidor como Blazor Server, cada acción del usuario implica un viaje de ida y vuelta por la red, lo que eleva la latencia de la interfaz². Aunque sean solo decenas de milisegundos por acción, en un trabajo de miles de operaciones diarias esa demora se percibe con toda seguridad como una sensación de «traba».
• Reproducir el comportamiento del teclado: cosas que se dan por sentadas en el trabajo de captura de datos —moverse entre campos con Enter, asignar teclas de función, validar de inmediato mientras se escribe— terminan construyéndose peleando contra el comportamiento predeterminado del navegador (Enter que envía un formulario, F1 que abre la ayuda, etc.). No es imposible, pero implica pagar un costo adicional para alcanzar la calidad que un framework y un componente de cuadrícula de escritorio ya traen de fábrica.
• Cuadrículas con grandes volúmenes de datos: construir para la Web una cuadrícula de nivel de escritorio que muestre con fluidez decenas de miles de filas mediante desplazamiento virtual, y que admita edición de celdas, columnas fijas y copiar y pegar, requiere adoptar un componente comercial de altas prestaciones y un ajuste considerable.

Para consultas, aprobaciones o registros ocasionales, un formulario Web es más que suficiente. Pero para una pantalla donde la velocidad de entrada de datos se traduce directamente en productividad, conviene comprobar con calma si realmente se aprovechará la ventaja de la migración a la Web (poder usarla desde cualquier lugar), o si esa pantalla, al final, solo se va a usar desde un puesto fijo en la oficina. Si el lugar de uso es fijo, la migración a la Web no aporta nada y solo hace perder.

7. Caso 5: Empezar una «reconstrucción» con el presupuesto de una «portación»

Hasta aquí hablamos de funciones y formas de uso; ahora toca la estructura de costos. El patrón clásico por el que un plan de migración a la Web se desmorona a mitad de camino es presupuestarlo con la idea de una portación —«trasladar lo que ya existe a la Web»— y descubrir después que en realidad era una reconstrucción.

• Los activos de pantalla no se pueden trasladar. No existe una manera realista de convertir automáticamente a la Web las definiciones y la lógica de pantalla de WinForms o WPF: hay que rediseñar y reconstruir la interfaz pantalla por pantalla. El número de pantallas multiplicado por su complejidad se convierte directamente en el esfuerzo de desarrollo.
• Antes hay que hacer un inventario de la lógica de negocio. No es raro que, en una aplicación con muchos años de operación, existan reglas de negocio que no figuran en ninguna especificación y que solo viven dentro del código. Migrar a la Web incluye la tarea de desenterrar todo eso y volver a implementarlo. Aquí se aplica tal cual el principio de «no lanzarse directamente a una reescritura total» que expusimos en «Migración de aplicaciones de negocio VB6 / Access».
• El costo operativo, una vez terminado el proyecto, aumenta estructuralmente. Operar una aplicación de escritorio consistía en cuidar los equipos, pero con una aplicación Web surge trabajo continuo: construir, monitorear y respaldar un servidor (o entorno en la nube), además de gestionar certificados y actualizaciones de seguridad. Si la empresa no cuenta con esa estructura internamente, habrá un costo mensual de tercerización. La comparación de costos de la migración a la Web debe incluir este costo recurrente, no solo el costo de desarrollo inicial.
• Cambian las premisas de seguridad. En el momento en que una aplicación que solo funcionaba dentro de la LAN interna pasa a la Web y se permite el acceso externo, el nivel exigido de autenticación, autorización, cifrado de las comunicaciones y protección contra ataques sube un escalón. Esto también forma parte del «costo de la migración a la Web».

Insistimos: nada de esto es un argumento en contra de la migración a la Web, sino material para presupuestarla sobre premisas correctas. Si, incluso incorporando el costo de la reconstrucción y de la operación continua, los beneficios de migrar a la Web siguen siendo mayores, adelante. Si no lo son, conviene evaluar primero si modernizar la aplicación manteniéndola en Windows —migrar a la versión más reciente de .NET, mejorar el método de distribución, renovar la interfaz— puede satisfacer la mayor parte de la motivación con una inversión menor.

8. La solución realista: no forzar la disyuntiva entre todo Web o todo Windows

Al llevar a la práctica todo el razonamiento anterior, en la mayoría de los casos la respuesta no es «migrar todo a la Web» ni «dejarlo todo como está», sino dividir.

La idea es sencilla: aplicar la tabla de decisión del capítulo 1 no a la aplicación entera, sino función por función.

• Lo que se lleva a la Web: la visualización, búsqueda y agregación de datos que varias sedes o personas necesitan consultar, la descarga de informes y operaciones ligeras como las aprobaciones. El mantenimiento de datos maestros suele entrar aquí también.
• Lo que se mantiene en Windows: la integración con dispositivos y periféricos, el monitoreo y procesamiento por lotes de archivos locales, el trabajo de campo que no puede detenerse ni siquiera sin conexión, y las pantallas de entrada rápida de datos.
• Lo que se comparte: la base de datos y la lógica de negocio. Se centralizan los datos de modo que tanto la aplicación Web como la aplicación Windows consulten la misma API (o base de datos). Al compartir esta parte, se logra una arquitectura que satisface la mayor parte de la motivación para migrar a la Web: «el personal de campo registra los datos con la aplicación Windows, y la sede central los verifica al instante desde el navegador».

Esta arquitectura tiene ventajas prácticas que una migración total no ofrece: el alcance que hay que reconstruir de una vez es menor, se puede avanzar por etapas empezando por las partes de mayor impacto (las de visualización), y no se pierde usabilidad en el terreno. A cambio, se necesita una estructura capaz de mantener dos sistemas —una aplicación Windows y una aplicación Web—, así que si la aplicación en cuestión es pequeña y se centra sobre todo en la visualización, puede que lo más sensato sea, sencillamente, migrarla por completo a la Web. Tampoco aquí se trata de una disyuntiva binaria, sino de una cuestión de grado.

Cabe añadir que, para el requisito de «queremos construir la interfaz con tecnología Web, pero también necesitamos tocar recursos locales», existen opciones híbridas como Electron o Blazor Hybrid (WebView2). Permiten usar una interfaz con tecnología Web sin las restricciones del sandbox del navegador, pero conviene tener presente que se trata de una aplicación de escritorio que requiere distribución, y por tanto no responde a la solicitud de «queremos usarla solo desde el navegador».

9. Lista de verificación antes de decidir la migración a la Web

Revisar los siguientes puntos antes de solicitar un presupuesto o de iniciar la aprobación interna reduce el riesgo de retrabajo.

1. Desglosar la motivación: ¿cuál es el verdadero problema —la molestia de la distribución, el lugar de uso o la obsolescencia tecnológica—? Si es solo la distribución, ¿bastaría con cambiar el método de distribución?
2. Integración con hardware: ¿hay funciones que se comuniquen directamente con dispositivos serie/USB, instrumentos de medición o impresoras especiales? Si las hay, decida de antemano cómo tratar esa parte (mantenerla en Windows o usar una arquitectura de agente).
3. Dependencia de recursos locales: ¿existe monitoreo de carpetas, procesamiento masivo de archivos o integración de procesos con Excel u otras aplicaciones? ¿Se puede cambiar el flujo de trabajo a un modelo de procesamiento en el servidor?
4. Requisitos sin conexión: si la red se cae durante 30 minutos, ¿ese proceso puede esperar?
5. Peso del trabajo de entrada de datos: ¿hay pantallas donde se teclea todo el día? ¿De verdad se va a usar esa pantalla «desde cualquier lugar»?
6. Realidad de los usuarios y los lugares: ¿quién, desde dónde y qué quiere ver o registrar? ¿Es «todos necesitan todas las funciones desde fuera de la empresa» o «la sede central solo quiere ver los datos»?
7. Estructura operativa: ¿quién se encargará de construir, monitorear y actualizar la seguridad del servidor? ¿Cuánto costará eso al mes?
8. Ubicación de la lógica de negocio: ¿la especificación coincide con el código? ¿Se incluyó en la estimación el tiempo necesario para el inventario?

Si alguno de los puntos 2 a 5 aplica, recomendamos considerar como enfoque principal una arquitectura dividida en lugar de una migración total a la Web. Para la preparación general antes de encargar el desarrollo, consulte también «Qué conviene organizar antes de solicitar el desarrollo externo de una aplicación Windows».

Resumen

La migración a la Web es una herramienta, no un fin en sí mismo. Ayuda claramente al uso desde varias sedes y a reducir la gestión de equipos, pero la integración con dispositivos y el procesamiento de archivos locales chocan con restricciones que provienen del propio diseño de seguridad del navegador, difíciles de superar mediante la elección de un framework o el esfuerzo de desarrollo, y aunque la operación sin conexión y la entrada rápida de datos puedan resolverse técnicamente, el costo de construirlas y operarlas tiende a ir en sentido contrario al objetivo inicial de «facilitar las cosas migrando a la Web». Además, migrar a la Web es una reconstrucción, no una portación, y una vez terminado el proyecto se añade un nuevo costo continuo: la operación del servidor.

Por eso, la decisión práctica no es «migrar a la Web o no», sino una cuestión de diseño: «qué funciones se llevan a la Web, cuáles se mantienen en Windows y qué se comparte». Desde el inventario de la aplicación existente hasta la decisión sobre la migración y el diseño de la arquitectura dividida, suele ser necesario un juicio fundamentado en el código y en la operación real, así que, si tiene dudas, no dude en consultarnos.

Artículos relacionados

• Qué conviene organizar antes de solicitar el desarrollo externo de una aplicación Windows
• Prolongar la vida y migrar aplicaciones de negocio VB6 / Access — Tabla de decisión entre mantener, envolver o reemplazar
• Tabla de decisión para elegir entre WinForms, WPF y WinUI
• Cómo elegir el método de distribución de una aplicación Windows (MSI / MSIX / ClickOnce / xcopy / actualizador propio)
• Prolongar la vida de un sistema Web interno dependiente del modo IE y su estrategia de salida
• Buenas prácticas para verificar y mostrar el estado de dispositivos externos
• Los fundamentos seguros de FileSystemWatcher
• Cómo construir la salida de informes de Excel

Áreas de consultoría relacionadas

En KomuraSoft LLC (合同会社小村ソフト) ofrecemos consultoría técnica sobre si conviene o no migrar a la Web una aplicación Windows existente, el diseño de arquitecturas divididas entre Web y Windows, y el desarrollo o la modificación de aplicaciones de negocio que incluyen integración de dispositivos y procesamiento local.

• Desarrollo de aplicaciones Windows
• Modificación y mantenimiento de software Windows existente
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Si vamos a actualizar una aplicación Windows antigua, ¿conviene aprovechar para migrarla a la Web?

No recomendamos migrar a la Web solo porque la aplicación sea "antigua". La migración a la Web exige un esfuerzo cercano a una reconstrucción completa, no a una simple portación, y además las aplicaciones Web también sufren obsolescencia tecnológica (un sistema Web interno que quedó atado exclusivamente a IE es un ejemplo típico). El criterio de decisión no debería ser la antigüedad de la tecnología, sino la forma en que se usa la aplicación. Si se usa desde varias sedes o se quiere reducir la gestión de equipos, la migración a la Web aporta beneficios reales; pero si el núcleo de la aplicación es la integración con dispositivos o el procesamiento de archivos locales, suele ser más rentable modernizarla manteniéndola como aplicación Windows: migrar a una versión más reciente de .NET, renovar la interfaz, etc.

¿No basta con migrar a la Web para eliminar las molestias de distribución e instalación?

El trabajo de distribución del lado del cliente desaparece, pero si esa es la única motivación, existen soluciones más ligeras que la migración a la Web. Cambiar a un método de distribución con actualización automática integrada, como ClickOnce o MSIX, permite reducir a casi cero las visitas de instalación a cada equipo sin dejar de ser una aplicación Windows. Además, al migrar a la Web aparece un nuevo costo operativo continuo: construir, monitorear y aplicar actualizaciones de seguridad a un servidor (o entorno en la nube). Evalúe tanto los costos que elimina como los que añade antes de decidir.

¿Es posible migrar a la Web solo una parte de la aplicación?

Sí, y en la práctica esa suele ser la solución más realista. Un patrón típico consiste en trasladar a la Web la visualización de datos, la agregación, los informes y el acceso desde varias sedes, mientras se mantiene como aplicación Windows la integración con dispositivos, la entrada rápida de datos en el terreno y el procesamiento de archivos locales, conectando ambas partes mediante una API y una base de datos comunes. Frente a una migración total, el alcance que hay que reconstruir de una sola vez es menor, y se puede avanzar por etapas comenzando por las partes donde la migración aporta más beneficio.

¿Qué pasa con opciones intermedias como Electron, PWA o Blazor Hybrid?

Son cosas de naturaleza distinta que conviene separar. Electron y Blazor Hybrid (WebView2) funcionan como aplicaciones de escritorio, por lo que pueden acceder a archivos y dispositivos sin las restricciones del sandbox del navegador, aunque la interfaz se escriba con tecnología Web. Sin embargo, siguen siendo aplicaciones de escritorio que requieren distribución y actualización, por lo que no responden a la solicitud de "poder usarla solo desde el navegador". Una PWA, en cambio, puede sentirse instalada —por ejemplo, anclada a la barra de tareas— pero por dentro sigue siendo una aplicación Web que corre en el navegador, con las mismas restricciones de acceso a recursos locales que cualquier aplicación Web convencional. Es fundamental desglosar primero qué problema se quiere resolver realmente al considerar la migración a la Web.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.