Cambio de proveedor de WiFi para invitados: lista de comprobación de migración para recintos multisede

Cambiar de proveedor de WiFi para invitados en recintos con múltiples ubicaciones requiere exportar los datos de los invitados, configurar RADIUS en la nube según RFC 2865 y RFC 2866, y realizar una prueba piloto de 14 días antes del despliegue por fases. El hardware existente de proveedores como Cisco Meraki o HPE Aruba se integra sin necesidad de sustituir equipos, mientras que mantener informes paralelos durante un periodo de solapamiento de 30 días garantiza la continuidad del servicio.

¿Qué implica realmente cambiar de proveedor de WiFi para invitados?

Un cambio de proveedor de WiFi para invitados traslada tres elementos: los datos de sus invitados, la configuración de su red y sus informes. Sus puntos de acceso permanecen donde están. Con una solución superpuesta en la nube como Guest WiFi de Purple, el nuevo proveedor se integra sobre el hardware que ya posee. Dicho hardware incluye Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Los motivos se explican en Por qué su próxima actualización de WiFi no necesita hardware nuevo.

Tres términos concentran la mayor parte del trabajo en una migración de WiFi para invitados:

• Portal cautivo: la página de inicio de sesión que ve un visitante antes de conectarse a internet.
• Walled garden: la lista de dominios a los que un dispositivo puede acceder antes de iniciar sesión, para que puedan cargarse el portal y las páginas de inicio de sesión social.
• RADIUS: el protocolo definido en RFC 2865 que utilizan los puntos de acceso para consultar a un servidor si admiten un dispositivo. Su extensión de contabilidad, RFC 2866, comunica al servidor el inicio, la finalización y la duración de la sesión.

Los dos fallos críticos son quedarse a oscuras y perder la base de datos. Quedarse a oscuras significa que los invitados de una ubicación no pueden conectarse a internet por haber omitido un ajuste de configuración. Perder la base de datos es quedarse sin poder enviar correos a su lista de marketing porque las pruebas de consentimiento permanecieron con el antiguo proveedor. El orden de trabajo que se detalla a continuación existe para evitar ambos problemas.

¿Qué necesita antes de cambiar de proveedor de WiFi para invitados?

Las fechas de su contrato y las cláusulas sobre datos

Empiece por el contrato anterior, no por la red. Localice tres fechas: el plazo de preaviso, la fecha de fin de servicio y cualquier plazo límite para la devolución de datos. Conforme al artículo 28(3)(g) del GDPR, el encargado del tratamiento debe suprimir o devolver los datos personales al término de la prestación del servicio, a elección de usted como responsable del tratamiento. Escriba al antiguo proveedor y elija «devolución», por escrito, antes de notificar la rescisión.

Planifique un solapamiento de al menos 30 días entre la puesta en marcha del nuevo servicio y la finalización del anterior. Necesitará ese margen para la ejecución de informes en paralelo que se describe más adelante. Si el plazo de preaviso es de 90 días, calcule hacia atrás: exportación en los primeros 15 días, piloto hacia el día 45, fase final hacia el día 75.

Un inventario de cada ubicación

No es posible programar una transición que no se puede ver. Elabore una hoja de cálculo con una fila por cada ubicación y las siguientes columnas:

• Proveedor del punto de acceso y controlador o panel de gestión (por ejemplo, panel de Cisco Meraki, HPE Aruba Central, Ruckus SmartZone).
• Nombres de SSID para invitados y cualquier VLAN (LAN virtual, un segmento de red independiente) en el que se aloje el tráfico de invitados.
• Quién es el propietario del cortafuegos y de la línea de banda ancha en esa ubicación.
• Un contacto local identificado que pueda confirmar que el portal se carga en un teléfono móvil.
• Picos de actividad comercial y fechas de restricción.

Una exportación limpia del proveedor anterior

Solicite la exportación por escrito y especifique el formato. Una solicitud imprecisa genera un archivo impreciso. En esta tabla se detalla qué debe solicitar.

