Puntos clave
- Una política de gobernanza de fin de vida (EOL) eficaz parte de criterios de retirada bien definidos y de estándares de ciclo de vida documentados.
- Separar y monitorizar los activos heredados ayuda a los MSP a detectar riesgos antes de que afecten a sus clientes.
- La automatización, las revisiones con las partes interesadas y los flujos de trabajo de retirada estructurados simplifican la gestión de los dispositivos EOL.
- Usar plataformas de gestión de activos como NinjaOne te ayuda a mantener una documentación coherente y a agilizar la gobernanza del fin de vida.
Los equipos que han llegado al fin de su vida útil (EOL), es decir, el hardware obsoleto o muy específico, siguen inflando los costes y generando riesgos si no se retiran del entorno técnico del cliente. Para los proveedores de servicios gestionados (MSP) es esencial identificar, controlar y retirar estos dispositivos de forma proactiva para poder ofrecer el mejor servicio. Sigue leyendo para descubrir cómo crear una política EOL para equipos heredados y de nicho en entornos de cliente.
Si prefieres una visión general rápida en vídeo, echa un vistazo a nuestra guía sobre cómo crear una política de gobernanza de fin de vida para equipos heredados y de nicho.
Cómo crear una política de gobernanza para dispositivos EOL
Una política estructurada debería ayudar a los MSP y a los equipos de TI a retirar los dispositivos del servicio de forma proactiva, en lugar de ocuparse del equipamiento obsoleto solo cuando empieza a dar problemas. Además, garantiza que todas las decisiones de retirada sean coherentes, queden documentadas y cumplan los requisitos aplicables.
📌 Requisitos previos:
- Datos de inventario de cliente precisos, con información de cada dispositivo (fechas de despliegue, versiones del sistema operativo y cobertura de garantía)
- Acuerdo entre las partes interesadas sobre las responsabilidades de soporte y retirada
- Acceso a herramientas de seguimiento y automatización (por ejemplo, hojas de seguimiento compartidas, NinjaOne, un PSA o scripts propios)
- Conocimiento de los requisitos de cumplimiento aplicables (por ejemplo, HIPAA, PCI, ISO 27001)
Define el alcance y los criterios de retirada
Empieza por definir qué dispositivos están sujetos a retirada y detalla las condiciones que activarán el proceso. Así evitarás decisiones incoherentes, dispositivos que pasan desapercibidos y desacuerdos con los clientes.
Lo primero es identificar las categorías de dispositivos incluidas en el alcance, como:
- Dispositivos heredados: hardware que ha superado el ciclo de vida con soporte de tu organización (normalmente entre 5 y 7 años) o que está fuera de garantía
- Equipos especializados: dispositivos de nicho en laboratorios, kioscos o con software propietario
- Activos sin soporte: dispositivos que ya no reciben actualizaciones de SO, controladores o firmware
- Dispositivos no conformes: carecen de las funciones de seguridad exigidas (por ejemplo, TPM o cifrado)
A continuación, define los desencadenantes de la retirada, como:
- Fin del soporte del fabricante: hardware o software que ya no recibe mantenimiento
- Incumplimiento del nivel mínimo de seguridad: SO sin soporte o sin parches disponibles
- Redundancia: la función del dispositivo ha quedado obsoleta tras mejorar la infraestructura
- Riesgo operativo: fallos frecuentes, impacto por tiempo de inactividad o problemas de rendimiento
También es buena idea establecer un marco de excepciones, con prórrogas temporales o dispositivos críticos para el negocio que requieran una justificación documentada para seguir en uso.
Crea una plantilla formal de política EOL
El siguiente paso es estandarizar la documentación de estas decisiones de retirada. Debería ofrecer un marco repetible que garantice la coherencia y evite ambigüedades durante auditorías, QBR o revisiones de presupuesto. La idea es registrar siempre los mismos campos, como estos:
| Campo | Descripción/finalidad | Ejemplo de entrada |
| Categoría del dispositivo | Define el tipo de equipo al que se aplica la política | «Estaciones de trabajo heredadas con Win7», «Sensores IoT sin TLS» |
| Periodo de soporte | Duración estándar del soporte antes de la retirada | «7 años desde el despliegue» o «SO con soporte +12 meses (o según la política de ciclo de vida de tu organización)» |
| Fecha de fin de soporte | Última fecha formal de soporte del dispositivo | «31/12/2026» |
| Pasos de retirada | Acciones paso a paso para dar de baja el equipo de forma responsable | Copia de seguridad → Retirada → Borrado de datos → Sustitución |
| Flujo de notificaciones | Plan de comunicación con las partes interesadas | Correo de aviso 90 días antes → Recordatorio a 30 días → Aviso final |
| Responsable | Persona o equipo encargado de la revisión, la aprobación y la ejecución | Responsable de TI, vCIO del cliente o responsable de operaciones del MSP |
| Gestión de excepciones | Recoge las condiciones para prórrogas temporales o aprobaciones especiales | «Revisión trimestral; requiere aprobación del CIO» |
| Notas de auditoría | Espacio para registrar la confirmación de la retirada, la verificación del borrado y las referencias de archivo | «Dispositivo retirado el 30/06/2024: borrado verificado» |
Guarda toda la información recopilada en un repositorio compartido (por ejemplo, SharePoint, Google Drive o la base de conocimientos de tu PSA) y alinéala con el resto de la documentación del ciclo de vida (como los procedimientos de alta o de renovación), para que se convierta en un estándar vivo que garantice la coherencia.
Segmenta y controla los activos heredados por separado
Controlar los dispositivos heredados aparte del inventario principal que usas para la gestión diaria del parque es una buena práctica para que no se te pasen por alto. Esta segmentación ayuda a los MSP a monitorizar el riesgo, planificar las sustituciones y explicar a los clientes qué activos son excepciones al proceso estándar de ciclo de vida.
Al hacer el seguimiento de estos activos, incluye campos como:
- Nombre y modelo del dispositivo
- Función o uso dentro del negocio
- Fecha de despliegue y antigüedad actual
- Estado EOL actual (aviso, caducado, excepción)
- Fecha prevista de sustitución o retirada
Valora combinar las siguientes fuentes para tener una visión clara y accionable de todos los sistemas heredados:
- Campos personalizados de NinjaOne para la función y la fase del ciclo de vida
- Un Excel o una hoja de cálculo compartida para la visibilidad conjunta
- Etiquetas como EOL_Warning, Legacy_OS o Unsupported_Hardware
Detecta candidatos automáticamente con scripts ligeros
Plantéate automatizar las revisiones de EOL para acelerarlas. Puedes ejecutar scripts pequeños y seguros en los endpoints o sobre el inventario de tu RMM para localizar dispositivos que probablemente hayan superado su vida útil. Después, canaliza esos resultados hacia tu hoja de seguimiento y tus flujos de trabajo.
Aquí tienes un script de PowerShell de ejemplo que puedes ejecutar en local, mediante la automatización de NinjaOne o sobre un grupo de dispositivos para detectar equipos que se acercan a los umbrales de EOL:
| $cutoff = (Get-Date).AddYears(-5) $info = Get-ComputerInfo $installDate = [datetime]$info.OsInstallDateif ($installDate -lt $cutoff) { [PSCustomObject]@{ ComputerName = $info.CsName OsInstallDate = $installDate } | Export-Csv -Path "EOL_Candidates.csv" -NoTypeInformation} |
En este script:
- $cutoff = (Get-Date).AddYears(-5) define tu umbral de antigüedad. En este ejemplo se marcan los dispositivos instalados hace más de 5 años. Ajústalo a 6 o 7 años si esa es tu política interna.
- Get-ComputerInfo recopila los detalles del sistema local, incluidos la fecha de instalación del SO y el nombre del equipo.
- if ($installDate -lt $cutoff) comprueba si la fecha de instalación es anterior al umbral.
- [PSCustomObject] da formato a la salida en un objeto limpio y estructurado.
Export-Csv -Path "EOL_Candidates.csv" -NoTypeInformationexporta los resultados a un archivo CSV que puedes adjuntar a un ticket, importar en tu hoja de seguimiento de EOL o cargar en tu sistema PSA.
También puedes mejorar la detección comprobando lo siguiente:
- La versión del SO o su proximidad al fin del ciclo de vida (por ejemplo, Windows 10 llegó al fin del soporte general el 14 de octubre de 2025; los dispositivos no inscritos en el programa de Extended Security Updates (ESU) de Microsoft ya no reciben parches de seguridad, y el propio ESU solo amplía la cobertura hasta el 12 de octubre de 2027
- Carencias en el nivel mínimo de seguridad (por ejemplo, presencia de TPM, Arranque seguro, cifrado de disco, antivirus o EDR con soporte)
- Función y criticidad del dispositivo
- Garantía frente a antigüedad
- Fecha de la última sustitución o renovación
- Constancia del tiempo de actividad o uso desatendido
Un flujo de trabajo práctico sería algo así:
- Ejecuta el script base de forma programada (por ejemplo, cada noche o cada semana), según la frecuencia de revisión de tu organización.
- Añade campos adicionales (versión del SO, TPM, garantía) a la misma exportación.
- Etiqueta en NinjaOne los endpoints marcados (EOL_Warning, Unsupported_OS, No_TPM).
- Sincroniza el CSV con tu hoja de seguimiento de EOL compartida (o añádelo automáticamente mediante la API).
- Genera tickets en el PSA o informes para las QBR de todo lo que esté «Sin soporte» o a «< 90 días del fin de soporte».
Avisa a las partes interesadas y programa revisiones
Una vez marcados los candidatos a EOL, habla con tus clientes y ofréceles revisiones estructuradas para que el proceso sea transparente. Tienen que saber qué va a pasar para poder presupuestarlo y no llevarse sorpresas con retiradas repentinas. Algunas buenas prácticas:
- Usa alertas y tickets generados automáticamente en el PSA cuando los dispositivos superen los umbrales de antigüedad o de soporte.
- Programa revisiones trimestrales alineadas con las QBR y los ciclos presupuestarios.
- Envía avisos escalonados (por ejemplo, aviso 90 días antes → recordatorio a 30 días → notificación final de retirada).
- Comparte con los clientes informes que destaquen los dispositivos marcados, su estado y las recomendaciones de retirada.
Gestiona el flujo de aprobación y retirada
Los equipos marcados como EOL siguen necesitando un proceso claro y con responsabilidades definidas antes de retirarse, sobre todo cuando su función es crítica o muy específica. Así evitarás retirar activos de forma prematura y permitirás que los clientes participen en la decisión.
Valora este flujo, que equilibra el riesgo operativo con la transparencia hacia el cliente:
- Desencadenante: el dispositivo cumple los criterios de EOL (antigüedad, SO sin soporte, carencia de cumplimiento).
- Notificación: el responsable asignado (responsable de operaciones del MSP, responsable de TI o vCIO) recibe una alerta o un ticket.
- Revisión: valora si conviene prolongar su vida útil, aislarlo o sustituirlo, y ten en cuenta la criticidad para el negocio, el uso especializado o las solicitudes de excepción.
- Aprobación: se requiere el visto bueno formal de la dirección de TI o del contacto del cliente antes de actuar.
- Ejecución: lleva a cabo los pasos de retirada (copia de seguridad, borrado de datos, retirada o sustitución del hardware, etc.)
- Archivo: actualiza la hoja de seguimiento con la fecha de retirada, la confirmación del borrado y las notas.
- Conservación: guarda los registros para auditorías, cumplimiento y consultas futuras.
Cierra el círculo con el archivo y las notas de auditoría
El último paso es documentar correctamente cada dispositivo retirado, por seguridad y trazabilidad. No te olvides de estas tareas:
- Actualiza la hoja de seguimiento: registra la fecha de retirada, los datos del equipo sustituto y la confirmación del borrado de datos.
- Archiva los registros: guárdalos en una carpeta segura y centralizada para estar listo ante una auditoría.
- Pruebas de cumplimiento: conserva notas vinculadas a los requisitos normativos (HIPAA, PCI, ISO, etc.).
- Informes para las QBR: usa los datos archivados para demostrar a los clientes una reducción medible de la deuda tecnológica.
Resumen de buenas prácticas
Tu política de gobernanza de EOL debe ser sencilla, repetible y transparente. Estas son algunas buenas prácticas que ayudan a los MSP a evitar puntos ciegos, reducir el trabajo manual y ganarse la confianza del cliente
| Elemento | Finalidad |
| Criterios de EOL claros | Elimina las dudas sobre cuándo y por qué debe retirarse un dispositivo |
| Documentación estándar | Garantiza que cada retirada siga un proceso repetible y transparente |
| Segmentación del inventario | Marca los dispositivos en riesgo sin saturar los informes del parque principal |
| Automatización ligera | Reduce el seguimiento manual y saca a la luz candidatos de forma eficiente, sobre todo en parques grandes |
| Revisión y aprobación formales | Mantiene el cumplimiento intacto y alinea la comunicación con el cliente con las decisiones tomadas |
| Registros de retirada listos para auditoría | Aportan trazabilidad, favorecen el cumplimiento y demuestran diligencia debida |
Por qué importa tener una política de gobernanza para los equipos EOL
El hardware obsoleto, como los equipos muy específicos o heredados, puede convertirse rápidamente en un lastre por la falta de soporte, parches y otras actualizaciones críticas, lo que expone los sistemas a riesgos graves. Una política de gobernanza de EOL para este tipo de equipos debería ayudarte a:
- Reducir los riesgos de seguridad: retirar o aislar de forma inteligente los endpoints inseguros y vulnerables es clave antes de que se conviertan en puerta de entrada de amenazas hacia el resto del sistema.
- Garantizar la continuidad operativa: los equipos heredados pueden fallar en cualquier momento. Unos criterios formales de retirada deberían facilitar su sustitución cuanto antes y reducir al mínimo el tiempo de inactividad.
- Estar preparado para las auditorías de cumplimiento: una política que documente con claridad cómo y cuándo se retiran los dispositivos sin soporte ayuda a las organizaciones a cumplir normativas como HIPAA, PCI o ISO, y evita conclusiones de negligencia en las revisiones de seguridad.
- Apoyar la planificación financiera y el control de costes: los clientes pueden anticipar las fechas de sustitución y ajustar sus presupuestos a la gestión del ciclo de vida de los equipos.
- Mejorar la comunicación y las expectativas del cliente: gestionar el ciclo de vida de los dispositivos de forma sistemática y con flujos de notificación formales aumenta la confianza y la transparencia.
Puntos de integración con NinjaOne
NinjaOne no incluye una lógica de gobernanza de EOL integrada, pero sí ofrece a los MSP la visibilidad y el marco de automatización necesarios para dar soporte a este proceso de gobernanza. Estos son algunos de los métodos de integración clave:
| Método de integración | En qué ayuda | Ejemplo de uso |
| Campos personalizados | Almacenan detalles del ciclo de vida (estado EOL, última renovación, nivel de riesgo) | Filtrar los dispositivos próximos a su retirada durante las revisiones |
| Informes programados | Generan automáticamente informes de versiones de SO sin soporte o despliegues antiguos | Compartirlos en las QBR para poner el foco en la deuda tecnológica |
| Scripts automatizados | Ejecutan comprobaciones de antigüedad, versión del SO o funciones de seguridad ausentes | Etiquetar y exportar automáticamente los endpoints marcados a tu hoja de seguimiento de EOL para revisarlos |
| Políticas de alertas | Lanzan notificaciones proactivas cuando los dispositivos cumplen los criterios de EOL | Crear tickets en el PSA cuando finaliza el soporte del SO |
| Exportación de datos | Exporta los datos de los dispositivos para hojas de seguimiento o trabajo en equipo | Sincronizar los informes de NinjaOne con Excel/hojas de cálculo o con los paneles del PSA |
| Etiquetas | Clasifican y marcan visualmente los dispositivos según su estado de ciclo de vida o su riesgo | Aplicar etiquetas como EOL_Warning, Legacy_OS o Unsupported_Hardware para filtrar rápido y activar automatizaciones |
Guía de inicio rápido
NinjaOne ofrece varias funciones clave para ayudarte a gestionar los equipos que llegan al fin de su vida útil:
1. Gestión de activos de TI (ITAM)
- Controla dispositivos sin soporte nativo (teléfonos, cámaras, impresoras, etc.)
- Crea tipos y funciones de dispositivo personalizados
- Añade campos personalizados para registrar información adicional de cada dispositivo
2. Gestión del ciclo de vida de los dispositivos
- Usa funciones de dispositivo personalizadas para clasificar los equipos heredados o de nicho
- Añade etiquetas para controlar el estado de los dispositivos
- Monitoriza el estado de los dispositivos y sus vulnerabilidades
3. Seguimiento de dispositivos no gestionados
- Añade al sistema los dispositivos no gestionados
- Registra información, actividades y notas de cada dispositivo
- Usa campos personalizados para anotar el estado de fin de vida o los planes de sustitución
La gobernanza del fin de vida como ventaja estratégica
Una política de gobernanza de fin de vida (EOL) para equipos heredados y de nicho en entornos de cliente aporta estructura a un proceso de alto riesgo como es la retirada de dispositivos. Los pasos anteriores deberían ayudar a los MSP a reducir los riesgos de seguridad y garantizar el cumplimiento, siempre en línea con las necesidades de sus clientes. Sigue siempre las buenas prácticas para crear un flujo de trabajo que te consolide como socio estratégico de tus clientes.
Temas relacionados:
