PowerShell 7.4 y 7.5 llegan al fin de soporte: cómo planificar la migración empresarial a 7.6 LTS

1. La decisión de lifecycle: qué ha cambiado

Microsoft fija el 10 de noviembre de 2026 como fecha de fin de soporte de PowerShell 7.4 LTS y PowerShell 7.5. La rama 7.4 está basada en .NET 8 LTS; la rama 7.5, en .NET 9. PowerShell 7.6 es la línea LTS actual, basada en .NET 10, con soporte previsto hasta el 14 de noviembre de 2028.

El repositorio oficial de PowerShell publicó 7.6.10 el 10 de noviembre de 2026. Hay que separar la fecha del release de la disponibilidad en cada canal de distribución: algunas páginas de instalación de Microsoft todavía muestran ejemplos con versiones anteriores. En un despliegue gobernado, fija artefacto, versión, arquitectura, origen y SHA-256; no dejes que una pipeline elija silenciosamente “la última versión”.

El fin de soporte significa que esa rama deja de recibir nuevas actualizaciones bajo su ciclo de mantenimiento. Puede existir una excepción temporal por compatibilidad, pero debe tener propietario, riesgo aceptado, controles compensatorios y fecha de salida.

2. Primero separa PowerShell 7 de Windows PowerShell 5.1

PowerShell 7 no sustituye a Windows PowerShell 5.1. Se instala en otra ubicación y ambos pueden convivir. Esto es relevante en Windows Server, donde todavía existen módulos o herramientas que dependen de .NET Framework, componentes del sistema o comportamientos específicos de Windows PowerShell.

El alcance no debería definirse como “actualizar todos los servidores Windows”, sino como “identificar cada ejecución de PowerShell 7.4/7.5 y migrar las cargas compatibles, manteniendo una ruta controlada para las que todavía dependen de 5.1”.

• Consolas y estaciones administrativas.
• Scripts programados en Task Scheduler y tareas de mantenimiento.
• Servicios, agentes y procesos que invocan pwsh.exe.
• Runners de CI/CD, herramientas de configuración y automatización remota.
• Contenedores e imágenes base que incluyen PowerShell.
• Jump servers, hosts de administración y servidores de automatización.

La distinción operativa importante es qué ejecutable llama cada consumidor. Un script que usa powershell.exe puede seguir ejecutándose en 5.1; una tarea que invoca una ruta absoluta de pwsh.exe puede quedar vinculada a una versión o ubicación concreta.

3. Inventario: no empieces por el instalador

El inventario debe responder al menos a cuatro preguntas: qué versión está instalada, cómo se instaló, qué la invoca y qué módulos necesita. Una sesión interactiva que devuelve $PSVersionTable no descubre tareas programadas, agentes, contenedores ni referencias a rutas absolutas.

3.1 Detectar instalaciones registradas

En Windows puedes consultar las claves estándar de desinstalación. Evita Win32_Product como método de discovery: su consulta puede disparar comprobaciones de consistencia de Windows Installer y no es una fuente adecuada para inventariar una flota.

$uninstallRoots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

$powerShellInstalls = foreach ($root in $uninstallRoots) {
  Get-ItemProperty -Path $root -ErrorAction SilentlyContinue
}

$powerShellInstalls |
  Where-Object { $_.DisplayName -match '^PowerShell 7' } |
  Select-Object DisplayName, DisplayVersion, InstallLocation, Publisher

Este método cubre las instalaciones que registran su paquete en esas claves. No es suficiente para ZIP, despliegues portables o ejecutables fuera del PATH. Compleméntalo con resolución de comandos:

Get-Command pwsh -All -ErrorAction SilentlyContinue |
  Select-Object Name, Source, Version, CommandType

3.2 Discovery remoto controlado

Si WinRM está habilitado y autorizado, puedes iniciar un inventario sobre una lista aprobada de equipos. Ejecuta primero contra un grupo piloto, limita la concurrencia a la capacidad de administración disponible y guarda los resultados en una ubicación protegida.

$computers = Get-Content .\servers-pilot.txt |
  Where-Object { $_ -and $_ -notmatch '^\s*#' }

$inventory = Invoke-Command -ComputerName $computers -ScriptBlock {
  $roots = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
  )

  foreach ($root in $roots) {
    Get-ItemProperty $root -ErrorAction SilentlyContinue |
      Where-Object { $_.DisplayName -match '^PowerShell 7' } |
      Select-Object @{n='ComputerName';e={$env:COMPUTERNAME}},
        DisplayName, DisplayVersion, InstallLocation
  }

  Get-Command pwsh -All -ErrorAction SilentlyContinue |
    Select-Object @{n='ComputerName';e={$env:COMPUTERNAME}},
      @{n='DisplayName';e={'Command resolution'}}, Source, Version
}

$inventory |
  Export-Csv .\powershell-inventory.csv -NoTypeInformation -Encoding utf8

Este ejemplo es una primera fotografía, no un sistema exhaustivo de discovery. Correlaciona sus resultados con CMDB, Intune/Configuration Manager, inventario de software, repositorios, definiciones de pipeline, tareas programadas y configuración de servicios.

4. Compatibilidad: donde se concentran los riesgos

La migración suele ser menos problemática en el motor que en las dependencias periféricas: módulos, runtimes nativos, autenticación, perfiles, rutas de ejecutables, serialización y supuestos heredados de Windows PowerShell.

4.1 Módulos, edición y dependencias nativas

Registra qué módulos se cargan, desde dónde, qué versiones se han validado y qué dependencias nativas necesitan. Revisa especialmente módulos internos, binarios, módulos basados en .NET Framework y módulos que instalan dependencias por separado.