Campo	Por qué lo necesita	Formato que debe solicitar
Dirección de correo electrónico	Clave principal para marketing y deduplicación	CSV UTF-8, un registro por fila
Número de teléfono móvil	Marketing por SMS y cotejo de datos	Formato internacional ITU-T E.164
Indicador de consentimiento por canal	El consentimiento para correo electrónico y SMS es independiente en virtud de la normativa PECR	Una columna de verdadero/falso por canal
Marca de tiempo del consentimiento	Demuestra cuándo se otorgó el consentimiento (artículo 7(1) del GDPR)	ISO 8601 con desfase UTC
Texto o versión del consentimiento	Demuestra qué se le comunicó al visitante	Identificador de versión vinculado al texto archivado del portal
Ubicación de Capture	Vincula el consentimiento a la sede que lo recopiló	Identificador de ubicación que coincida con su inventario
Revocaciones y cancelaciones de suscripción	Evita enviar correos electrónicos a personas que hayan optado por no recibirlos	Archivo de exclusión independiente con fechas
Historial de visitas	Base de referencia para la conciliación de informes	Totales mensuales por ubicación, últimos 13 meses

Compruebe el recuento de filas al recibir el archivo. Si el panel de control anterior muestra 200 000 perfiles y el archivo contiene 160 000, pregunte el motivo antes de dar su conformidad a nada.

Pruebas de consentimiento válidas tras la migración

El artículo 7(1) del GDPR establece que, cuando el tratamiento se base en el consentimiento, el responsable del tratamiento debe ser capaz de demostrarlo. La guía sobre consentimiento de la ICO indica qué debe incluir ese registro: quién prestó el consentimiento, cuándo, cómo, qué se le comunicó y si lo ha revocado. Una hoja de cálculo con direcciones de correo electrónico y una columna «marketing = sí» no cumple ninguno de estos requisitos.

Tres pasos para trasladar el consentimiento de forma intacta:

1. Archive el texto del portal anterior. Haga capturas de pantalla fechadas de cada versión de la página de inicio de sesión y del aviso de privacidad, y vincule cada una con el campo de versión del consentimiento.
2. Compruebe a nombre de quién está el consentimiento. El considerando 42 del GDPR señala que el interesado debe conocer al menos la identidad del responsable del tratamiento. El consentimiento otorgado a la marca de su sede se mantiene. El consentimiento otorgado para las acciones de marketing del proveedor anterior, no.
3. Importe primero la lista de exclusión. Cualquier persona que haya cancelado su suscripción debe permanecer dada de baja en el nuevo sistema desde el primer día.

Los registros que no incluyan marca de tiempo o versión del texto no son aptos para comunicaciones de marketing. Impórtelos como contactos sin consentimiento de marketing en lugar de eliminarlos, de modo que el historial de visitas se mantenga intacto.

¿Cómo llevar a cabo la migración de WiFi para invitados ubicación por ubicación?

Paso 1: importe la lista antes de intervenir en un punto de acceso

Importe primero a Purple Engage. Purple Engage admite registros de invitados que han dado su consentimiento junto con su historial de consentimientos, de modo que cada perfil conserva su marca de tiempo, canal y versión del texto legal. Hacer esto antes de cualquier migración garantiza que no se envíe ninguna comunicación de marketing sin haber cargado la lista de exclusión. También permite que los visitantes que regresen se encuentren con una base de datos que ya contiene su registro.

Purple Engage se integra con plataformas de CRM y marketing. Si su plataforma de correo electrónico es el sistema de referencia para las bajas, conéctela antes de la primera campaña, no después.

Paso 2: configure el portal cautivo, el walled garden y los ajustes de RADIUS

Purple Access gestiona el portal cautivo y RADIUS en la nube en los puntos de acceso que ya posee. Cree una plantilla de portal por marca y, a continuación, clónela por ubicación para que el ID de la sede sea correcto desde el principio. Redacte el nuevo texto de consentimiento con opciones de inclusión explícitas, una por canal, y registre su versión antes del lanzamiento.

