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 pagos, una sala de hospital informa de una movilidad clínica poco confiable, o los residentes de un edificio gestionado hacen fila fuera de una oficina de soporte porque el portal de inquilinos 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 vencido y servicios de identidad que nadie quiere apagar. Este libro de jugadas trata al WiFi, la identidad y los servicios de red multiinquilino como objetivos de migración por derecho propio, no como tuberías de las que ocuparse después de mover 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 el acceso a las habitaciones, las integraciones de gestión de propiedades, el inicio de sesión de fidelidad y 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 inventario y el WiFi para clientes. En el sector salud, la cadena de dependencias puede incluir servicios de directorio, RADIUS, certificados, integraciones de llamadas a enfermeras, dispositivos clínicos y aplicaciones móviles. En un complejo residencial, un servicio de autenticación compartido puede dar soporte a inquilinos, contratistas, personal del edificio, cámaras, ascensores y áreas comunes.
Por lo tanto, el caso de negocio es operativo, no estético. Cuente los incidentes, las autenticaciones fallidas, los reinicios manuales, los minutos de interrupción, las horas de ingeniería de emergencia, las licencias obsoletas y las piezas de repuesto escasas. Luego identifique qué impiden esas fallas. Una migración puede reducir los gastos administrativos indirectos, mejorar la capacidad de soporte, exponer los problemas de cobertura y autenticación con mayor claridad, simplificar la incorporación y brindar 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 una reversión, entonces 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 del gobierno central en 2024, frente al 26% en 2023. La misma evidencia registró que el 60% de los servicios digitales del gobierno se habían migrado a la nube, pero ese progreso había tomado 13 años, con un 28% del patrimonio que aún era 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 conexión de gestión, moverla a un hardware nuevo solo hace que la falla 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 paralela y el retorno al estado anterior. El resultado no es una actualización de hardware. Es el retiro de un modelo operativo obsoleto sin dejar desamparados a huéspedes, médicos, 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 administración. Registre la ubicación, el propietario, el inquilino o unidad de negocio, el modelo, el firmware, el estado del 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 recopilada a partir de registros de compras omitirá puntos de acceso no administrados, integraciones abandonadas, SSIDs temporales y dispositivos instalados por equipos locales. Compare las exportaciones de configuración con el tráfico observado, los datos de monitoreo, los tickets de servicio y las entrevistas con las personas que brindan soporte en 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 verdad, el proceso de alta y baja, la vida útil de las credenciales, la propiedad del certificado, la ruta de aprobación y el método de acceso de emergencia.
Luego 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 e integraciones con la administración de la propiedad. Un minorista necesita conectividad en el punto de venta, inicio de sesión de lealtad, dispositivos portátiles y failover en la tienda. Un hospital necesita movilidad clínica, equipos conectados, autenticación del personal y resiliencia a nivel de sala. Un complejo residencial necesita incorporación de inquilinos, instalaciones compartidas, acceso de visitantes y aislamiento entre ocupantes.
Tome decisiones de migración basadas en evidencia
Clasifique cada activo o flujo de trabajo por criticidad empresarial, sensibilidad de datos, riesgo de compatibilidad y urgencia. Marque protocolos no compatibles, vencimiento de certificados, puntos únicos de falla, reglas de firewall no documentadas, cuentas de servicio codificadas directamente y brechas en la calidad de los datos. Asigne un propietario responsable y defina la evidencia requerida para superar cada etapa.
| Activo o flujo de trabajo | Evidencia a recopilar | Clasificación de riesgo | Oleada de migración |
|---|---|---|---|
| Ruta de directorio y RADIUS | Registros de autenticación, mapeo de fuente de verdad, configuración de failover, propietario del servicio | Alto si se comparte entre sitios | Oleada de base inicial |
| Captive Portal e identidad de invitados | Flujos de redireccionamiento, registros de cupones o perfiles, registros de consentimiento, dependencias de CRM y PMS | Alto en entornos orientados a invitados | Piloto por sitio o inquilino |
| SSID clínicos u operativos | 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 importa | Oleada controlada y específica del sitio |
| 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 | Oleadas de cohortes de inquilinos |
| Puntos de acceso y controladores | Firmware, estado de soporte, historial de unión, respaldo de configuración, ubicación física | Medio a alto según la cobertura | Alineado con oleadas de servicios validados |
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 reversión, no pertenece a una fase de lanzamiento de producción.
Cómo elegir el enfoque de migración adecuado
Elija el enfoque que se adapte a sus limitaciones. Las tendencias tecnológicas son 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, una implementación estable de RADIUS o una plataforma que aún se comporta de manera predecible pero ha alcanzado un límite operativo. Es rápido, pero arrastra procesos manuales, suposiciones de licencias, defectos de configuración y deuda técnica.
Replatform cambia el entorno de ejecución preservando el comportamiento principal del servicio. Un Captive Portal podría moverse a contenedores administrados, o una integración de directorio podría moverse a una capa de servicio compatible. Este es el camino intermedio más sensato 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 reemplazar reglas de red estáticas con servicios de políticas, exponer APIs o separar las decisiones de identidad de la presentación del portal. Refactorizar crea una mejor base, pero exige decisiones de producto más claras y más pruebas que una migración directa (lift and shift).
Migración por estrangulamiento (Strangler) ejecuta los servicios antiguos y nuevos en paralelo 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 predeterminada más segura porque el equipo puede validar la coexistencia, comparar los resultados de las políticas y devolver un grupo definido a la plataforma anterior.
| Enfoque | Mejor ajuste | Principal beneficio | Principal riesgo |
|---|---|---|---|
| Rehospedar (Rehost) | Salida urgente de infraestructura | Cambio de servicio mínimo | Preserva las debilidades de diseño |
| Replataformar (Replatform) | Integraciones estables con un tiempo de ejecución costoso | Mejor capacidad de soporte sin una reescritura | El trabajo de compatibilidad permanece |
| Refactorizar (Refactor) | Rediseño de políticas, API y orquestación | Modelo operativo a largo plazo más sólido | Mayor demanda de entrega y pruebas |
| Patrón de estrangulamiento (Strangler) | Identidad compartida y redes multi-sitio | Cohortes pequeñas y reversión rápida | La coexistencia debe ser diseñada |
Un programa práctico puede rehostear 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 periodo de coexistencia, el propietario y la condición de salida para cada carga de trabajo. Las organizaciones que evalúan servicios profesionales gestionados también pueden revisar la oferta de servicios profesionales de Purple junto con su modelo de entrega interna.
Evite una transición del tipo "big-bang" a menos que el entorno sea simple, la sincronización esté probada y la ventana de reversión sea tolerable. En una infraestructura multi-tenant, "todo a la vez" generalmente significa "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 el usuario 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 Microsoft 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 manera deliberada
Ejecute la sincronización de directorios por etapas. Coincida las identidades utilizando atributos estables, resuelva los duplicados antes de habilitar el acceso y defina cómo se propagan los usuarios deshabilitados o desvinculados al nuevo servicio. No utilice la migración como excusa para crear un segundo directorio de identidades no controlado. Cada cuenta temporal necesita un propietario, una condición de vencimiento 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 renovación, cadenas de confianza y poblaciones de dispositivos que utilizan EAP-TLS o 802.1X. Rote los certificados en una secuencia controlada, comenzando con una cohorte representativa. Mantenga disponible la ruta de confianza anterior hasta que la nueva cadena haya superado las comprobaciones de autenticación y revocación en cada clase de dispositivo relevante.
“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 directamente al cliente.”
La identidad de los invitados requiere un flujo de trabajo independiente. Preserve la relación entre perfiles, consentimiento, códigos de acceso, registros de lealtad y usuarios recurrentes cuando el negocio dependa de ello. Pruebe el registro, el acceso de retorno, los datos olvidados, el vencimiento, la exclusión voluntaria y la recuperación asistida por soporte. Los invitados no deberían descubrir que la migración fue exitosa solo porque su acceso anterior desapareció.
Secuencie el acceso, no solo el equipamiento
Mueva los servicios de identidad antes de realizar cambios amplios de SSID y VLAN. Luego migre un SSID, sitio, inquilino o flujo de trabajo definido mientras monitorea el comportamiento de autenticación y tráfico. En el sector salud, mantenga las rutas de dispositivos clínicos y conectados 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 integración con la administración de la propiedad antes de abrir el nuevo flujo de huéspedes a cada habitación.
Utilice la descripción general de datos y seguridad de Purple como punto de referencia al evaluar los requisitos de identidad, seguridad y manejo 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 que la autenticación es exitosa, la autorización es correcta, la confianza en los certificados, la inhabilitación del directorio, la finalización del portal, la asignación de VLAN y la recuperación después de una interrupción del servicio.
Pruebas, transición y rollback que realmente funcionan
Diseñe el plan de transición a la inversa, comenzando por el plan de retorno. La mayoría de los planes deficientes describen cómo se habilitará el nuevo servicio y luego agregan una instrucción vaga de "revertir si es necesario". Eso no es un plan de retorno. Un plan de retorno real define el detonante, el tomador de decisiones, la acción técnica, el responsable de la comunicación y el límite de tiempo.
Utilice una ejecución paralela como instrumento de prueba
Ejecute los planos de red y de identidad heredados y nuevos de forma conjunta durante un periodo definido. Utilice solicitudes shadow de RADIUS donde la arquitectura lo permita, recorridos de Captive Portal duplicados, comparación de configuraciones y pruebas sintéticas de inicio de sesión de invitados. Pruebe la autenticación exitosa y fallida, certificados caducados, cuentas deshabilitadas, roaming, asignación de VLAN, dependencia de DNS, comportamiento del firewall y la pérdida de un directorio o de un punto de conexión RADIUS.
Realice pruebas por grupos de negocio. Un ala de hotel, una tienda minorista, un grupo de dispositivos aprobado por el departamento o un edificio residencial es más útil que una prueba de laboratorio que excluye las integraciones reales. Conserve un paquete de evidencias que contenga marcas de tiempo, identidades de prueba, tipos de dispositivos, resultados de políticas, defectos y aprobaciones.
Escriba el plan de ejecución minuto a minuto
La secuencia de transición debe incluir:
- Congelar cambios: Detenga los cambios no relacionados en la red, el directorio, los certificados y los portales.
- Capturar el estado actual: Exporte configuraciones, registre versiones de políticas, preserve asignaciones de identidad y confirme que los archivos de restauración sean utilizables.
- Migrar la cohorte: Cambie el sitio, tenant, SSID o flujo de trabajo definido, no un "entorno" ambiguo.
- Observar el comportamiento: Supervise la autenticación, los redireccionamientos, las conexiones de puntos de acceso, los contactos de soporte, las transacciones de aplicaciones y el aislamiento de tenants.
- Expandir o revertir: Continúe únicamente después de que el propietario designado confirme los criterios de salida. Si se activa una alerta, ejecute la reversión ensayada.
Las notas del plan identifican ejemplos como una tasa de falla de autenticación superior al 1.5%, bucles de redirección de Captive Portal y fallas de unión de puntos de acceso por encima de un umbral acordado. Utilice esos ejemplos solo si su línea base los admite, y defina 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 discusiones en la sala de incidentes.
Ensaye la reversión con las mismas personas que operarán en producción. Un plan de respaldo que solo existe en un documento fallará cuando los certificados, las memorias caché, las rutas y las decisiones humanas interactúen bajo presión.
Control de realidad sobre costos, plazos y cumplimiento
La estimación de entrega optimista de un proveedor no es un presupuesto listo para presentarse ante la junta directiva. Construya 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 capacitació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, portales cautivos, certificados, enrutamiento, aislamiento de inquilinos y soporte de transición sitio por sitio. Una migración no es barata si la plataforma antigua sigue 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 encontró niveles de tecnología heredada que van del 10% al 60-70% en las fuerzas policiales y los fideicomisos del NHS, hizo referencia a servicios críticos creados sobre sistemas que datan de la década de 1970 y citó problemas de tecnología heredada en 153 sistemas en 16 departamentos. Estas cifras no son una lista de precios del sector privado. Muestran por qué el descubrimiento y la remediación de dependencias pertenecen al presupuesto de entrega y no a una línea de gastos generales que se termina recortando.
Un análisis del sector público del Reino Unido sobre los costos de TI heredados informó que la TI heredada cuesta entre el 4% y el 7% del gasto anual del sector público en pérdida de productividad. Utilice esa cifra como un recordatorio para medir el desperdicio operativo en su organización, incluido el trabajo de identidad manual, las llamadas de soporte repetidas, el acceso fallido de invitados y las soluciones alternativas del servicio de red. No lo presente como un ahorro de migración garantizado.
| Sector | Rango de costo indicativo | Duración típica | Factores clave de cumplimiento |
|---|---|---|---|
| Hospitalidad | Alcance según el número de sitios, identidad de invitados, integración de PMS, diseño de WiFi y cobertura de soporte | Secuencia en torno a la ocupación y eventos | Seguridad de pagos, privacidad, registros de acceso, garantía de proveedores |
| Retail | Alcance según la variación de tiendas, dependencias de POS, identidad de fidelidad, WiFi y ventanas comerciales | Piloto fuera de las horas pico de comercio, luego despliegue por cohortes | PCI-DSS, privacidad, controles de endpoints, auditabilidad |
| Salud | Alcance según flujos de trabajo clínicos, validación de dispositivos, resiliencia inalámbrica y gobernanza del cambio | Ventanas de planificación y validación más largas | Seguridad del paciente, privacidad, garantía de dispositivos médicos, continuidad |
| Residencial y estudiantil | Alcance según el aislamiento de inquilinos, incorporación, instalaciones compartidas y sistemas del edificio | Oleadas por edificio o cartera | Privacidad, aislamiento contractual, gobernanza de acceso, controles de proveedores |
Para 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 para invitados de Purple para revisar ese estado e identificar las brechas que requieren financiamiento.
La ONS ofrece otra lección difícil. Los informes sobre la migración de sistemas heredados de la ONS señalaron que las limitaciones presupuestarias ralentizaron su transición para abandonar los sistemas heredados, a pesar del progreso hacia el reemplazo del 80% de los servicios heredados. La misma fuente informó que el 90% de las organizaciones tenían deuda técnica de Windows, el 60% tenían muchos servidores o escritorios de Windows sin soporte y el 51% reportaron tiempo de inactividad vinculado a la deuda técnica. La presión por el fin de la vida útil no elimina la necesidad de planificar la continuidad.
Mapee el programa frente a PCI-DSS, ISO 27001, Cyber Essentials, NIS2 donde aplique, y las obligaciones específicas del sector. El cumplimiento expondrá suposiciones débiles, así que cotice los controles, la evidencia, las pruebas y la propiedad operativa antes de la ventana de cambio.
Monitoreo post-migración y desmantelamiento continuo
El lanzamiento de producción es el comienzo de la responsabilidad. Una vez que el nuevo servicio gestiona tráfico de producción, el equipo necesita una línea base que demuestre si la migración mejoró las operaciones o si simplemente trasladó las mismas fallas a una consola diferente.
Monitoree la latencia de autenticación RADIUS, la tasa de fallas del Captive Portal, el éxito de la conexión de los puntos de acceso, el tiempo de entrega de la renovación de certificados, las discrepancias de políticas, los contactos de soporte y los objetivos de servicio a nivel de inquilino cuando el aislamiento multi-inquilino sea importante. Asigne a cada señal un propietario designado, una ruta de escalación 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 faltantes, fallas de autenticación recurrentes y soluciones temporales de soporte. La segunda debe probar si el servicio está funcionando sin la intervención del equipo de migración. La tercera debe decidir si la plataforma heredada está lista para ser retirada.
No declare victoria porque la nueva plataforma ha estado activa durante un fin de semana tranquilo. Compare el comportamiento a lo largo de los ciclos comerciales, grupos de inquilinos, clases de dispositivos y eventos operativos. El sector de la hospitalidad necesita variaciones de ocupación, el comercio minorista requiere condiciones comerciales, el sector salud necesita flujos de trabajo clínicos aprobados y los desarrollos residenciales necesitan la incorporación de inquilinos y el acceso comunitario.
Desmantelamiento en etapas controladas
Retire el servicio heredado únicamente después de que se cumplan los criterios de salida y el propietario del negocio dé su aprobación. Luego, elimínelo de forma metódica:
- Cierre administrativo: Detenga los cambios, cierre los canales de soporte, archive las configuraciones aprobadas y actualice los registros de propiedad.
- Revocación de confianza: Revoque certificados obsoletos, deshabilite cuentas de servicio antiguas, elimine la sincronización de directorios no utilizada y elimine las rutas de acceso residuales.
- Retiro de red: Elimine túneles VPN heredados, políticas, integraciones y dependencias de administración, luego recupere el espacio de direcciones y las licencias.
- Traspaso de conocimientos: Almacene la arquitectura final, el registro de decisiones, las pruebas de ensayo, el historial de incidentes y los procedimientos operativos donde el equipo de soporte pueda encontrarlos.
Un análisis del gobierno del Reino Unido sobre la complejidad del patrimonio heredado describió los sistemas heredados como obsoletos, vulnerables, insostenibles y una limitación para la transformación. Esa fuente ya ha establecido la magnitud del problema. Su trabajo después de la migración es garantizar que el antiguo patrimonio no permanezca como un límite de seguridad sin propietario.
Purple ofrece autenticación de 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, análisis y migración se adaptan a su plan de migración de sistemas heredados.
