Guía para abandonar la dependencia de sistemas en modo IE

1. Este artículo en una frase

“Usar el modo IE de forma segura mediante una operación formal, reducir la dependencia poco a poco y, finalmente, llevarla a cero” — esta es la estrategia realista. Antes de abandonarlo, hay que gestionarlo correctamente.

Terminología usada en este artículo

A continuación se resumen los términos que aparecerán repetidamente más adelante.

2. Antecedentes: ¿hasta “cuándo” se puede usar el modo IE?

Conviene tener claro que, aunque se pueda usar hasta 2029, eso no significa que se pueda dejar el asunto sin atender con tranquilidad. Este período es solo el margen para abandonarlo de forma planificada, y para no tener que apresurarse cuando 2029 esté encima, no queda más remedio que empezar a prepararse desde ahora.

3. Por qué no se puede salir de la dependencia del modo IE

El modo IE es un mecanismo que, dentro de Edge (basado en Chromium), renderiza únicamente los sitios antiguos con el motor Trident (MSHTML). Lo que asume este motor Trident es lo siguiente.

• El modo de documento (Document Mode) antiguo
• Los controles ActiveX / BHO (Browser Helper Object)
• La configuración antigua de zonas de seguridad
• La configuración de compatibilidad de Enterprise Mode

Mientras se dependa de estos elementos, actualizar solo el navegador no resuelve el problema. El primer paso es identificar la verdadera naturaleza de esa dependencia.

Problemas frecuentes en el terreno

1. Error de configuración del modo de documento → la pantalla se rompe, aparecen errores de script
2. Omisión al configurar un sitio neutral → se producen bucles de reautenticación o de redirección en el SSO (inicio de sesión único)
3. Formato incorrecto de Enterprise Mode Site List → la integración con el modo IE no admite el schema v.1, por lo que hace falta migrar al schema v.2
4. Edge solo procesa una lista de sitios → la directiva del lado de Edge tiene prioridad sobre la del lado de IE

Clasificación de la dependencia: primero, identifique “de qué depende”

4. Paso 1: medidas de prolongación — primero, opere con seguridad

1. Gestionar correctamente la lista de sitios (lo más importante)

Dejar la “recarga” en manos del usuario es peligroso. Gestiónela formalmente mediante directivas.

Lo que hay que hacer: migrar a Cloud Site List Management y gestionar de forma centralizada quién usa qué sitio en modo IE y hasta cuándo.

Ejemplo mínimo de XML de lista de sitios

La lista de sitios se escribe como un XML del schema v.2 de Enterprise Mode Site List, es decir, con <site-list> como elemento raíz. La configuración mínima es la siguiente.

<site-list version="1">
  <!-- Sitio que se abre en modo IE -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- Servidor de autenticación: se abre con el motor de origen de la navegación (sitio neutral) -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

Los puntos a tener en cuenta al escribirla son los siguientes.

• En url no se escribe el protocolo. Si se escribe contoso.local, se aplica tanto a http como a https.
• Un sitio con <open-in>IE11</open-in> se abre en modo IE.
• <compat-mode> indica el modo de documento que se usa en el lado del modo IE (IE8Enterprise, IE7Enterprise, Default, etc.).
• <open-in>None</open-in> es la especificación de un sitio neutral. Los servidores de autenticación se incluyen aquí.
• version es el número de versión de la lista de sitios. Cada vez que se actualiza la lista, se sube este valor.

Directiva de grupo usada para la distribución

Para distribuir la lista de sitios se configuran dos directivas de grupo. Ambas pueden configurarse tanto desde “Configuración de usuario” como desde “Configuración del equipo”.

Como ubicación de la lista de sitios se puede indicar una URL HTTPS (recomendado), una ruta de recurso compartido de red o una ruta de archivo local. En el lado de IE existe una directiva equivalente, «Use the Enterprise Mode IE website list» (Plantillas administrativas > Componentes de Windows > Internet Explorer), pero si se configura la directiva del lado de Edge, esta tiene prioridad. Esto permite un uso diferenciado: distribuir la lista de producción a toda la empresa mediante la directiva de IE y, solo al departamento piloto, una lista de verificación mediante la directiva de Edge.

2. Consolidar la configuración relacionada con la autenticación

Cuando interviene el SSO, es habitual que la autenticación se rompa en la transición entre el modo IE y el modo Edge.