En cuanto a los puntos de acceso, consulte el artículo de soporte de Purple correspondiente a su proveedor específico en lugar de copiar los valores del proveedor anterior. Las direcciones de servidor, los secretos compartidos y los dominios de walled garden varían de un proveedor a otro. Un ajuste arrastrado de la configuración anterior es la causa más común de una migración fallida.

Paso 3: migre una sede piloto

Elija una sede piloto que sea representativa, no sencilla. Debe contar con el hardware más habitual, registrar una afluencia normal de visitantes y estar al alcance de su equipo de TI. Realice la migración durante las horas de menor actividad comercial, guardando la configuración antigua de SSID para poder revertir los cambios en cuestión de minutos.

Realice pruebas en al menos cuatro dispositivos: un iPhone actual, un teléfono Android actual, un portátil Windows y un portátil macOS. Pruebe todos los métodos de inicio de sesión que ofrezca. A continuación, mantenga el piloto en funcionamiento durante 14 días antes de la fase 1, ya que algunos fallos solo se manifiestan bajo una carga real.

Paso 4: migre por fases

Agrupe las sedes de modo que cada fase reutilice una configuración que ya haya validado. Esta matriz de decisión establece el orden.

Perfil de la sede	Fase	Motivo
Sede representativa, hardware habitual, cercana al equipo de TI	Piloto	Detecta fallos de configuración en una sola sede, no en 30
Mismo controlador o panel de gestión que el piloto	Fase 1	Plantilla validada, menor riesgo
Proveedor de hardware diferente	Piloto propio, luego la siguiente fase	El walled garden y la sintaxis de RADIUS varían según el proveedor
Sedes estacionales o de baja actividad comercial	Fase 1 o 2	Menos visitantes afectados si se cuela algún fallo
Sedes insignia o de mayores ingresos	Fase final	Recibe la configuración más contrastada
Sedes con eventos o fechas punta dentro del plan	Fuera de un margen de 7 días a cada lado del pico	Evita romper el bloqueo de cambios en su momento de mayor actividad

Limite cada fase a un número de sedes que su equipo pueda verificar en un solo turno. Un contacto local debe confirmar que el portal se carga correctamente en cada sede antes de dar por cerrada la fase.

Caso práctico: un grupo de 30 hoteles

Las cifras que figuran a continuación corresponden a un ejemplo práctico, no a una implantación con nombres reales. Un grupo de 30 hoteles gestiona WiFi para invitados con Cisco Meraki en 22 establecimientos y con HPE Aruba en ocho. Su contrato contempla un plazo de preaviso de 90 días. Puede obtener más información sobre el sector en nuestra página de Hoteles.

Qué se hizo. El grupo optó por la «devolución» en virtud del artículo 28 y notificó la rescisión el primer día. La exportación llegó en la segunda semana con 210.000 registros. De ellos, 31.000 carecían de marca de tiempo de consentimiento y se importaron en Purple Engage como no aptos para marketing. El piloto se ejecutó durante 14 días en un hotel Meraki de 120 habitaciones. Los demás hoteles Meraki migraron en dos fases de 10 y 11 establecimientos mediante plantillas de panel de control. Los centros con Aruba tuvieron su propio piloto y luego migraron en una única fase de siete.

Resultado. Los 30 hoteles ya utilizaban el nuevo portal en la semana siete. La interrupción más prolongada en cualquiera de los centros fue de 12 minutos, dentro de una ventana de cambio nocturna. Los inicios de sesión diarios en el piloto coincidieron con las cifras del antiguo proveedor con un margen del 3 %. El contrato anterior finalizó con un margen de 40 días de solapamiento.

¿Cómo demostrar que los nuevos informes coinciden con los anteriores?

Ejecute ambos sistemas en paralelo durante el piloto

No es posible comparar los informes de dos sistemas que nunca han medido a los mismos visitantes. Durante las dos semanas del piloto, mantenga activo el panel de control del proveedor anterior con las exportaciones habilitadas. Extraiga las mismas cinco métricas de ambos sistemas para las mismas fechas y el mismo centro:

• Inicios de sesión diarios.
• Visitantes únicos.
• Visitantes nuevos frente a recurrentes.
• Duración media de la sesión.
• Tasa de aceptación (opt-in) de marketing.

