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

“Queremos migrar a la Web la aplicación Windows que usamos internamente” —esta consulta aumenta año tras año. Aunque suele ser una motivación razonable, al escuchar los detalles no es raro encontrar casos en los que se intenta migrar por completo a la Web una aplicación que, precisamente al migrarla, resultaría más incómoda de usar y más costosa.

Aclaremos antes de nada: este artículo no dice “no migren a la Web”. Hay muchas situaciones en las que la migración a la Web es claramente la respuesta correcta, como el uso desde varias sedes o la reducción de la gestión de equipos. El problema es meter en el mismo saco, bajo la etiqueta de “modernizar = migrar a la Web”, incluso las aplicaciones cuya naturaleza no encaja con la Web. En este artículo organizamos, desde la experiencia práctica del desarrollo Windows por encargo, cómo identificar los “casos en los que no conviene migrar a la Web” y presentamos la solución realista de la división, en lugar de reducirlo todo a la disyuntiva de “todo Web o todo Windows”.

1. Primero, la conclusión (tabla de decisión)

El punto clave es decidir no por la aplicación en su conjunto, sino por cada función o característica que tiene la aplicación.

Los símbolos tienen el siguiente significado. ◎ = el efecto de migrar a la Web es grande / ○ = apto para migrar a la Web / △ = requiere precaución (según las condiciones puede no ser apto; conviene evaluar antes otras soluciones distintas de la migración a la Web) / × = no apto (se debe a restricciones estructurales del navegador, difíciles de revertir por más esfuerzo de desarrollo que se invierta).

Y aquí va la conclusión, por adelantado:

• Detrás de la solicitud “queremos migrar a la Web” suelen mezclarse tres problemas distintos: el trabajo de distribución, las restricciones del lugar de uso y la obsolescencia tecnológica. Cada uno tiene una solución diferente, y solo una parte de ellos se resuelve exclusivamente migrando a la Web (capítulo 2).
• En las aplicaciones con integración de dispositivos, procesamiento de archivos locales u operación sin conexión, es más seguro no migrar a la Web esa parte. Por razones de seguridad, el navegador restringe deliberadamente el acceso a los recursos locales; esto no es un defecto de la Web, sino su filosofía de diseño¹. Existen soluciones alternativas, pero traen consigo otros costos, como las limitaciones de los navegadores compatibles o una operación más compleja (capítulos 3 a 5).
• La migración a la Web no es una “portación”, sino una “reconstrucción”. Los activos de pantalla existentes no se pueden trasladar tal cual, y una vez terminada aparece un nuevo costo continuo: la operación del servidor. Si esto no se tiene en cuenta desde la base del presupuesto, el plan se desmorona a mitad de camino (capítulo 7).
• La solución realista es la división. Llevar a la Web la consulta, la agregación y los informes, mantener en Windows la integración con dispositivos y la entrada de datos en el terreno, y conectar ambas partes mediante una API y una base de datos comunes. Permite empezar en menor escala que una migración total y avanzar primero por las partes donde el efecto es mayor (capítulo 8).

2. Desglosar qué hay detrás de “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 la frase “queremos pasarlo a la Web” suele haber, casi siempre, uno de estos tres motivos (o varios a la vez):

(1) Queremos eliminar el trabajo de distribución y actualización. Es la preocupación de “cada vez que hay una nueva versión, tenemos que recorrer todos los equipos para instalarla”. Esto sí se resuelve migrando a la Web, pero también se puede resolver sin migrar a la Web. Cambiar a un método de distribución con mecanismo de actualización automática, como ClickOnce o MSIX, permite reducir casi a cero el trabajo de distribución sin dejar de ser una aplicación Windows. Este tema se desarrolla en “Cómo elegir el método de distribución de una aplicación Windows”. Si el único motivo es la molestia de la distribución, migrar a la Web es una inversión excesiva.