El sitio neutral (Neutral Site) es una configuración que indica, tanto en modo IE como en modo Edge, que el sitio “se abra con el motor de origen de la navegación”. Si no se registra aquí el sitio de retransmisión de autenticación/SSO, en el instante en que se salta desde una página abierta en modo IE hacia el servidor de autenticación, se produce una redirección a Edge y la autenticación falla. La propia documentación de Microsoft explica que, para que el modo IE funcione correctamente, es necesario configurar explícitamente el servidor de autenticación/SSO como sitio neutral.

• Configurar correctamente el sitio neutral → especificar explícitamente el servidor SSO con <open-in>None</open-in>
• Configurar, si es necesario, el uso compartido de cookies (de forma predeterminada, los procesos de Edge e Internet Explorer no comparten las cookies de sesión)
• Mientras no se sepa cuál es el servidor de autenticación, capturar el registro de red con edge://net-export para identificar los destinos de la navegación
• Mientras no se pueda identificar el servidor de autenticación de ningún modo, usar temporalmente la directiva “mantener la navegación dentro de la página en modo IE” (pero desactivarla en cuanto quede confirmado)

3. Dominar las herramientas de diagnóstico

Decida en función de datos observados, no de intuición.

4. Aislar lo que definitivamente no se pueda corregir

5. Paso 2: medidas de abandono — cómo reducir la dependencia

Tabla comparativa de patrones

★ es el primer candidato en la práctica.

Cómo interpretar el “esfuerzo orientativo”

Las cifras de personas-mes de la tabla son un rango pensado para un único sistema interno, y no son cifras que se puedan usar directamente para presupuestar. Incluso dentro de un mismo patrón, pueden variar varias veces según el número de pantallas, el número de URL objetivo del modo IE, los tipos de ActiveX/BHO, el número de rutas de SSO, la cantidad de integraciones externas y el volumen de pruebas de aceptación necesarias. Considere esta tabla como una forma de comparar el “peso relativo entre patrones”.

Para presupuestar de verdad, primero cuente lo siguiente y multiplíquelo por sus propios datos históricos (esfuerzo de modificación por pantalla, esfuerzo de verificación de autenticación por ruta) para construir el total.

• Número de pantallas e informes
• Número de URL objetivo del modo IE (resultado del inventario de Enterprise Site Discovery)
• Tipos de ActiveX/BHO y si existe o no una alternativa para cada uno
• Número de rutas de autenticación/SSO
• Período en que lo antiguo y lo nuevo funcionan en paralelo
• Número de casos de pruebas de regresión y qué proporción de ellos requiere verificación manual

Cuándo usar cada patrón

La refactorización por etapas es la opción más realista.

• No hace falta reconstruirlo todo de golpe
• Basta con modernizar las pantallas o funciones una a una
• El “diseño de rutas de navegación” durante el período en que coexisten lo antiguo y lo nuevo (qué pantalla funciona con qué motor) es crucial

El wrapper WebView2 se usa para “redefinir las fronteras”.

• No es para conservar tal cual la dependencia de ActiveX o COM
• Se trasladan a la parte nativa responsabilidades del lado del sistema operativo, como “operaciones con archivos”, “integración con equipos” o “autenticación de Windows”, y se moderniza la interfaz web
• Sin embargo, tenga en cuenta que surge la responsabilidad de distribuir el WebView2 Runtime

Los microfrontends solo son eficaces cuando la “frontera de equipos” coincide con la “frontera de despliegue”. No deben adoptarse solo porque estén de moda.

La reescritura completa es el último recurso. Se limita a los casos en que la dependencia de ActiveX o BHO es tan profunda que resulta imposible de descomponer.

6. Paso 3: cómo proceder en concreto (hoja de ruta)

Evaluación → Priorización → PoC → Pruebas → Despliegue → Operación

1. Evaluación — inventario de la dependencia

• Elaborar una lista de las URL objetivo con Enterprise Site Discovery
• Visualizar las transiciones de red con edge://net-export
• Clasificar la dependencia en “modo de documento”, “ActiveX/BHO”, “autenticación”, “certificado de cliente”, “archivos/impresión” y “equipos/COM”

2. Priorización — por dónde empezar

Ordene según los siguientes criterios.

• Importancia (por orden de gravedad si se detiene)
• Número de usuarios
• Grado de exposición de seguridad
• Grado de impacto en otros sistemas
• Facilidad de separación (si la frontera es clara o no)

En particular, distinguir entre las “funciones que avanzan con solo cortar la frontera” y las “funciones que requieren trasladar toda la frontera” facilita planificar los pasos siguientes.

3. PoC (prueba de concepto) — probar a pequeña escala

Empiece por un solo flujo de trabajo que tenga “alto valor de negocio y una dependencia moderada”.

