Modernización de sistemas heredados antes de que se acaben los parches: .NET 8, PHP 8.2 y Windows Server 2016 en 2026–2027

Respuesta breve: Las tres fechas críticas de 2026–2027 son el 10 de noviembre de 2026 para .NET 8 y .NET 9, el 31 de diciembre de 2026 para PHP 8.2 y el 12 de enero de 2027 para Windows Server 2016 y .NET Framework 4.6.2. En esas fechas no se apaga nada: el servidor y la aplicación siguen funcionando. Lo que termina es el suministro de parches de seguridad para las vulnerabilidades que se descubran a partir de entonces. Una buena modernización de sistemas heredados (legacy) sigue una secuencia, no el calendario: un inventario, la cadena de dependencias, una decisión independiente para cada sistema (actualizar, migrar, refactorizar, aplicar el patrón strangler fig, reescribir o retirar) y una migración por fases con plan de reversión. En este camino, el programa de actualizaciones de seguridad extendidas (ESU, Extended Security Updates) de Microsoft es un puente condicionado de hasta tres años, no un destino.

Hemos escrito esta guía para responsables de TI, CTO y propietarios de empresas con infraestructura on-premise o híbrida. También se dirige a los equipos que mantienen aplicaciones PHP/Laravel o .NET y a quienes preparan el presupuesto de TI de 2027, incluidas las empresas internacionales que operan sistemas en Turquía o trabajan con socios turcos. Cuando una norma solo se aplica en Turquía, la explicamos brevemente. Hemos verificado las fechas en las páginas de ciclo de vida de los proveedores y en sus anuncios oficiales. No indicamos precios ni ofrecemos interpretaciones jurídicas. Este artículo está actualizado a fecha de 31 de octubre de 2026.

Calendario de fin de soporte 2026–2027: ¿qué software deja de recibir parches y cuándo?

Una aclaración sobre las fechas: Las páginas de ciclo de vida de Microsoft muestran la fecha de finalización en hora del Pacífico, como las 06:59:59 del día siguiente (“1/13/2027 6:59:59 AM” para Windows Server 2016). En la tabla utilizamos los días que indican los anuncios de Microsoft. Para Windows Server 2016, el corte exacto es el 13 de enero de 2027 a las 17:59:59, hora de Turquía (UTC+3). Las fechas futuras de los proyectos de código abierto son planes; de Python 3.11, por ahora solo se conoce el mes.

¿Qué significa fin de soporte? ¿Qué es un sistema heredado?

Sistema heredado (legacy): Software o infraestructura que sigue ejecutando tareas críticas, pero cuya tecnología, versión o conocimiento técnico han quedado obsoletos. Se ha vuelto difícil de modificar y, a menudo, el soporte de su proveedor ya ha terminado o está a punto de terminar.

Fin de soporte (end of support): Fecha en la que el proveedor deja de ofrecer actualizaciones de seguridad, correcciones de errores y soporte técnico para una versión. El software sigue funcionando, pero las nuevas vulnerabilidades no se corrigen.

En los productos sujetos a la política de ciclo de vida fijo de Microsoft (Fixed Lifecycle Policy), primero termina el soporte estándar (mainstream support). Durante el soporte extendido, las actualizaciones de seguridad continúan sin costo adicional. La verdadera ruptura llega el día en que termina el soporte extendido. A partir de entonces, las actualizaciones de seguridad solo están disponibles a través del programa ESU, que Microsoft ofrece para algunos productos. En los proyectos de código abierto, el equivalente es la fecha de EOL (end of life, fin de vida útil). php.net advierte que los usuarios de una versión EOL “deberían actualizar lo antes posible, ya que pueden estar expuestos a vulnerabilidades de seguridad sin parchear”. La política de soporte de .NET de Microsoft es aún más clara: “Se recomienda encarecidamente no utilizar software sin soporte”.

No confunda el soporte estándar con el extendido: el soporte estándar de Windows Server 2022 terminó el 13 de octubre de 2026, pero sus parches de seguridad continúan hasta octubre de 2031.

¿Por qué “si funciona, no lo toque” puede salir caro?

Seguridad: Dos vulnerabilidades conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619; puntuación CVSS v4.0 de 9,2; ejecución remota de código sin autenticación) se corrigieron con versiones oficiales en todas las ramas con soporte el 21 de octubre de 2026. Para las ramas 7.4, 8.0 y 8.1, ya en fin de vida útil, el equipo de seguridad de PHP hizo una excepción por la gravedad de los fallos y compartió únicamente parches mínimos de código fuente (encontrará los detalles en nuestro artículo sobre PHP2Shell). No hay ninguna garantía de que ocurra lo mismo con la próxima vulnerabilidad.

