Si tu empresa tiene un portal de clientes, una API que conecta el ERP con la tienda en línea, un sistema de producción hecho a la medida o scripts que automatizan tareas en los servidores, hay buena probabilidad de que algo de eso corra sobre .NET o PowerShell. El martes 10 de noviembre de 2026, con el Patch Tuesday de ese mes, Microsoft publica las últimas actualizaciones para varias versiones muy usadas. A partir de ahí, ya no hay parches.
Qué vence el 10 de noviembre
Según la política de soporte de .NET y la página de ciclo de vida de PowerShell de Microsoft, consultadas el 26 de octubre de 2026:
| Producto | Tipo | Fin de soporte | Versión a la que migrar |
|---|---|---|---|
| .NET 8 | LTS (largo plazo) | 10-nov-2026 | .NET 10 (LTS, hasta 14-nov-2028) |
| .NET 9 | STS (corto plazo) | 10-nov-2026 | .NET 10 |
| PowerShell 7.4 | LTS, basado en .NET 8 | 10-nov-2026 | PowerShell 7.6 (LTS, hasta 14-nov-2028) |
| PowerShell 7.5 | Estable, basado en .NET 9 | 10-nov-2026 | PowerShell 7.6 |
| Azure Functions, modelo in-process para .NET | Modelo de ejecución | 10-nov-2026 | Modelo isolated worker |
Las últimas versiones de mantenimiento publicadas hasta ahora son la 8.0.33 y la 9.0.22, ambas del 25 de octubre de 2026. La de noviembre será la última.
Por qué importa a una PyME
El fin de soporte no apaga nada. El sistema sigue funcionando el 11 de noviembre igual que el 9. El problema llega después: cada mes Microsoft corrige fallas en el runtime de .NET, en ASP.NET Core y en PowerShell. Desde diciembre, esas correcciones solo saldrán para .NET 10 y PowerShell 7.6. Si alguien descubre una falla grave en el servidor web Kestrel o en una librería de autenticación, tu portal se queda expuesto sin remedio.
Hay tres situaciones donde el riesgo es mayor:
- Aplicaciones expuestas a internet: portales de clientes y proveedores, APIs de integración con tiendas en línea o paqueterías, apps móviles que consultan un backend propio.
- Aplicaciones "autocontenidas": Microsoft explica que en Windows las apps que dependen del runtime instalado reciben parches por Microsoft Update, pero las que traen su propio runtime empaquetado (self-contained) solo se actualizan si el desarrollador las vuelve a compilar y publicar. Muchas veces nadie lo hace.
- Sistemas cuyo proveedor ya no está: el freelance o la agencia que hizo el sistema hace tres años y al que ya no contactas. Es el caso más común y el más delicado.
Cómo saber si tu empresa usa estas versiones
No necesitas ser programador para hacer una primera revisión. Pide a quien administra tus servidores que corra estos comandos en cada equipo donde viva una aplicación interna:
# Versiones de .NET instaladas en el equipo
dotnet --list-runtimes
# Versión de PowerShell 7 (si está instalado)
pwsh -Command '$PSVersionTable.PSVersion'
Si aparece Microsoft.NETCore.App 8.x o 9.x, o Microsoft.AspNetCore.App 8.x o 9.x, ese servidor tiene runtimes que vencen el 10 de noviembre. Si pwsh responde 7.4 o 7.5, tus scripts automatizados corren en una versión que también vence. Ten presente que Windows PowerShell 5.1, el que viene con Windows, es otro producto que sigue el ciclo de vida de Windows y no está en esta lista.
Para las funciones en Azure, revisa en el portal si tus Function Apps de .NET usan el modelo in-process. Microsoft pide migrarlas al modelo isolated worker.
Qué hacer antes y después del 10 de noviembre
- Haz el inventario de aplicaciones. Lista cada sistema hecho a la medida, quién lo desarrolló, dónde corre y en qué versión de .NET está. Si ya hiciste un escaneo de vulnerabilidades de tu red, cruza la lista de servidores.
- Prioriza por exposición. Primero lo que está publicado en internet, luego lo que maneja datos de clientes o dinero, al final las herramientas internas.
- Aplica el parche de noviembre. Aunque vayas a migrar, instala las versiones 8.0 y 9.0 que salgan el 10 de noviembre: es la última corrección que recibirás.
- Planea la migración a .NET 10. Pasar de .NET 8 a .NET 10 suele ser un cambio de versión en el proyecto, actualización de paquetes NuGet y pruebas. No es reescribir el sistema, pero sí requiere que alguien compile, pruebe y publique. Pide a tu proveedor un estimado por escrito.
- Actualiza PowerShell en los servidores. Instala PowerShell 7.6 y prueba tus scripts de respaldo, altas de usuarios o reportes antes de retirar la versión anterior.
- Reduce la exposición mientras migras. Si una aplicación no se puede migrar pronto, ponla detrás de un firewall de aplicaciones web o una VPN y limita quién puede llegar a ella.
- Revisa el contrato con tu proveedor. Si alguien te da mantenimiento, el contrato de soporte debería decir quién es responsable de mantener las versiones al día.
Un mes cargado de vencimientos
El 10 de noviembre también se quedan sin parches las versiones 23H2 de Windows 11 Enterprise y Education y Windows Server 2012 R2 vive su primer Patch Tuesday sin protección. Y a fin de año vencen PostgreSQL 14 y PHP 8.2, otra base muy común en sistemas a la medida. Conviene revisar todo en una sola pasada.
Si no sabes por dónde empezar, nuestro equipo de desarrollo de software puede hacer el inventario, estimar la migración y dejarla probada, y el de ciberseguridad puede proteger lo que quede pendiente.
Fuentes: política de soporte de .NET y .NET Core (dotnet.microsoft.com), ciclo de vida de PowerShell (Microsoft Learn, actualizado el 9-sep-2026) y lista "Ending Support in 2026" de Microsoft Lifecycle, consultadas el 26 de octubre de 2026.