Las condiciones de éxito son las siguientes cuatro.

1. Que deje de ser necesario el modo IE
2. Que se mantenga el SSO
3. Que el rendimiento de respuesta sea de un nivel comparable
4. Que sea posible el retroceso (poder volver al estado anterior)

4. Pruebas — gestionar la coexistencia de lo antiguo y lo nuevo

• Ruta moderna → pruebas automatizadas de Edge con Playwright
• Ruta en modo IE → página de diagnóstico + verificación manual
• Durante el período de coexistencia, deje explícito qué ruta funciona con qué motor (sin esto, resulta difícil reproducir los fallos)

5. Despliegue — ampliar de forma gradual

• Distribución canario (despliegue anticipado desde una parte de los usuarios)
• Reservar una ventana de verificación con Extended Stable (ciclo de 8 semanas)
• Incorporar al flujo operativo el intervalo de actualización de la lista de sitios y el requisito de reiniciar el navegador
• No olvide que, si usa la lista de sitios en la nube, es necesario haber iniciado sesión en Edge

6. Operación — seguir reduciendo

• Recoger, mediante la función de comentarios de Cloud Site List Management, los sitios que añaden los usuarios o las configuraciones incorrectas
• Mantener un ciclo operativo que reduzca la lista objetivo del modo IE cada mes
• Las “medidas de prolongación” deben ir siempre acompañadas de una “operación de reducción”

Flujo general (diagrama de flujo)

flowchart TD
    accTitle: Hoja de ruta para el abandono del modo IE
    accDescr: Diagrama que muestra el flujo desde el inventario y la clasificación de la dependencia hasta la elección de patrón según el tipo de dependencia, pasando por PoC, pruebas, despliegue por etapas y la decisión final de retirada del modo IE
    A[Inventario de activos objetivo] --> B[Clasificación de la dependencia]
    B --> C{¿Qué tipo de dependencia es?}
    C -->|"Centrado en modo de documento/SSO"| D[Operación formal en modo IE]
    C -->|"Centrado en integración con el SO/COM"| E[Conversión en wrapper]
    C -->|"Se puede dividir por pantalla"| F[Refactorización por etapas]
    C -->|"Desarrollo paralelo con varios equipos"| G[Microfrontends]
    C -->|"La dependencia es demasiado profunda"| H[Reescritura completa]

    D --> I[Ajuste de sitio neutral y cookies]
    E --> J[Frontera WebView2/nativa]
    F --> K[Coexistencia antiguo-nuevo y sustitución por etapas]
    G --> K
    H --> L[Rediseño hacia una nueva arquitectura]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[Pruebas automatizadas y pruebas operativas]
    N --> O[Despliegue por etapas]
    O --> P[Recopilación de uso y comentarios]
    P --> Q[Reducción del alcance del modo IE]
    Q --> R[Decisión de retirada]

7. Paso 4: gobernanza — el marco de gestión

Formalizar el modo IE como una “operación de excepción”

• Para cada nueva URL que se añada al alcance del modo IE, defina siempre los siguientes elementos.
  • Propietario de negocio (quién es el responsable)
  • Propietario técnico (quién la gestiona técnicamente)
  • Fecha de caducidad (para cuándo debe abandonarse)
  • Plan alternativo (cómo se va a abandonar)
• Si la lista de sitios XML existente usa el schema v.1, migre al schema v.2, que es el que admite la integración con el modo IE
• Realice el seguimiento del historial de cambios con Cloud Site List Management o una herramienta de gestión de configuración

Consideraciones de seguridad

• Fijar y operar una versión antigua de Edge es peligroso → use las series Stable/Beta más recientes
• Si necesita un período de verificación, use Extended Stable (ciclo de 8 semanas)
• Para comprobar la calidad de las GPO, use Security Compliance Toolkit o Policy Analyzer
• Es más probable que un incidente provenga de “una operación del navegador descuidada en su entorno” que de “una vulnerabilidad del propio modo IE”

Calcular la línea temporal hacia atrás

• Fin del soporte del modo IE: 2029
• Fin de las actualizaciones de Edge/WebView2 en Win10 22H2: octubre de 2028

Estos son “los límites externos del plazo de retirada”. Antes que nada, hay que elaborar una tabla calculada hacia atrás para llevar la dependencia a cero antes de que expire el soporte.

8. Estrategia recomendada según el tamaño

Las cifras de personas-mes de esta tabla también son un rango bajo las mismas premisas que el “esfuerzo orientativo” del paso 2. Si las condiciones típicas (número de pantallas, complejidad del SSO, número de departamentos) difieren mucho de las de su organización, no las aplique tal cual: recalcule el total a partir de su propio número de pantallas y de rutas.