KVKK: La KVKK es la Ley turca n.º 6698 de Protección de Datos Personales; la misma sigla designa a la autoridad nacional de protección de datos. El artículo 12 de la ley obliga al responsable del tratamiento a adoptar “todas las medidas técnicas y administrativas necesarias para garantizar un nivel de seguridad adecuado” (traducción nuestra). La Guía de Seguridad de Datos Personales de la autoridad señala además que algunos programas de uso generalizado presentan vulnerabilidades documentadas, sobre todo en sus versiones más antiguas. Incluye la gestión de parches y las actualizaciones de software entre los elementos importantes. La evaluación legal corresponde a su asesoría jurídica. El hecho técnico es este: no se pueden gestionar parches en un sistema que ya no los recibe.

Proveedor: El soporte de Microsoft 365 Apps en Windows Server 2016 terminó el 14 de octubre de 2025. Las instalaciones en estos servidores quedan congeladas en la versión 2602 y solo recibirán actualizaciones de seguridad hasta el 10 de octubre de 2028. Si ejecuta Office desde un servidor de Servicios de Escritorio remoto (RDS) con esta versión, planifique conjuntamente el sistema operativo y Office.

Primer paso: ¿cómo elaborar un inventario de sistemas heredados en 5 días hábiles?

Le recomendamos que el inventario no ocupe más de una semana de trabajo. El objetivo no es un registro de activos perfecto, sino una única tabla que sirva para tomar decisiones. Para cada sistema, anote lo siguiente:

• Servidor y sistema operativo: versión, físico o virtual, y dónde se ejecuta.
• Entorno de ejecución y framework: versiones de PHP, .NET, .NET Framework, Node.js, Python y Laravel; dependencias de paquetes.
• Base de datos: versión de SQL Server, MySQL/MariaDB o PostgreSQL.
• Hosting: cPanel/CloudLinux, IIS, un servidor on-premise o la nube.
• Integraciones: ERP, integrador de e-Fatura (el sistema turco de factura electrónica), POS virtual (pagos con tarjeta en línea), envíos, marketplaces.
• Licencias: ¿tiene Software Assurance activo, licencias de suscripción o SPLA? De ello depende que pueda obtener ESU on-premise.
• Responsable de negocio: si el sistema se detiene, ¿qué proceso se detiene y quién toma la decisión?
• Cobertura de pruebas: ¿quién verifica una actualización y cómo?
• Copia de seguridad y reversión: ¿cuándo fue la última prueba de restauración?

Después, puntúe cada sistema en dos ejes: urgencia (¿el soporte ya ha terminado o quedan 6 meses, 12 meses o más?) e impacto en el negocio (ingresos, operaciones, obligaciones legales). Los sistemas con una puntuación alta en ambos ejes forman la primera oleada. Los demás pasan al calendario.

No es una fecha, sino una cadena de dependencias: ¿qué actualización desencadena cuál?

Una actualización suele desencadenar otra. Si no ve la cadena, tendrá que intervenir dos veces en el mismo sistema en el plazo de un año. En las bases de datos, las reglas de actualización dependen del proveedor. MySQL no admite saltarse una serie al actualizar entre series LTS. MariaDB, en cambio, admite actualizar desde versiones anteriores directamente a la más reciente, sin pasos intermedios.

Fin de soporte de Windows Server 2016: .NET Framework 4.6.2 y SQL Server están en la misma cadena

El soporte de .NET Framework 4.6.2 termina el mismo día que el de Windows Server 2016. Las versiones 4.7 a 4.8.1 no tienen una fecha de finalización propia: se consideran un componente de Windows y, por tanto, siguen el ciclo de vida del sistema operativo en el que están instaladas. Esto significa que 4.8 en Windows Server 2016 también se queda sin soporte ese mismo día. Según Microsoft, 4.6.2 y las versiones posteriores son actualizaciones in situ, y se espera que las aplicaciones 4.x más antiguas funcionen sin recompilarse. Aun así, compruébelo primero en un entorno de pruebas. .NET Framework es un producto distinto de .NET 8. Si la base de datos de su ERP se ejecuta en SQL Server 2014 o 2016, la lista de compatibilidad de su proveedor de ERP determina la versión de destino. Los proveedores también pueden cambiar sus reglas de integración (un ejemplo es el paso de Mikro V17 a una API oficial; Mikro es un proveedor turco de ERP).

Fin de soporte de .NET 8: pase a .NET 10, no a .NET 9

En septiembre de 2025, Microsoft amplió STS (Standard Term Support) de 18 a 24 meses. Como consecuencia, .NET 9 también termina el 10 de noviembre de 2026, de modo que pasar a .NET 9 no le aporta ni un solo día. El destino es .NET 10 LTS (Long Term Support), con soporte hasta el 14 de noviembre de 2028. Pruebe de forma conjunta la compatibilidad de los paquetes NuGet, los cambios incompatibles (breaking changes) y su pipeline de compilación y despliegue.

PHP 8.2 EOL: Laravel 12 y la cadena del hosting

El soporte de seguridad de Laravel 12 termina el 24 de febrero de 2027, y Laravel 13 requiere PHP 8.3–8.5. Para una aplicación Laravel 12 sobre PHP 8.2, eso supone dos actualizaciones en dos meses. Laravel 12 también admite PHP 8.4, así que separe los pasos: primero PHP 8.4, después Laravel 13. En cPanel/CloudLinux, la versión de PHP suele seleccionarse por cuenta o por dominio. Antes de actualizar, revise sus dependencias de Composer, los módulos codificados y las extensiones de PHP.

¿Reescribir o refactorizar? Seis vías y una matriz de decisión para modernizar sistemas heredados

La vía adecuada depende del estado del sistema y de cuánto tiempo de inactividad pueda tolerar el negocio:

Cuatro preguntas determinan la vía:

1. ¿Hay pruebas? Si no las hay, la primera tarea es escribir pruebas de caracterización que registren el comportamiento actual.
2. ¿Están documentadas las reglas de negocio y quién tiene el código fuente y el conocimiento técnico? Las reglas sin documentar, un proveedor que ya no está o los módulos cuyo código fuente no posee reducen sus opciones.
3. ¿Cuántas integraciones y usuarios hay? Cada integración es una prueba de migración aparte.
4. ¿Qué normativa se aplica? En Turquía, la KVKK y las normas de e-Fatura influyen en cómo deben conservarse los datos durante la migración.

Si el servidor va a cambiar de ubicación, la migración a la nube también entra en la decisión. Analizamos el equilibrio entre productos estándar y desarrollo a medida en nuestros artículos sobre software a medida frente a software estándar y ERP y CRM a medida. Si ya no queda nadie que conozca el sistema, un CTO fraccional puede dirigir el proceso de decisión.

El patrón strangler fig: renovar un sistema pieza a pieza sin apagarlo

El nombre procede de una analogía de Martin Fowler. La higuera estranguladora (strangler fig) germina sobre un árbol y, a medida que echa raíces y crece, va ocupando el lugar del árbol que la hospeda. Fowler observa que los planes de reescribir un sistema heredado uno a uno fracasan la mayoría de las veces. Es difícil determinar los detalles del comportamiento actual, y gran parte de ese comportamiento es, en realidad, no deseado. La vía gradual necesita una arquitectura de transición que se desecha una vez terminado el trabajo. En opinión de Fowler, “la reducción del riesgo y el valor más temprano del enfoque gradual superan sus costos”. La guía de arquitectura de Microsoft sigue la misma idea: una fachada (proxy) se sitúa entre el cliente y los dos sistemas y, a medida que las funciones se trasladan, el enrutamiento pasa al sistema nuevo. Un ejemplo hipotético:

1. Se coloca una puerta de enlace de API (API gateway) delante de un antiguo portal de distribuidores que funciona con PHP 8.2. Todo el tráfico sigue yendo al código antiguo.
2. El comportamiento actual de la API de pedidos se registra con pruebas de caracterización y se reconstruye en un servicio nuevo.
3. Mediante un interruptor de funcionalidad, la puerta de enlace abre la nueva ruta de pedidos primero a los distribuidores piloto. Si surge un problema, se desactiva el interruptor y el tráfico vuelve al código antiguo.
4. Lo más difícil son los datos: ambos sistemas deben ver los mismos pedidos. La sincronización se configura mediante una base de datos compartida o captura de datos de cambios (CDC, change data capture), y se verifica la coherencia.
5. Los demás módulos se trasladan uno a uno. El portal antiguo se apaga al final.

¿Qué es ESU? ¿Las actualizaciones de seguridad extendidas son un puente o una trampa?

Microsoft anunció ESU para Windows Server 2016 el 25 de febrero de 2026; el programa comienza el 12 de enero de 2027. Microsoft describe ESU como “una opción de pago de último recurso”: no una solución permanente, sino un puente temporal mientras se traslada a una nueva plataforma. Las condiciones generales de la página de preguntas frecuentes de ESU son las siguientes (hoy la página cubre los programas de Windows Server 2012/2012 R2 y Windows 10):