WiFi Analytics de Purple ofrece estas métricas por centro y para todo el conjunto de instalaciones. La duración de la sesión depende de la contabilidad de RADIUS, por lo que debe comprobar que los registros contables se estén recibiendo antes de dar por buena esa cifra.

Concilie a partir de las definiciones, no de los totales

Los totales rara vez coinciden el primer día, y eso no constituye un error en sí mismo. La mayoría de las discrepancias se deben a diferencias en las definiciones. Un proveedor puede contabilizar cada asociación de dispositivo como una visita. Otro puede contar únicamente las sesiones autenticadas. Uno puede fusionar sesiones en un intervalo de 30 minutos y otro no.

Documente la definición de cada proveedor y, a continuación, compare conceptos equivalentes. Las funciones de privacidad de los dispositivos también afectan al recuento de visitantes recurrentes. Apple introdujo las direcciones privadas en iOS 14, y Android aleatoriza las direcciones de forma predeterminada a partir de Android 10. Un proveedor que identifique a los visitantes recurrentes únicamente por la dirección MAC registrará menos visitas recurrentes que otro que realice la concordancia mediante la identidad del inicio de sesión.

Acuerde un margen de tolerancia antes de empezar; por ejemplo, un 5 % en los inicios de sesión diarios. Si no se pacta una cifra de antemano, cada discrepancia dará pie a un debate.

Formalice la aprobación antes de que finalice el periodo de preaviso

Elabore un documento de aprobación de una sola página con las métricas comparadas, la definición de cada proveedor, la discrepancia y la explicación. Procure que lo firmen los departamentos de TI, marketing y compras. A continuación, realice una exportación definitiva de los informes históricos del proveedor anterior para que las comparativas interanuales sigan estando disponibles tras el cambio.

Caso práctico: una cadena de retail de 120 tiendas

Las cifras a continuación son un ejemplo práctico, no una implementación con un cliente específico. Una cadena de moda con 120 tiendas opera puntos de acceso Ruckus bajo un controlador central. El equipo de marketing del grupo necesita tendencias interanuales de visitas de compradores para mantener la continuidad durante el cambio. Nuestra página de Retail aborda este sector con más detalle.

Lo que se hizo. La tienda piloto detectó que el inicio de sesión social fallaba en dispositivos Android. El walled garden contenía los dominios del portal pero no los dominios de inicio de sesión del proveedor de identidad. El equipo de TI solucionó esto antes de la ola 1. En los informes paralelos, el antiguo proveedor mostraba un 18% más de visitas diarias que Purple. El antiguo proveedor contabilizaba cada asociación. Purple contabilizaba sesiones autenticadas. Al volver a ejecutar la exportación antigua solo con sesiones autenticadas, la diferencia se redujo al 2%.

Resultado. Las 120 tiendas se migraron en cuatro olas semanales. Ninguna tienda perdió el WiFi de invitados durante el horario comercial. La conciliación se firmó con una diferencia del 2% frente a una tolerancia acordada del 5%, tres semanas antes de que finalizara el contrato anterior.

¿Qué ajustes de los puntos de acceso fallan con mayor frecuencia durante una migración de Captive Portal?

La mayoría de los fallos se deben a unos pocos ajustes. Esta tabla enumera cada uno de ellos, el síntoma y la solución.