9. Errores frecuentes y cómo evitarlos

10. Resumen

Estrategia estándar = Operación formal en modo IE (prevención de incidentes)
                       + Visualización de la dependencia (inventario)
                       + Reducción por etapas (abandono uno a uno)

• En pequeña escala, refactorización por etapas
• En gran escala, control de la lista de sitios + gestión de cartera
• Con presupuesto ajustado, contener mediante virtualización mientras se detienen las nuevas dependencias
• La reescritura completa es el último recurso
• Los contenedores quedan normalmente fuera de las opciones, el VDI es un refugio temporal y el modo IE es la pista de despegue (sirve para poder despegar)

Referencias

• Preguntas frecuentes sobre el ciclo de vida de IE y Edge — la política de 2029 para el modo IE
• Introducción al modo IE — documento básico sobre el alcance del soporte
• Configuración de directivas del modo IE — las tres etapas de la configuración de integración
• Enterprise site configuration strategy — sitios neutrales, uso compartido de cookies, schema v.2
• Enterprise Mode schema v.2 guidance — elementos y ejemplos de escritura del XML de la lista de sitios
• Introducción a los canales de actualización de Microsoft Edge — los ciclos de Stable y Extended Stable
• IE mode troubleshooting and FAQ — la página de diagnóstico y el uso de net-export
• Cloud Site List Management — gestión centralizada desde el centro de administración
• Enterprise Site Discovery — el punto de partida del inventario
• Documentación de WebView2 — para valorar la conversión en wrapper
• Azure Virtual Desktop / RemoteApp — como medida de aislamiento
• Guía de migración de Windows Containers — no adecuada como destino de prolongación de GUI
• App Assure — el alcance del soporte de configuración del modo IE
• Playwright — pruebas automatizadas de Edge
• single-spa — los fundamentos de los microfrontends
• webpack Module Federation — integración de compilaciones independientes

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.

¿Hasta cuándo se puede usar el modo IE de Edge?

El modo IE de Edge tiene soporte previsto al menos hasta 2029, con la política de notificar la retirada con un año de antelación. Además, las actualizaciones de Edge / WebView2 Runtime en Windows 10 22H2 llegan al menos hasta octubre de 2028. Sin embargo, este período es solo el margen para abandonarlo de forma planificada, y 2029 debe entenderse no como la fecha para empezar a prepararse, sino como el plazo hacia el que calcular hacia atrás la finalización del abandono. La propia aplicación de escritorio IE11 ya está retirada.

¿Por qué no se puede salir de la dependencia del modo IE?

El modo IE es un mecanismo que, dentro de Edge (basado en Chromium), renderiza únicamente los sitios antiguos con el motor Trident (MSHTML), y es este Trident el que asume el modo de documento antiguo, los controles ActiveX y BHO, la configuración antigua de zonas de seguridad y la configuración de compatibilidad de Enterprise Mode. Mientras se dependa de estos elementos, actualizar solo el navegador no resuelve nada. El primer paso es clasificar la dependencia en modo de documento, ActiveX/BHO, autenticación/SSO, integración del lado del cliente y premisas operativas antiguas, para identificar su verdadera naturaleza.

¿Qué métodos existen para abandonar el modo IE?

Las principales opciones son seis: continuar operando en modo IE, el wrapper WebView2, la refactorización por etapas, los microfrontends, la reescritura completa y el aislamiento con VDI/RemoteApp. En la práctica, el primer candidato es la refactorización por etapas, que permite modernizar pantallas o funciones una a una. El wrapper WebView2 no se usa para conservar ActiveX, sino para trasladar a la parte nativa responsabilidades del lado del sistema operativo, como operaciones con archivos o integración con equipos, y redefinir así la frontera. La reescritura completa es el último recurso cuando la dependencia es demasiado profunda para descomponerla.

Si se sigue usando el modo IE por ahora, ¿qué se debe hacer?

Primero, gestionar la lista de sitios formalmente mediante directivas, en lugar de dejar la recarga en manos del usuario. Migrar a Cloud Site List Management permite distribuir varias listas, llevar historial de cambios y asignar por grupo. Cuando interviene el SSO, hay que configurar correctamente los sitios neutrales y, si es necesario, el uso compartido de cookies. Además, a toda nueva URL objetivo del modo IE se le debe asignar siempre un propietario de negocio, un propietario técnico, una fecha de caducidad y un plan alternativo, dentro de un ciclo operativo que reduzca la lista objetivo cada mes.

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.