• Duración y alcance: hasta tres años después del fin del soporte extendido; solo actualizaciones de seguridad críticas e importantes, sin soporte técnico general.
• En Azure: gratuito en máquinas virtuales de Azure.
• On-premise: de pago, ya sea por uso a través de Azure Arc o anual mediante licencias por volumen (Volume Licensing). Se requiere Software Assurance activo, licencias de suscripción (incluidas las de CSP) o SPLA.
• Reglas: con licencias por volumen, no se puede comprar el año 2 o el año 3 sin los años anteriores. Si se inscribe tarde en Azure Arc, los meses perdidos se facturan con carácter retroactivo.

En el momento de redactar este artículo, las fechas por año, los precios y las condiciones específicas de Windows Server 2016 aún no figuran en la página de ciclo de vida de Microsoft ni en las preguntas frecuentes de ESU. Confírmelos con Microsoft o con su partner de licencias. La política de soporte de .NET de Microsoft no incluye ninguna ampliación de pago para .NET 8. PHP 8.2 no recibirá correcciones de seguridad de php.net después del 31 de diciembre. php.net señala que algunas distribuciones de Linux y proveedores de LTS ofrecen correcciones retroportadas (backports) para ramas sin soporte. Si elige esta vía, pida a su proveedor que le confirme por escrito el alcance y la duración.

Nuestra regla es sencilla: vincule ESU a una fecha de migración. “Un año de ESU y después migración en una fecha fijada” es un plan. ESU sin fecha es una factura de modernización que solo se ha aplazado.

Hoja de ruta de 90 días para modernizar sistemas heredados de cara al presupuesto de TI de 2027

1. Noviembre de 2026: Complete el inventario. Migre las aplicaciones .NET 8 y 9 a .NET 10; entre las que no estén listas para el 10 de noviembre, dé prioridad a las expuestas a internet. Ensaye la actualización de PostgreSQL 14 en una copia.
2. Diciembre de 2026: Actualice las aplicaciones PHP 8.2 a 8.4 (o temporalmente a 8.3 si sus dependencias no están listas) e incluya la migración a Laravel 13 en el calendario. Tome la decisión sobre Windows Server 2016: Windows Server 2025, traslado a la nube o ESU con migración en una fecha fijada.
3. Enero de 2027: Antes del 12 de enero, ejecute la decisión o inscríbase en ESU. Para SQL Server 2014 y 2016, planifique una ventana de migración con la versión de destino que haya aprobado su proveedor de ERP.
4. Resto de 2027: Laravel 12 en el primer trimestre; Visual Studio 2017, Node.js 22 y Ubuntu 22.04 en el segundo; ESU de SQL Server 2014 en el tercero; Python 3.11, SQL Server 2017, PostgreSQL 15 y PHP 8.3 en el cuarto.

Partidas presupuestarias: inventario y consultoría; automatización de pruebas y un pipeline de CI/CD; licencias (incluido ESU si es necesario); infraestructura duplicada durante el periodo de funcionamiento en paralelo; copias de seguridad y recuperación ante desastres, incluidas las pruebas de restauración.

Cómo le ayuda Partnerfy

Gestionamos la modernización no como un gran proyecto, sino como una serie de decisiones tomadas sistema por sistema. Empezamos con un inventario y una puntuación de riesgos basados en la lista de este artículo. Después, para cada sistema, le presentamos por escrito la vía que recomendamos, con sus razones y sus riesgos. En la ejecución, primero configuramos pruebas de regresión automatizadas y un pipeline de CI/CD. Antes de cada migración, hacemos una copia de seguridad y ensayamos los pasos de reversión, y pasamos a producción por etapas. Encontrará el alcance completo en nuestra página de modernización de software. Para programar una reunión sobre el inventario, contáctenos.

Fuentes

• PHP: Versiones con soporte, Ramas sin soporte, Archivo de noticias de 2026
• .NET: Política de soporte, Anuncio sobre STS, .NET Framework, Preguntas frecuentes de .NET Framework
• Windows Server: 2016, 2012, 2012 R2, 2022, 2025, Anuncio en el blog
• Ciclo de vida y ESU: Política de ciclo de vida fijo, Página de ESU, Preguntas frecuentes de ESU
• SQL Server: 2014, 2016, 2017, 2022, 2025
• Otros: Office 2021, Office LTSC 2021, Exchange 2016, Exchange 2019, SharePoint 2016, SharePoint 2019, Visual Studio 2017, Windows 10, Microsoft 365 Apps
• Bases de datos: MySQL 8.0, MySQL LTS, MariaDB, PostgreSQL
• Entornos de ejecución: Node.js, Python, Laravel, Ubuntu
• Hosting: cPanel MultiPHP Manager, CloudLinux PHP Selector
• Patrones: Martin Fowler: Strangler Fig, Microsoft: patrón Strangler Fig
• KVKK: Ley n.º 6698 de Protección de Datos Personales (en turco), Guía de Seguridad de Datos Personales (en turco)

Preguntas frecuentes