PowerShell 7.6 LTS: qué cambió y cómo migrar desde el 5.1

La mayoría de los entornos Windows corporativos todavía corre Windows PowerShell 5.1 — el que viene instalado por defecto en el sistema, nunca recibió grandes actualizaciones y quedó congelado en .NET Framework. El 18 de marzo de 2026, Microsoft lanzó PowerShell 7.6 LTS, construido sobre .NET 10 (también LTS), y la pregunta que muchos sysadmins se hacen ahora es: ¿de verdad vale la pena migrar? La respuesta corta es sí.

Por qué importa "LTS" en este contexto

PowerShell 7.6 es la cuarta versión LTS del PowerShell moderno — las anteriores fueron 7.0, 7.2 y 7.4. LTS significa tres años de soporte garantizado con backport de correcciones de seguridad, sin necesidad de seguir cada versión intermedia. Para entornos con Change Control riguroso, esa estabilidad a largo plazo suele ser el único argumento que el equipo de infraestructura necesita escuchar.

El .NET 10 subyacente también es LTS, así que los ciclos quedan alineados: actualizas una vez, calificas, y el soporte llega hasta 2029. Nada de tener que renegociar la ventana de mantenimiento cada seis meses por una nueva versión non-LTS.

Qué cambió de verdad en el 7.6

El 7.6 no es una reescritura — es una versión de consolidación, con mejoras quirúrgicas que se acumulan bastante en el día a día. Los aspectos destacados confirmados por Microsoft:

• Autocompletado más inteligente: al asignar un array e intentar completar con Tab, PowerShell ahora sugiere métodos como Count y Length. La navegación en el registro de Windows también mejoró — al usar Get-ChildItem en rutas del Registro, el autocompletado sugiere subclaves correctamente en lugar de trabarse.
• PSReadLine 2.4.5: actualización del módulo de edición interactiva de la línea de comandos, con mejoras en la predicción de sintaxis y en el comportamiento del historial de comandos.
• PSResourceGet 1.2.0: el sucesor del antiguo PowerShellGet obtuvo un manejo de dependencias más robusto y descargas paralelas más confiables. Quien usa la PSGallery con frecuencia notará la diferencia.
• PSWhere() y PSForEach() como alias explícitos: los métodos intrínsecos .Where() y .ForEach() obtuvieron alias con nombre, haciendo el código más legible y los métodos más fáciles de descubrir vía Tab.
• Out-GridView vuelve a funcionar: el BinaryFormatter heredado fue reemplazado por una implementación propia y segura. Quien dependía de Out-GridView en automatizaciones y enfrentaba fallas a partir de .NET 5+ notará la corrección de inmediato.

Cómo instalar o actualizar

La forma más rápida en Windows 10/11 o Windows Server 2022/2025 es vía winget. Abre una terminal con privilegios de administrador y ejecuta:

# Instalar por primera vez
winget install --id Microsoft.PowerShell --source winget

# Actualizar desde una versión anterior de PowerShell 7.x
winget upgrade Microsoft.PowerShell

Si el entorno no tiene winget disponible (Windows Server 2019, por ejemplo), el MSI oficial está en la página de releases del proyecto en GitHub — descarga el .msi correspondiente a la arquitectura (x64 en la mayoría de los casos) y ejecútalo normalmente.

Después de la instalación, confirma la versión:

pwsh -Command '$PSVersionTable'

Deberías ver PSVersion 7.6.x y PSEdition Core. Si todavía aparece 5.1, estás ejecutando el powershell.exe antiguo, no el pwsh.exe nuevo.

Coexistencia con Windows PowerShell 5.1

PowerShell 7.x se instala en un directorio separado y usa el ejecutable pwsh.exe — distinto del powershell.exe del 5.1. Las dos versiones coexisten sin conflicto, lo que permite una migración gradual en lugar de un cambio abrupto.

El punto de atención son los módulos heredados que dependen de ensamblados de .NET Framework y no cargan en PowerShell 7. El mecanismo de compatibilidad Windows PowerShell Compatibility (importación implícita vía sesión remota al 5.1) cubre bastante, pero no es infalible. El camino más seguro es:

1. Listar los módulos que usan tus scripts: Get-Module -ListAvailable.
2. Verificar la compatibilidad en la documentación oficial de migración de Microsoft.
3. Probar scripts críticos en un entorno aislado con pwsh.exe antes de promoverlos a producción.

Si todavía estás construyendo familiaridad con los fundamentos, la guía de cmdlets básicos de PowerShell cubre lo esencial antes de pensar en migrar de versión.

Por qué dejar el 5.1 ahora

Windows PowerShell 5.1 no recibe funciones nuevas desde 2017. Mantenerlo en producción en 2026 significa renunciar a características que ya son estándar en el ecosistema moderno:

• Foreach-Object -Parallel: paralelismo nativo sin runspaces manuales — disponible desde el 7.0.
• Operadores de pipeline encadenado: && y || al estilo bash, para encadenar comandos con condición de éxito/fallo.
• Ternario y asignación nula: $x = $y ?? 'default' y $x ??= 'default' — ahorran líneas enteras de if/else.
• SSH Remoting nativo: remoting vía SSH sin depender de WinRM, especialmente relevante en entornos mixtos Linux/Windows. El tema conecta directamente con lo que tratamos sobre hardening de SSH en servidores Linux.
• Rendimiento de .NET 10: ganancias de throughput en pipelines largos que suman bastante en automatizaciones intensivas que corren decenas de veces al día.

Y si el objetivo principal es seguridad operativa, el post sobre usar PowerShell para auditar logs de seguridad en Windows trae scripts prácticos que se benefician de la madurez de Get-WinEvent en el 7.6.

¿Vale la pena actualizar ahora?

Para estaciones de trabajo y servidores de desarrollo, sí — hoy mismo. Para producción, el LTS justifica la ventana de cambio: planifica un sprint de validación, corre los scripts existentes en homologación con pwsh.exe, documenta los módulos que necesitan el modo de compatibilidad y luego promueve el cambio. No hay razón técnica para mantener el 5.1 una vez hecha la evaluación.

Si administras muchas máquinas, el winget vía Intune o un script de despliegue con PSResourceGet 1.2.0 hacen la migración a escala mucho más directa. Si tienes dudas sobre el proceso o encontraste algún módulo heredado problemático que no mencioné aquí, cuéntanos en los comentarios.