Ajuste	Síntoma cuando es incorrecto	Solución
Faltan los nuevos dominios del portal en el walled garden	El teléfono se conecta pero el portal nunca se carga	Añada cada dominio indicado en la guía de proveedores de Purple y luego elimine los del antiguo proveedor
Faltan los dominios de inicio de sesión social en el walled garden	El inicio de sesión por correo funciona, pero el inicio de sesión social falla	Añada los dominios del proveedor de identidad listados en la guía de proveedores
Discordancia en el secreto compartido de RADIUS	Se acepta el inicio de sesión pero el dispositivo nunca se conecta a internet	Vuelva a introducir el secreto tanto en el controlador como en el nuevo servidor
RADIUS accounting desactivado	Aparecen los inicios de sesión pero la duración de la sesión muestra cero	Active accounting (RFC 2866) con actualizaciones intermedias
El cortafuegos bloquea los puertos RADIUS	El inicio de sesión agota el tiempo de espera solo en una ubicación	Permita el tráfico saliente UDP 1812 y 1813, los puertos asignados en RFC 2865 y RFC 2866
Identificador de sitio asignado de forma incorrecta	Las sesiones aparecen vinculadas a la ubicación equivocada	Haga coincidir el identificador de sitio del controlador con el ID de sitio de Purple
Redirección antigua activa en un grupo de puntos de acceso	La mitad de un sitio muestra el portal antiguo	Audite cada SSID y grupo de puntos de acceso, no solo el predeterminado
Tiempo de espera de sesión copiado del antiguo proveedor	Se vuelve a pedir autenticación a los invitados a mitad de la visita	Establezca el tiempo de espera según la duración de la visita; consulte Cómo implementar restricciones de tiempo y ancho de banda en el WiFi de invitados

Políticas integradas en el antiguo proveedor

Algunos proveedores aplican filtrado de contenidos o límites de ancho de banda en su propia nube, no en su hardware. Al cambiar de proveedor, esas políticas desaparecen de forma silenciosa. Enumere cada política que aplicaba el antiguo proveedor y vuelva a crear cada una antes del cambio definitivo. Los locales nocturnos son los que más enfrentan este problema, tal como explica Proveedores de WiFi para discotecas y locales nocturnos: filtrado de contenidos, capacidad máxima y acceso del personal.

Problemas de reloj y certificados

La contabilidad RADIUS y los certificados del portal dependen de que la hora sea correcta. Un controlador con desfase horario genera registros de sesión que caen en el día equivocado. Dirija cada controlador a un servidor NTP (Network Time Protocol) de confianza antes del piloto.

¿Cuánto cuesta una migración y qué obtiene a cambio?

Las partidas de coste a incluir en el presupuesto

Una migración sobre el hardware existente implica cuatro partidas de costes, ninguna de ellas relacionada con el hardware:

• Licencia durante el solapamiento. Prevea pagar a ambos proveedores durante al menos 30 días.
• Tiempo de TI por sede. Los paneles basados en plantillas reducen este tiempo de forma drástica tras el piloto. Las sedes con controladores independientes requieren más tiempo.
• Limpieza de datos. Alguien debe asignar las versiones de consentimiento, desduplicar los registros y cargar la lista de exclusión.
• Verificación local. Una persona designada en cada sede comprueba que el portal cargue correctamente el día del cambio.

Purple ofrece licencias a través de tres planes: Connect, Capture y Engage. El departamento de compras debe calcular el precio del plan necesario en función del periodo de solapamiento, no respecto al año completo a partir de la migración definitiva.

Lo que obtiene a cambio

Conserva los puntos de acceso que ya tiene, por lo que no hay gastos de capital en hardware. Mantiene una lista de marketing a la que puede enviar correos de conformidad con la ley, ya que la prueba de consentimiento acompaña a cada registro. Obtiene un único modelo de informes para todas las sedes, de modo que las comparaciones globales dejan de depender de qué proveedor gestionaba cada recinto.

Además, se une a una plataforma de solvencia demostrada a gran escala. Purple opera en más de 80.000 recintos en más de 90 países y gestiona 500 millones de usuarios e inicios de sesión al año. Purple ofrece una disponibilidad del 99,999 %, cuenta con la certificación ISO 27001 y cumple con GDPR.

Preguntas frecuentes

¿Necesitamos nuevos puntos de acceso para cambiar de proveedor de WiFi para invitados WiFi a Purple?

No, Purple funciona con los puntos de acceso que ya tiene. Purple es independiente del hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La migración modifica los ajustes del portal cautivo, del walled garden y de RADIUS en su controlador o panel de gestión. Sus puntos de acceso, cableado y conmutadores permanecen donde están, por lo que el cambio de proveedor es un proyecto de configuración, no una renovación de hardware.

¿Podemos seguir enviando correos electrónicos a nuestra lista de invitados existente tras la migración?