(2) Queremos usarla desde cualquier lugar y desde cualquier equipo. El uso desde varias sedes, el acceso desde una visita comercial o desde casa, la consulta desde una tableta: aquí es donde la migración a la Web da lo mejor de sí. Pero incluso aquí conviene distinguir si lo que se busca es “usar todas las funciones desde cualquier lugar” o “consultar los datos desde cualquier lugar”. En la práctica suele ser lo segundo, y en ese caso basta con una arquitectura dividida (capítulo 8) que lleve a la Web solo la parte de consulta y agregación.

(3) Queremos dejar atrás una tecnología antigua. Es el motivo de “la persona que la creó ya no está en la empresa” o “nos preocupa seguir con .NET Framework”. Es una inquietud legítima, pero la solución no tiene por qué ser migrar a la Web. Si de todos modos hay que reconstruirla, y la naturaleza del trabajo es propia de escritorio, existe la opción de reconstruirla como aplicación Windows con la versión más reciente de .NET (tabla de decisión para elegir entre WinForms, WPF y WinUI). Además, conviene tener presente que pasar a la Web no libra de la obsolescencia. El caso de sistemas Web internos construidos exclusivamente para IE, que se quedaron sin rumbo tras el fin de IE, sigue fresco en la memoria (“Prórroga y estrategia de salida de sistemas Web internos mediante el modo IE”). Las aplicaciones Web también requieren mantenimiento para seguir el ritmo de los cambios del framework y del navegador: “migrar a la Web” no equivale a “liberarse del mantenimiento”.

Al hacer este desglose, se distingue lo que “solo se resuelve migrando a la Web”, lo que “se resuelve también de otras formas” y lo que “no se resuelve ni migrando a la Web”. Sobre esa base, conviene revisar si la aplicación tiene alguna función que encaje en los “casos en los que no conviene migrar a la Web” que se explican a continuación.

Cabe señalar que los casos siguientes se dividen en dos naturalezas distintas. Los casos 1 a 4 (capítulos 3 a 6) tratan de “qué no encaja técnicamente con la Web”, mientras que el caso 5 (capítulo 7) trata de “un error al leer la estructura de costos”. En los primeros, si la función corresponde, la conclusión directa es no llevarla a la Web; en el segundo, aunque corresponda, no es un motivo para cancelar el proyecto, sino para corregir la base del presupuesto.

3. Caso 1: conexión directa con dispositivos y periféricos

La comunicación con equipos de producción, la captura de datos desde instrumentos de medición o equipos de inspección, básculas o lectores de código de barras conectados por puerto serie (RS-232C), el control detallado de impresoras especiales: una aplicación con funciones que “conversan” directamente con hardware no encaja, estructuralmente, con migrar esa parte a la Web.

La razón es simple: el código que corre en el navegador se ejecuta dentro de un entorno aislado llamado sandbox. Como no conviene que, con solo abrir una página Web, se pueda manipular libremente los archivos o los dispositivos del equipo, 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 clientes 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 excepción PlatformNotSupportedException¹. Lo que se puede hacer queda limitado al alcance de las funciones del navegador².

Podría objetarse que “con la Web Serial API o WebUSB se puede hacer comunicación serie desde el navegador”. En efecto, existen, pero los navegadores compatibles son limitados. La Web Serial API funciona en navegadores basados en Chromium (Chrome, Edge, etc.), y desde Firefox 151, lanzado en mayo de 2026, también es compatible la versión de escritorio de Firefox; sin embargo, Safari sigue sin ser compatible (y en móviles, solo Chrome para Android ofrece soporte parcial mediante serie por Bluetooth), y WebUSB sigue limitada a navegadores basados en Chromium³. Esto añade una restricción a la mayor ventaja de la migración a la Web, “poder usarla desde cualquier navegador”, y además, al conectar el dispositivo, se requiere (al menos la primera vez o cada vez que se añade un equipo) que el usuario seleccione y autorice el dispositivo mediante un cuadro de diálogo del navegador; en la práctica, esto suele resultar poco rentable como mecanismo de integración con dispositivos en un sistema de negocio.