Get-Module -ListAvailable |
  Sort-Object Name, Version |
  Select-Object Name, Version, PSEdition, CompatiblePSEditions, Path

No basta con que Import-Module termine sin error. Comprueba las operaciones reales: autenticación, permisos, conexiones, paginación, serialización, formatos de fecha, llamadas nativas y tratamiento de errores.

4.2 Cambio relacionado con ThreadJob

En PowerShell 7.6, el módulo ThreadJob se sustituye por Microsoft.PowerShell.ThreadJob. El cmdlet Start-ThreadJob mantiene su nombre; sin embargo, los scripts que importan o invocan el módulo usando su nombre cualificado deben revisarse.

Get-ChildItem .\automation -Filter *.ps1 -Recurse |
  Select-String -Pattern 'ThreadJob\\Start-ThreadJob|Import-Module\s+ThreadJob'

Trata el resultado como una señal para revisar, no como prueba de incompatibilidad. Valida en el mismo host, con la misma cuenta de servicio, perfiles, políticas y contexto operativo que ejecutarán la carga.

4.3 Windows PowerShell Compatibility

Algunos módulos heredados pueden ejecutarse mediante la capa de compatibilidad, que utiliza un proceso local de Windows PowerShell. No asumas equivalencia completa: existen límites de serialización de objetos, sesiones, rendimiento y comportamiento funcional. Para cada dependencia heredada, decide si se mantiene temporalmente en 5.1, se ejecuta por compatibilidad o se sustituye.

5. Modelo de despliegue recomendado

Utiliza anillos y separa el cambio de runtime del cambio de lógica de los scripts. No actualices a la vez PowerShell, módulos, credenciales y automatizaciones: si algo falla, perderás la capacidad de atribuir la causa.

5.1 Elegir el artefacto adecuado

• Windows Server: Microsoft identifica MSI como opción apropiada para escenarios de servidor y despliegue empresarial. Elige arquitectura y propiedades de instalación de acuerdo con tu baseline.
• Windows cliente: WinGet es una vía soportada, pero disponibilidad y formato dependen de la plataforma y del origen. Verifica el paquete antes de darlo por válido.
• Linux: usa el repositorio y paquete correspondiente a la distribución soportada; fija versión y origen en la gestión de configuración.
• ZIP: útil para laboratorio y escenarios avanzados de side-by-side, pero exige gestionar PATH, accesos directos, actualizaciones y requisitos manualmente.

Para que el cambio sea reproducible, conserva el instalador aprobado, SHA-256, versión, arquitectura, fuente de descarga, opciones de instalación e identificador del cambio. La página de instalación de Microsoft y los feeds de paquetes pueden mostrar una versión distinta de la última release publicada en GitHub: registra cuál has decidido desplegar y por qué.

# Verificar el hash del paquete antes de distribuirlo
Get-FileHash .\PowerShell-7.6.10-win-x64.msi -Algorithm SHA256

# Confirmar la versión después de instalar
& "$env:ProgramFiles\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command '$PSVersionTable | Format-List'

En MSI, propiedades como USE_MU, ENABLE_MU, ENABLE_PSREMOTING, REGISTER_MANIFEST y ADD_PATH afectan al resultado de instalación y a la operación posterior. No habilites remoting ni modifiques PATH en toda la flota sin una decisión de seguridad y operación.

6. Validación y rollback: criterios de aceptación

La validación debe observar el servicio que ejecuta el script, no solo que pwsh.exe arranque. Por cada automatización crítica registra código de salida, duración, errores, resultado funcional y dependencias externas.

1. Arranque con -NoProfile y versión esperada.
2. Importación de módulos con la cuenta de servicio real.
3. Autenticación contra endpoints y recursos usados por la carga.
4. Lectura y escritura en las rutas y almacenes requeridos.
5. Tratamiento de errores, códigos de salida y logging.
6. Ejecución programada y remota, no solo ejecución interactiva.
7. Rendimiento dentro del baseline acordado.

Antes del cambio conserva el paquete exacto anterior, parámetros de instalación, módulos y configuración. En una actualización MSI convencional una versión nueva puede sustituir a la anterior: no presupongas que el rollback consiste en cambiar una ruta. Define el método de reinstalación o restauración, impacto de reinicio si aplica, ventana de observación y autoridad que aprueba la reversión.

Si necesitas comparar versiones de PowerShell 7 en paralelo, una instalación ZIP en un directorio separado puede ser útil para laboratorio. No conviertas esa vía en mecanismo permanente de producción sin gestionar PATH, tareas, servicios y actualizaciones.

7. Runbook de cambio

8. Fuentes primarias y notas de verificación

1. Microsoft Learn — PowerShell Support Lifecycle. Fechas de soporte, canales LTS/Stable y plataformas admitidas.
2. PowerShell/PowerShell — Release v7.6.10. Publicación del 10 de noviembre de 2026, artefactos y hashes oficiales.
3. Microsoft Learn — Installing PowerShell on Windows. MSI, MSIX, WinGet, ZIP, actualización y coexistencia con Windows PowerShell 5.1.
4. Microsoft Learn — What's New in PowerShell 7.6. Cambios documentados, incluido ThreadJob.
5. PowerShell/PowerShell — Releases. Historial de releases y artefactos.

Última revisión documental: 11 noviembre 2026. Guía de planificación contrastada con documentación pública; no se afirma validación práctica en una flota real. Prueba los comandos en un entorno representativo antes de usarlos en producción.