Sí, siempre que la prueba de consentimiento se traslade con la lista. El artículo 7(1) del GDPR exige demostrar el consentimiento, por lo que cada registro necesita una marca de tiempo, canal, sede de captación y el texto exacto que vio el visitante. Purple Engage importa los registros que cuentan con consentimiento adjuntando dicho historial. Los registros sin prueba deben importarse como no aptos para marketing. El consentimiento otorgado al antiguo proveedor en su propio nombre, en lugar de a su marca, no se transfiere.

¿Cuánto tiempo lleva una migración de WiFi para invitados WiFi en múltiples sedes?

Prevea de seis a ocho semanas para la mayoría de los despliegues de 20 a 150 sedes. Esto cubre una exportación de dos semanas, una prueba piloto de 14 días y fases de transición adaptadas al volumen que su equipo pueda verificar en un solo turno. Las sedes que comparten un panel de control en la nube avanzan más rápido, ya que una única plantilla de eficacia probada se aplica a muchas. Inicie la planificación a partir de la fecha de preaviso de su antiguo contrato, dejando al menos 30 días de solapamiento para la generación de informes en paralelo.

¿Se quedarán nuestras sedes sin conexión durante la transición?

No, siempre que siga el orden de piloto y fases posteriores. Cada sede cambia durante sus horas de menor actividad comercial, guardando la configuración antigua para permitir una reversión en cuestión de minutos. La mayoría de las interrupciones duran lo que tarda el controlador en aplicar los nuevos ajustes. Los fallos que provocan caídas más prolongadas, como la falta de dominios en el walled garden o puertos RADIUS bloqueados, se detectan en la sede piloto en lugar de en todo el despliegue.

¿El traslado de datos de invitados entre proveedores cumple con el GDPR?

Sí, siempre que usted actúe como responsable del tratamiento y ambos proveedores actúen como encargados del tratamiento bajo contrato. El artículo 28(3)(g) del GDPR exige que el antiguo encargado devuelva o suprima los datos personales al finalizar el servicio, según su elección. Solicite la «devolución» por escrito antes de notificar el cese del servicio. Traslade en primer lugar la lista de exclusión para que cualquier persona que haya revocado su consentimiento siga excluida. Purple cumple con el GDPR y cuenta con la certificación ISO 27001.

¿Qué ocurre con los datos que aún conserva el antiguo proveedor?

El antiguo proveedor debe eliminarlos una vez finalizado el servicio, si su contrato se ajusta al artículo 28 del GDPR. Solicite una confirmación de eliminación por escrito después de haber verificado su exportación y de haber aprobado los informes definitivos. Realice primero una exportación final de los informes históricos, ya que las comparativas interanuales dependen de ese historial. Conserve la confirmación de eliminación junto con sus registros de actividades de tratamiento por si un organismo regulador o un visitante la solicitaran.

¿Cómo demostramos que los informes de Purple coinciden con las cifras de nuestro antiguo proveedor?

Ejecute ambos sistemas en paralelo en la sede piloto durante 14 días y compare cinco métricas: inicios de sesión diarios, visitantes únicos, nuevos frente a recurrentes, duración de la sesión y tasa de aceptación (opt-in). La mayoría de las discrepancias se deben a diferentes definiciones de lo que constituye una visita, no a datos erróneos. Documente la definición de cada proveedor, acuerde previamente un margen de tolerancia (como el 5 %) y valide los datos antes de que finalice el antiguo contrato.

¿Puede Purple conectarse a nuestra plataforma de CRM y correo electrónico actual?

Sí, Purple se integra con plataformas de CRM y marketing. Los perfiles de invitados importados, los nuevos inicios de sesión y los cambios en el consentimiento pueden transferirse al sistema que su equipo de marketing ya utiliza. Conecte la integración antes de su primera campaña posterior a la migración, de modo que las bajas de cualquiera de los dos lados se respeten desde el primer envío. Esto mantiene un único registro de consentimiento entre el inicio de sesión de WiFi y el correo electrónico, que es lo que exige la guía de consentimiento de la ICO.