Viernes por la tarde, el antiguo controlador de WiFi vuelve a estar sobrecargado. La recepción de un hotel está reiniciando los puntos de acceso entre registros de entrada, una tienda minorista está perdiendo la conectividad de pago, una sala de hospital informa de una movilidad clínica poco fiable o los residentes de un edificio gestionado hacen cola ante una oficina de soporte porque el portal del inquilino ha dejado de autenticar. El programa de migración ya se ha retrasado y cada solución temporal ahora se encuentra dentro del entorno de producción.
Esa situación es el punto de partida para la migración de sistemas heredados. El problema no es que el hardware o el software sean antiguos. El problema es que una organización ha construido un modelo operativo en torno a una infraestructura frágil, dependencias no documentadas, administración manual, soporte caducado y servicios de identidad que nadie se atreve a apagar. Este libro de jugadas trata el WiFi, la identidad y los servicios de red multi-inquilino como objetivos de migración por derecho propio, no como fontanería de la que ocuparse después del traslado de la aplicación.
Por qué la migración de sistemas heredados merece un plan real
Una pila de red que falla rara vez lo hace de forma aislada. Una interrupción del WiFi de un hotel puede afectar al acceso a las habitaciones, a las integraciones de gestión de la propiedad, al inicio de sesión de fidelización y a los flujos de trabajo de recuperación de huéspedes. Un minorista puede perder la conectividad entre las cajas registradoras, los servicios de pago, los sistemas de stock y el WiFi para clientes. En el sector sanitario, la cadena de dependencias puede incluir servicios de directorio, RADIUS, certificados, integraciones de llamada a enfermería, dispositivos clínicos y aplicaciones móviles. En una finca residencial, un servicio de autenticación compartido puede dar soporte a inquilinos, contratistas, personal del edificio, cámaras, ascensores y servicios comunitarios.
Por lo tanto, el caso de negocio es operativo, no estético. Cuente las incidencias, las autenticaciones fallidas, los reinicios manuales, los minutos de interrupción, las horas de ingeniería de emergencia, las licencias obsoletas y las escasas piezas de repuesto. A continuación, identifique qué impiden esos fallos. Una migración puede reducir los costes de administración, mejorar la capacidad de soporte, exponer los problemas de cobertura y autenticación de forma más clara, simplificar la incorporación y ofrecer a los equipos de seguridad una base más limpia para las revisiones de acceso.
Regla práctica: Si la empresa no puede explicar quién es el propietario de una fuente de identidad, quién aprueba un cambio de política y quién puede autorizar un rollback, no está lista para la transición.
El sector público del Reino Unido ofrece una advertencia útil sobre la postergación. Una respuesta parlamentaria del Reino Unido de 2025 sobre sistemas heredados estimó que estos representaban el 28% de los sistemas en los departamentos gubernamentales centrales en 2024, frente al 26% en 2023. La misma evidencia registró que el 60% de los servicios digitales gubernamentales se habían migrado a la nube; sin embargo, ese progreso había llevado 13 años, con un 28% del patrimonio aún heredado. La adopción mayoritaria de la nube no eliminó el núcleo duro de las dependencias antiguas.
Un reemplazo idéntico a menudo conserva las mismas debilidades detrás de logotipos más nuevos. Si la plataforma antigua depende de cuentas compartidas, cambios manuales de VLAN, enrutamiento RADIUS frágil o un único punto de gestión, moverla a un hardware nuevo solo hace que el fallo sea más difícil de reconocer. Diseñe el plan en torno a la propiedad, la evidencia de dependencias, las oleadas de migración, la confianza de identidad, la operación en paralelo y la reversión. El resultado no es una actualización de hardware. Es la retirada de un modelo operativo obsoleto sin dejar desamparados a huéspedes, personal clínico, empleados o residentes.
Evaluación de la infraestructura antes de mover una sola carga de trabajo
Comience con un inventario, no con la presentación de un proveedor. Cree un registro verificado que cubra cada controlador, punto de acceso, switch, firewall, Captive Portal, directorio, autoridad de certificación, servidor RADIUS, VLAN, SSID y consola de gestión. Registre la ubicación, el propietario, el inquilino o unidad de negocio, el modelo, el firmware, el estado de soporte, el tráfico observado, el método de autenticación, la fuente de configuración y las dependencias conocidas.
La palabra verificado importa. Una hoja de cálculo elaborada a partir de registros de compras omitirá puntos de acceso no gestionados, integraciones abandonadas, SSIDs temporales y dispositivos instalados por los equipos locales. Compare las exportaciones de configuración con el tráfico observado, los datos de monitorización, los tickets de soporte y las entrevistas con las personas que dan soporte a cada sitio.
Mapee personas, dispositivos y relaciones de confianza
Trate la identidad como su propio inventario. Separe al personal, contratistas, invitados, pacientes, estudiantes, residentes, dispositivos IoT y cuentas de servicio. Para cada grupo, documente la fuente de información, el proceso de incorporación y baja, la duración de las credenciales, la propiedad de los certificados, la ruta de aprobación y el método de acceso de emergencia.
A continuación, pruebe flujos de trabajo representativos en lugar de conectividad genérica. Un hotel necesita registro de entrada, acceso a la habitación, WiFi para huéspedes y transferencias de gestión de la propiedad. Un minorista necesita conectividad en el punto de venta, inicio de sesión de fidelidad, dispositivos portátiles y conmutación por error de la tienda. Un hospital necesita movilidad clínica, equipos conectados, autenticación del personal y resiliencia a nivel de sala. Una urbanización residencial necesita la incorporación de inquilinos, instalaciones compartidas, acceso de visitantes y aislamiento entre ocupantes.
Tome decisiones de migración basadas en evidencias
Clasifique cada activo o flujo de trabajo según su criticidad para el negocio, la sensibilidad de los datos, el riesgo de compatibilidad y la urgencia. Marque los protocolos no compatibles, la expiración de certificados, los puntos únicos de fallo, las reglas de firewall no documentadas, las cuentas de servicio codificadas de forma fija y las deficiencias en la calidad de los datos. Asigne un propietario responsable y defina las pruebas necesarias para superar cada fase.
| Activo o flujo de trabajo | Evidencias a recopilar | Clasificación de riesgo | Ola de migración |
|---|---|---|---|
| RADIUS y ruta de directorio | Registros de autenticación, mapeo de fuente de verdad, configuración de conmutación por error, propietario del servicio | Alto si se comparte entre sedes | Ola fundacional inicial |
| Captive Portal e identidad de invitados | Flujos de redirección, registros de cupones o perfiles, registros de consentimiento, dependencias de CRM y PMS | Alto en entornos de cara al cliente | Piloto por sede o inquilino |
| SSID clínicos u operacionales | Registro de dispositivos, método de autenticación, pruebas de flujo de trabajo clínico, ventana de soporte | Crítico donde la continuidad del servicio es clave | Ola controlada y específica de cada sede |
| Servicios multi-inquilino | Reglas de separación de inquilinos, configuración de iPSK o equivalente, flujos de SSO, propiedad de soporte | Alto donde el aislamiento es contractual | Olas de cohortes de inquilinos |
| Puntos de acceso y controladores | Firmware, estado de soporte, historial de conexión, copia de seguridad de configuración, ubicación física | Medio a alto según la cobertura | Alinear con olas de servicio validadas |
Un proveedor puede ayudar a descubrir activos, pero ninguna herramienta puede reparar un mapa de propiedad incompleto. El registro debe convertirse en el registro de decisiones del programa. Si un elemento no tiene propietario, evidencia de dependencia o ruta de rollback, no pertenece a una fase de puesta en marcha.
Elección del enfoque de migración adecuado
Elija el enfoque que se adapte a la limitación. La moda es un mal método de migración, especialmente cuando la red soporta la identidad y las operaciones de primera línea.
Rehost traslada un servicio existente a una infraestructura más nueva con cambios mínimos. Utilícelo para una salida urgente de hardware o hipervisor, un despliegue de RADIUS estable o una plataforma que siga comportándose de forma predecible pero que haya alcanzado un límite operativo. Es rápido, pero arrastra procesos manuales, asunciones de licencias, defectos de configuración y deuda técnica.
Replatform cambia el entorno de ejecución manteniendo el comportamiento principal del servicio. Un Captive Portal podría trasladarse a contenedores gestionados, o una integración de directorio podría pasar a una capa de servicio compatible. Esta es la ruta intermedia más sensata cuando la lógica de negocio es sólida pero la plataforma operativa es costosa o difícil de mantener.
Refactor cambia el diseño interno. Esto puede significar sustituir las reglas de red estáticas por servicios de políticas, exponer APIs o separar las decisiones de identidad de la presentación del portal. Refactorizar crea una base mejor, pero exige decisiones de producto más claras y más pruebas que una migración directa.
La migración por estrangulamiento ejecuta los servicios antiguos y nuevos de forma conjunta mientras enruta un sitio, inquilino, SSID o flujo de trabajo a la vez. Para entornos de WiFi e identidad, esta suele ser la opción por defecto más segura, ya que el equipo puede validar la coexistencia, comparar los resultados de las políticas y devolver un grupo definido al plano antiguo.
| Enfoque | Mejor encaje | Principal beneficio | Principal riesgo |
|---|---|---|---|
| Rehospedar (Rehost) | Salida urgente de infraestructura | Cambio de servicio mínimo | Conserva las debilidades de diseño |
| Migrar de plataforma (Replatform) | Integraciones estables con costes de ejecución elevados | Mejor compatibilidad sin necesidad de reescribir | Sigue habiendo trabajo de compatibilidad pendiente |
| Refactorizar (Refactor) | Rediseño de políticas, API y orquestación | Modelo operativo a largo plazo más sólido | Mayor exigencia de entrega y pruebas |
| Patrón del estrangulador (Strangler) | Identidad compartida y redes multisitio | Cohortes pequeñas y reversión rápida | La coexistencia debe diseñarse específicamente |
Un programa práctico puede re-alojar una plataforma RADIUS estable, replataformar el portal de invitados y refactorizar la aplicación de políticas. Registre el método elegido, las alternativas rechazadas, el período de coexistencia, el propietario y la condición de salida para cada carga de trabajo. Las organizaciones que evalúen servicios profesionales gestionados también pueden revisar la oferta de servicios profesionales de Purple junto con su modelo de entrega interno.
Evite una transición de tipo big-bang a menos que el entorno sea sencillo, la sincronización esté demostrada y la ventana de rollback sea tolerable. En un entorno multi-inquilino, "todo a la vez" suele significar "todas las llamadas de soporte a la vez".
Migración de datos e identidad sin romper la confianza
La identidad es la columna vertebral de la migración. Si falla, los puntos de acceso pueden estar en buen estado y los switches pueden estar reenviando tráfico, pero el servicio seguirá sin estar disponible para la persona que lo necesita.
Comience por mapear cada fuente de autenticación. Incluya servidores RADIUS, Captive Portals, integraciones de gestión de propiedades, bosques de Active Directory, conexiones de Entra ID, Google Workspace, Okta, cuentas de servicio compartidas, certificados de dispositivos y cuentas de emergencia locales. Decida qué fuentes sobrevivirán, cuáles se sincronizarán temporalmente y cuáles deben retirarse antes de que el nuevo servicio pase a ser la autoridad.
Construya la coexistencia de forma deliberada
Ejecute la sincronización de directorios por etapas. Empareje las identidades utilizando atributos estables, resuelva los duplicados antes de habilitar el acceso y defina cómo se propagan los usuarios deshabilitados o dados de baja al nuevo servicio. No utilice la migración como excusa para crear un segundo directorio de identidades sin control. Cada cuenta temporal necesita un propietario, una condición de expiración y una pista de auditoría.
Los certificados requieren la misma disciplina. Realice un inventario de las autoridades de certificación, plantillas, sistemas emisores, propiedad de la renovación, cadenas de confianza y poblaciones de dispositivos que utilicen EAP-TLS o 802.1X. Rote los certificados en una secuencia controlada, comenzando con una cohorte representativa. Mantenga la antigua ruta de confianza disponible hasta que la nueva cadena haya superado las comprobaciones de autenticación y revocación en todas las clases de dispositivos relevantes.
“Una migración de credenciales es una migración de servicios. Trate los restablecimientos de contraseñas, la renovación de certificados y la inhabilitación de cuentas como cambios que afectan al cliente.”
La identidad de los invitados requiere una línea de trabajo independiente. Preserve la relación entre los perfiles, el consentimiento, los cupones, los registros de fidelidad y los usuarios recurrentes allí donde el negocio dependa de ello. Pruebe el registro, el acceso de retorno, el olvido de credenciales, la expiración, la exclusión voluntaria y la recuperación asistida por soporte. Los invitados no deberían descubrir que la migración ha sido un éxito solo porque su acceso anterior ha desaparecido.
Secuencie el acceso, no solo el equipamiento
Mueva los servicios de identidad antes de realizar cambios amplios en SSID y VLAN. Luego, migre un SSID, sitio, inquilino o flujo de trabajo definido mientras supervisa la autenticación y el comportamiento del tráfico. En el sector sanitario, mantenga las rutas de los dispositivos conectados y clínicos separadas del acceso general del personal. En entornos residenciales, preserve el aislamiento de los inquilinos mientras cambia el servicio que lo aprovisiona. En el sector hotelero, verifique la transferencia de gestión de la propiedad antes de abrir el nuevo flujo de huéspedes a cada habitación.
Utilice la descripción general de seguridad y datos de Purple como punto de referencia al evaluar los requisitos de identidad, seguridad y gestión de datos. La elección de la herramienta importa menos que la evidencia de aceptación. Antes de que el tráfico siga el nuevo plano de identidad, demuestre el éxito de la autenticación, la autorización correcta, la confianza en los certificados, la desactivación del directorio, la finalización del portal, la asignación de VLAN y la recuperación tras la interrupción del servicio.
Pruebas, transición y rollback que realmente funcionan
Diseñe el plan de transición a la inversa, empezando por la reversión. La mayoría de los planes deficientes describen cómo se habilitará el nuevo servicio y luego añaden una instrucción vaga de "revertir si es necesario". Eso no es un plan de reversión. Una reversión real define el desencadenante, la persona que toma las decisiones, la acción técnica, el responsable de comunicación y el límite de tiempo.
Utilice una ejecución en paralelo como instrumento de prueba
Ejecute los planos de red y de identidad heredados y nuevos de forma conjunta durante un período definido. Utilice solicitudes RADIUS espejo donde la arquitectura lo permita, flujos de Captive Portal duplicados, comparación de configuraciones y pruebas sintéticas de inicio de sesión de invitados. Pruebe autenticaciones correctas y fallidas, certificados caducados, cuentas deshabilitadas, itinerancia, asignación de VLAN, dependencia de DNS, comportamiento del cortafuegos y la pérdida de un directorio o de un endpoint RADIUS.
Realice pruebas por grupos de negocio. El ala de un hotel, un establecimiento comercial, un grupo de dispositivos aprobado para una planta hospitalaria o un edificio residencial resultan más útiles que una prueba de laboratorio que excluya integraciones reales. Mantenga un conjunto de pruebas que contenga marcas de tiempo, identidades de prueba, tipos de dispositivos, resultados de políticas, fallos y aprobaciones.
Escriba el plan de ejecución minuto a minuto
La secuencia de transición debe incluir:
- Congelar cambios: Detener cambios no relacionados en la red, directorios, certificados y portales.
- Capturar el estado: Exportar configuraciones, registrar versiones de políticas, conservar asignaciones de identidad y confirmar que los archivos de restauración son utilizables.
- Migrar la cohorte: Cambiar el sitio, inquilino, SSID o flujo de trabajo definido, no un "entorno" ambiguo.
- Observar el comportamiento: Supervisar la autenticación, los redireccionamientos, las conexiones de puntos de acceso, los contactos de soporte, las transacciones de aplicaciones y el aislamiento de inquilinos.
- Expandir o revertir: Continuar únicamente después de que el propietario designado confirme los criterios de salida. Si se activa una alerta, ejecutar la reversión ensayada.
Las notas del plan identifican ejemplos como una tasa de fallos de autenticación superior al 1,5%, bucles de redirección de Captive Portal y fallos de conexión de puntos de acceso por encima de un umbral acordado. Utilice esos ejemplos solo si su línea de base los respalda, y establezca el activador final con los propietarios del servicio antes de la ventana de cambio. El objetivo no es elegir un número universal. El objetivo es eliminar las discusiones en la sala de incidentes.
Ensaye el rollback con las mismas personas que gestionarán la producción. Una alternativa que solo existe en un documento fallará cuando los certificados, las cachés, las rutas y las decisiones humanas interactúen bajo presión.
Realidad sobre costes, plazos y cumplimiento normativo
La estimación de entrega optimista de un proveedor no es un presupuesto listo para el consejo de administración. Elabore el modelo en torno al descubrimiento, la remediación, las integraciones, las pruebas, el tiempo del personal interno, la cobertura de soporte, las licencias, las comunicaciones, la formación, la exposición al tiempo de inactividad y la contingencia. Incluya la capa de red como trabajo de entrega: diseño de WiFi, servicios de identidad, Captive Portals, certificados, enrutamiento, aislamiento de inquilinos y soporte de transición sitio por sitio. Una migración no es barata si la antigua plataforma permanece operativa indefinidamente.
El sector público del Reino Unido ofrece una advertencia clara sobre el trabajo aplazado. El State of Digital Government Review registró tecnología heredada en el 28% de los sistemas del gobierno central en 2024. También detectó niveles de obsolescencia que oscilaban entre el 10% y el 60-70% en las fuerzas policiales y los consorcios del NHS, hizo referencia a servicios críticos creados sobre sistemas que se remontan a la década de 1970 y citó problemas de sistemas heredados en 153 sistemas de 16 departamentos. Estas cifras no son una lista de precios del sector privado. Demuestran por qué la detección de dependencias y su remediación deben formar parte del presupuesto de ejecución, no de una partida de costes indirectos que se acaba recortando.
Un análisis del sector público del Reino Unido sobre los costes de la TI heredada informó que la TI heredada cuesta entre un 4 y un 7 % del gasto anual del sector público en pérdida de productividad. Utilice esa cifra como referencia para medir el desperdicio operativo en su organización, incluyendo la gestión manual de identidades, las llamadas de soporte recurrentes, los fallos de acceso de invitados y las soluciones alternativas de servicio de red. No la presente como un ahorro garantizado por la migración.
| Sector | Rango de costes indicativo | Duración típica | Factores clave de cumplimiento |
|---|---|---|---|
| Hostelería | Alcance según número de sedes, identidad de invitados, integración de PMS, diseño de WiFi y cobertura de soporte | Secuencia según ocupación y eventos | Seguridad de pagos, privacidad, registros de acceso, garantía de proveedores |
| Retail | Alcance según variación de tiendas, dependencias de POS, identidad de fidelización, WiFi y ventanas comerciales | Piloto fuera de horas punta, luego despliegue por cohortes | PCI-DSS, privacidad, controles de endpoints, audibilidad |
| Sanitario | Alcance según flujos de trabajo clínicos, validación de dispositivos, resiliencia inalámbrica y gobernanza de cambios | Ventanas de planificación y validación más amplias | Seguridad del paciente, privacidad, garantía de dispositivos médicos, continuidad |
| Residencias y alojamientos de estudiantes | Alcance según aislamiento de inquilinos, incorporación, instalaciones compartidas y sistemas de edificios | Olas por edificio o cartera | Privacidad, aislamiento contractual, gobernanza de accesos, controles de proveedores |
Para las redes de invitados, evalúe el consentimiento, la retención, los registros de acceso, el manejo de identidades y la separación de inquilinos antes de comprometerse con un diseño. Utilice la herramienta de verificación de cumplimiento de WiFi de invitados de Purple para revisar ese estado e identificar las brechas que requieren financiación.
La ONS ofrece otra lección dura. Los informes sobre la migración de sistemas heredados de la ONS señalaron que las limitaciones presupuestarias ralentizaron su transición fuera de los sistemas heredados, a pesar de los avances hacia la sustitución del 80% de los servicios heredados. La misma fuente informó que el 90% de las organizaciones tenían deuda técnica de Microsoft Windows, el 60% tenían muchos servidores o escritorios de Windows sin soporte, y el 51% informó de tiempos de inactividad vinculados a la deuda técnica. La presión del fin de la vida útil no elimina la necesidad de planificar la continuidad.
Mapee el programa con respecto a PCI DSS 4.0, ISO 27001, Cyber Essentials Plus, NIS2 cuando corresponda, y las obligaciones específicas del sector. El cumplimiento expondrá asunciones débiles, así que valore los controles, la evidencia, las pruebas y la propiedad operativa antes de la ventana de cambio.
Supervisión post-migración y desmantelamiento continuo
La puesta en marcha es el comienzo de la rendición de cuentas. Una vez que el nuevo servicio gestiona el tráfico de producción, el equipo necesita una línea base que demuestre si la migración mejoró las operaciones o si trasladó los mismos fallos a una consola diferente.
Supervise la latencia de autenticación RADIUS, la tasa de fallos del Captive Portal, el éxito de asociación de los puntos de acceso, el plazo de renovación de certificados, las discrepancias de políticas, los contactos de soporte y los objetivos de servicio a nivel de inquilino donde el aislamiento multi-inquilino sea importante. Asigne a cada señal un propietario designado, una ruta de escalado y una frecuencia de revisión. Un panel de control sin un operador responsable es solo decoración.
Ejecutar una curva de estabilidad
Utilice un ritmo de revisión de 30, 60 y 90 días. La primera revisión debe detectar desviaciones de configuración, alertas ausentes, fallos de autenticación recurrentes y soluciones temporales de soporte. La segunda debe comprobar si el servicio funciona sin la intervención del equipo de migración. La tercera debe decidir si la plataforma heredada está lista para su retirada.
No declare victoria solo porque la nueva plataforma haya estado activa durante un fin de semana tranquilo. Compare el comportamiento a lo largo de los ciclos de negocio, grupos de inquilinos, clases de dispositivos y eventos operativos. El sector de la hostelería necesita variaciones de ocupación, el comercio minorista necesita condiciones comerciales, el sector sanitario necesita flujos de trabajo clínicos aprobados y las urbanizaciones residenciales necesitan la incorporación de inquilinos y el acceso comunitario.
Retirada de servicio en fases controladas
Retire el servicio heredado solo después de que se cumplan los criterios de salida y el propietario del negocio dé su aprobación. Luego, elimínelo metódicamente:
- Cierre administrativo: Detener cambios, cerrar vías de soporte, archivar configuraciones aprobadas y actualizar los registros de propiedad.
- Revocación de confianza: Revocar certificados obsoletos, desactivar cuentas de servicio antiguas, eliminar la sincronización de directorios no utilizada y suprimir rutas de acceso residuales.
- Retirada de la red: Eliminar túneles VPN heredados, políticas, integraciones y dependencias de gestión, para luego recuperar el espacio de direcciones y las licencias.
- Traspaso de conocimientos: Almacenar la arquitectura final, el registro de decisiones, las pruebas de testeo, el historial de incidencias y los procedimientos operativos donde el equipo de soporte pueda encontrarlos.
Un análisis del gobierno del Reino Unido sobre la complejidad de los sistemas heredados describió los sistemas heredados como obsoletos, vulnerables, insoportables y una limitación para la transformación. Dicha fuente ya ha establecido la magnitud del problema. Su trabajo después de la migración es garantizar que el entorno antiguo no permanezca como un límite de seguridad sin propietario.
Purple ofrece autenticación WiFi basada en la nube y redes basadas en la identidad para invitados, personal y entornos multi-inquilino, con integraciones para servicios de directorio y plataformas de red. Visite Purple para evaluar si sus capacidades de identidad, acceso de invitados, analítica y migración se adaptan a su plan de migración de sistemas heredados.