El estado de compatibilidad de los navegadores mencionado aquí es información que cambia rápido y envejece pronto (incluso la compatibilidad de Firefox con la Web Serial API es un movimiento relativamente reciente). Al tomar la decisión real, no se base únicamente en lo que dice este artículo: consulte la sección “Browser compatibility” de cada página de la API en MDN para conocer el estado actualizado. En cambio, el principio de que “el sandbox restringe el acceso a los recursos locales” es una filosofía de diseño, así que ese no cambia en el corto plazo.

También existe la alternativa de evitar el problema con una arquitectura de “aplicación Web + un agente de integración residente en cada equipo”, pero se trata de una configuración en la que termina quedando 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 es algo distinto de la expectativa inicial de que “al migrar a la Web ya no habrá 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 y otras aplicaciones

El siguiente caso frecuente es aquel en el que el núcleo del trabajo consiste en la interacción con archivos del equipo o con otras aplicaciones.

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

El acceso a archivos desde el navegador se limita, por principio, a “los archivos que el usuario selecciona cada vez mediante un cuadro de diálogo”. No es posible el acceso en bloque sin intervención del usuario, ni el monitoreo residente que sigue funcionando aunque el navegador esté cerrado. La File System Access API reciente permite el acceso por carpeta seleccionada por el usuario, y también ha aparecido una API experimental (FileSystemObserver) que monitorea, mientras la página está abierta, los cambios dentro de la carpeta elegida; 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. Y simplemente no existe ningún medio para que el navegador lance y controle otro proceso local (Excel, por ejemplo).

Migrar este tipo de función a la Web exige cambiar el flujo de trabajo hacia un modelo de “el usuario sube el archivo al servidor y este lo procesa”. Si el negocio funciona 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 lo construye como para quien lo usa— mantener esa parte como aplicación Windows (y, si es un procesamiento desatendido como el monitoreo de carpetas o el procesamiento en bloque, como un servicio de Windows). Solo la integración COM con Excel requiere prestar atención a dónde se ubica: Microsoft desaconseja y no da soporte a la automatización de Office desde entornos desatendidos y no interactivos, como los servicios⁵, así que el procesamiento que automatiza Excel debe ubicarse en el lado de la aplicación de escritorio que usa un usuario con sesión iniciada, o bien sustituirse por lectura y escritura mediante bibliotecas de la familia Open XML que no requieren abrir Office. La forma de construir la integración con Excel se trata en “Cómo construir la salida de informes en Excel”, y el monitoreo de carpetas en “Fundamentos seguros de FileSystemWatcher”.

5. Caso 3: operaciones que no pueden detenerse en entornos con red inestable

Por su propia estructura, una aplicación Web presupone que la red está activa. Esto vale tanto para las aplicaciones Web con renderizado del lado del servidor como para Blazor Server, popular en el ecosistema C#: como todas las operaciones de la interfaz se procesan a través de una conexión permanente con el servidor, la aplicación deja de funcionar si se corta la conexión. La documentación oficial indica expresamente que no hay soporte sin conexión².

Esto se vuelve un problema en entornos como los siguientes:

• Fábricas, almacenes y trabajo 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 detenga unos minutos para afectar la producción o el despacho
• Sedes con conexión débil o inestable: oficinas provisionales que dependen de datos móviles, embarcaciones, zonas montañosas, etc.

Una aplicación Windows nativa puede construirse de forma natural para que mantenga los datos localmente, siga funcionando sin conexión y sincronice al recuperar la red. El propio Microsoft menciona el funcionamiento sin conexión como una de las razones para elegir una aplicación nativa⁶. Técnicamente también es posible dotar a una aplicación Web de soporte sin conexión mediante una PWA (Service Worker) o un diseño que mantenga datos del lado del cliente, pero construir eso de forma completa, incluida la sincronización y la resolución de conflictos, exige una inversión adicional considerable, lo que va en sentido contrario a la expectativa inicial de que “migrar a la Web saldría más barato”.

El punto clave para decidir es: “si la red se cae durante 30 minutos, ¿ese trabajo puede esperar?”. Si no puede esperar, al menos la pantalla que atiende ese trabajo debería funcionar de forma local.

6. Caso 4: el núcleo del trabajo es la entrada de datos rápida y masiva por teclado

Ingreso de comprobantes, registro de inspección y despacho, pantallas de atención de un centro de llamadas: son trabajos en los que se pasa el día entero frente a la pantalla, ingresando grandes volúmenes de datos principalmente con el teclado. Este es un terreno donde la interfaz de escritorio tiene una madurez muy alta, y donde la migración a la Web suele degradar la calidad percibida.

• Retraso en la respuesta: en un modelo conectado al servidor como Blazor Server, cada operació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 operación, en un trabajo de ingreso con miles de operaciones diarias eso se percibe con claridad como una sensación de “traba”.
• Reproducir el comportamiento del teclado: cosas tan básicas en el trabajo de ingreso como moverse de campo con Enter, asignar teclas de función o validar en tiempo real mientras se escribe, hay que construirlas chocando con el comportamiento por defecto del navegador (Enter envía el formulario, F1 abre la ayuda, etc.). No es imposible, pero implica pagar un costo adicional para alcanzar la calidad que, en el escritorio, el framework y los componentes de grilla ya traen de fábrica.
• Grillas con grandes volúmenes de datos: mostrar con fluidez decenas de miles de filas mediante scroll virtual, y admitir edición de celdas, fijación de columnas y copiar y pegar con una grilla de nivel escritorio, requiere en la Web adoptar componentes comerciales de alto rendimiento y una afinación considerable.

Para consultar, aprobar o hacer algún registro ocasional, un formulario Web es suficiente. Pero en las pantallas donde la velocidad de ingreso incide directamente en la productividad del negocio, conviene verificar con calma si realmente se va a aprovechar el efecto de la migración a la Web (poder usarla desde cualquier lugar), o si esa pantalla, al final, solo se usa desde el puesto fijo de la oficina. Si el lugar de uso es fijo, migrar a la Web no aporta nada y solo hace perder cosas.

7. Caso 5: presupuestar como “portación” lo que en realidad es una “reconstrucción”

Hasta aquí hablamos de funciones y formas de uso; el último punto es de estructura de costos. El patrón típico por el que un plan de migración a la Web se desmorona a mitad de camino es presupuestar 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 un medio práctico para convertir automáticamente a la Web las definiciones y la lógica de pantalla de WinForms o WPF; la interfaz hay que rediseñarla y reconstruirla por completo, pantalla por pantalla. El número de pantallas multiplicado por su complejidad se convierte directamente en el esfuerzo de desarrollo.
• Primero hace falta un inventario de la lógica de negocio. En las aplicaciones que llevan años en operación, no es raro que existan reglas de negocio que solo viven dentro del código y no están en ninguna especificación. Migrar a la Web implica desenterrarlas todas y reimplementarlas. Aquí se aplica el mismo principio de “no reescribir todo de golpe” que se explica en “Migración de aplicaciones de negocio en VB6 / Access”.
• El costo de operación posterior aumenta de forma estructural. Operar una aplicación de escritorio consistía en atender los equipos, pero en una aplicación Web aparecen como trabajo continuo la construcción, el monitoreo, las copias de seguridad y las actualizaciones de seguridad y certificados de un servidor (o de la nube). Si la empresa no cuenta con esa estructura, se generará un costo mensual de tercerización. La comparación de costos de la migración a la Web debe incluir, además del costo de desarrollo inicial, este costo de operación recurrente.
• Cambian las premisas de seguridad. En el instante en que una aplicación que solo funcionaba dentro de la LAN interna se convierte en Web y se permite el acceso desde fuera de la empresa, el nivel exigido de autenticación, autorización, cifrado de comunicaciones y protección frente a ataques sube un escalón. Esto también forma parte del “costo de la migración a la Web”.

Al usarlo para una aprobación interna o una comparación dentro de la empresa, conviene ordenar el cálculo de la siguiente forma para que la discusión tenga sentido:

Costo total = costo de desarrollo inicial (esfuerzo de la reconstrucción) + costo de operación mensual × 12 × años de uso previstos + costos puntuales del período de transición (migración de datos, capacitación, período de convivencia)

El punto clave es comparar las opciones con el mismo número de años. Se coloca, por ejemplo, a 5 años, tanto la “migración a la Web” como la “modernización manteniéndola como aplicación Windows (migración al .NET más reciente, mejora del método de distribución, renovación de la interfaz)”, y se calcula el costo total de cada una. Si solo se comparan los costos iniciales, el costo continuo de operar el servidor desaparece del panorama; si solo se mira el costo mensual, no se ve la magnitud de la reconstrucción. Los años de uso previstos conviene definirlos a partir del ciclo de renovación del sistema de negocio (cuándo fue la última vez que se reemplazó internamente).

Insistimos: esto no es material para descartar la migración a la Web, sino material para presupuestarla sobre premisas correctas. Si, aun incorporando la reconstrucción y el costo de operación continuo, el beneficio de migrar a la Web sigue siendo mayor, conviene avanzar. Si no lo es, conviene evaluar antes si la modernización manteniéndola como aplicación Windows (migración al .NET más reciente, mejora del método de distribución, renovación de la interfaz), una inversión más pequeña, puede cubrir la mayor parte del motivo original.

8. La solución realista: no reducirlo a “todo Web” o “todo Windows”

Al llevar a la práctica el criterio expuesto hasta aquí, en la mayoría de los casos la respuesta no es ni “migración total a la Web” ni “mantener todo como está”, sino la división.

La idea es simple: aplicar la tabla de decisión del capítulo 1 no a la aplicación en su conjunto, sino a cada función. El panorama general queda así:

flowchart TB
    subgraph WEB["Migrar a la Web — navegador"]
        W["Consulta, búsqueda y agregación<br/>Descarga de informes y aprobaciones<br/>Mantenimiento de datos maestros"]
    end
    subgraph WIN["Mantener en Windows — app en cada equipo"]
        D["Integración con dispositivos y periféricos<br/>Monitoreo y procesamiento masivo de archivos locales<br/>Operación sin conexión y entrada rápida"]
    end
    API["Lógica de negocio y API comunes"]
    DB[("Base de datos")]
    W --> API
    D --> API
    API --> DB

Figura 1: panorama general de la arquitectura dividida. La sede central y otras ubicaciones usan el navegador, el personal de campo usa la aplicación Windows, y los datos y la lógica de negocio son comunes.

• Lo que se lleva a la Web: la consulta, la búsqueda y la agregación de datos que se quieren ver desde varias sedes o por varias personas, la descarga de informes, aprobaciones y otras operaciones ligeras. El mantenimiento de datos maestros también suele encajar aquí.
• Lo que se mantiene en Windows: la integración con dispositivos y periféricos, el monitoreo y procesamiento en bloque de archivos locales, el trabajo de campo que no puede detenerse aunque no haya conexión, y las pantallas de entrada rápida de datos.
• Lo que se hace común: 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 la misma base de datos). Al compartir esta parte, se logra una arquitectura que satisface la mayor parte del motivo original para migrar a la Web: “el personal de campo ingresa datos con la aplicación Windows, y la sede central los consulta al instante desde el navegador”.

Esta arquitectura tiene ventajas prácticas que no existen en una migración total a la Web: el alcance que hay que reconstruir de una sola vez es menor, se puede avanzar por etapas a partir de las partes de mayor efecto (las de consulta), y no se pierde comodidad de uso en el terreno. En contrapartida, se necesita una estructura para mantener dos sistemas, el Windows y el Web, así que si la aplicación objetivo es pequeña y sus funciones son sobre todo de consulta, a veces conviene simplemente migrarla por completo a la Web. Tampoco aquí es una disyuntiva binaria, sino una cuestión de grado.

Cabe mencionar que, para el requisito de “queremos construir la pantalla con tecnología Web, pero también necesitamos tocar recursos locales”, existe además la opción de un modelo híbrido como Electron o Blazor Hybrid (WebView2). Permite usar una interfaz con tecnología Web sin sufrir las restricciones del sandbox del navegador, pero se trata de una aplicación de escritorio que requiere distribución, así que tenga en cuenta que no es la respuesta a la solicitud de “queremos usarla solo desde el navegador”.

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

Antes de pedir un presupuesto o presentar una aprobación interna, revisar lo siguiente reduce los retrocesos:

1. Desglose del motivo: ¿cuál es el problema real: el trabajo de distribución, el lugar de uso o la obsolescencia tecnológica? Si es solo distribución, ¿no basta con cambiar el método de distribución?
2. Presencia de integración con hardware: ¿hay funciones que se comunican directamente con puerto serie, USB, instrumentos de medición o impresoras especiales? Si las hay, decida primero cómo tratar esa parte (mantenerla en Windows / arquitectura de agente).
3. Dependencia de recursos locales: ¿hay monitoreo de carpetas, procesamiento masivo de archivos o interacción de procesos con Excel u otras aplicaciones? ¿Se puede cambiar el flujo de trabajo a un modelo de procesamiento en servidor?
4. Requisito de operación sin conexión: si la red se cae durante 30 minutos, ¿ese trabajo puede esperar?
5. Peso del trabajo de ingreso: ¿hay pantallas donde se ingresan datos con el teclado todo el día? ¿Esa pantalla realmente se usa “desde cualquier lugar”?
6. Realidad de los usuarios y del lugar: ¿quién, desde dónde y qué quiere ver o ingresar? ¿Es “todos, todas las funciones, desde fuera de la empresa” o más bien “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 cuesta eso al mes?
8. Ubicación de la lógica de negocio: ¿la especificación coincide con el código? ¿Se incluyó en el presupuesto el tiempo que llevará hacer el inventario?

Si alguno de los puntos 2 a 5 aplica, recomendamos evaluar como eje una arquitectura dividida en lugar de una migración total a la Web. Para la organización general antes de contratar, consulte también “Qué conviene organizar antes de encargar el desarrollo externo de una aplicación Windows”.

Resumen

La migración a la Web es una herramienta, no un fin en sí mismo. Es claramente eficaz para el uso desde varias sedes y para reducir la gestión de equipos, pero la integración con dispositivos y el procesamiento de archivos locales son difíciles de revertir con la elección del framework o el esfuerzo de desarrollo, porque las restricciones provienen del propio diseño de seguridad del navegador, y la operación sin conexión y la entrada rápida de datos, aunque técnicamente se puedan resolver, suelen implicar un costo de desarrollo y de operación que va en sentido contrario al objetivo inicial de “abaratar las cosas migrando a la Web”. Y, además, la migración a la Web no es una portación sino una reconstrucción, a la que se suma, una vez terminada, un nuevo costo continuo: la operación del servidor.

Por eso, en la práctica, la decisión no es “migrar a la Web o no”, sino un problema de diseño: “qué función se lleva a la Web, cuál se mantiene en Windows y qué se hace común”. Desde el inventario de la aplicación existente hasta la decisión de migrar o no y el diseño de la arquitectura dividida, suele hacer falta juzgar caso por caso viendo el código y la operación real, así que si tiene dudas, consúltenos.

Artículos relacionados

• Qué conviene organizar antes de encargar el desarrollo externo de una aplicación Windows
• Prórroga y migración de aplicaciones de negocio en VB6 / Access — tabla de decisión entre mantener, envolver y 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)
• Prórroga y estrategia de salida de sistemas Web internos mediante el modo IE
• Buenas prácticas para verificar y mostrar el estado de dispositivos externos
• Fundamentos seguros de FileSystemWatcher
• Cómo construir la salida de informes en Excel

Áreas de consultoría relacionadas

KomuraSoft LLC ofrece consultoría técnica sobre la decisión de migrar o no a la Web una aplicación Windows existente, el diseño de una arquitectura dividida entre Web y Windows, y el desarrollo o la modificación de aplicaciones de negocio que incluyen integración con 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.