Gli access point sono montati, la finestra di manutenzione è prenotata e il fornitore dichiara che la configurazione è pronta. Poi il primo login del lunedì fallisce. Un terminale della reception di un hotel finisce sulla VLAN errata, i lettori di codici a barre di un negozio rifiutano l'autenticazione o gli inquilini scoprono che i loro dispositivi sono stati spostati dietro una policy che non possono soddisfare. L'hardware potrebbe essere perfettamente funzionante. Era la pianificazione della migrazione a non esserlo.
Le migrazioni WiFi aziendali falliscono nei divari tra infrastruttura, identità, applicazioni e operazioni. Un piano affidabile tratta questi divari come rischi di ingegneria, non come dettagli amministrativi. Identifica ogni classe di client, definisce la sequenza delle dipendenze di autenticazione, offre ai team aziendali una finestra di transizione realistica e dimostra che il rollback funziona prima che gli utenti di produzione dipendano da esso.
Perché la maggior parte delle migrazioni WiFi fallisce prima ancora di iniziare
Un hotel da 200 camere cambia la propria piattaforma wireless un lunedì mattina. Al termine del servizio colazione, la reception si trova a gestire i reclami di ospiti e personale, mentre il team IT cerca di capire perché i terminali del sistema di gestione della proprietà vedono la rete ma non riescono a completare l'autenticazione. I nuovi access point sono online. L'SSID è visibile. Il problema risiede nella mappatura delle policy tra la VLAN del terminale, il suo metodo di autenticazione e i servizi applicativi di cui ha bisogno.
Questo tipo di incidente ha una dinamica comune, anche quando cambia il luogo. Nel settore retail, un lettore di codici a barre non documentato può bloccare un flusso di rifornimento. In un edificio multi-tenant, il dispositivo di un residente può rimanere isolato perché il team di migrazione ha trattato ogni client come se supportasse i moderni sistemi di autenticazione enterprise. Questi fallimenti iniziano durante la fase di discovery, molto prima che un ingegnere sostituisca un access point.
Le ipotesi che si rivelano errate per prime
Tre presupposti causano problemi sproporzionati:
- Ogni dispositivo supporta il nuovo metodo di autenticazione. Gli scanner più vecchi, le stampanti, le telecamere, i sistemi di controllo ambientale, gli endpoint IPTV e i sensori dell'edificio potrebbero utilizzare credenziali fisse, modalità di sicurezza obsolete o un processo di onboarding specifico del fornitore.
- L'SSO può essere collegato alla fine. Gli identity provider, i criteri RADIUS, i certificati, i gruppi di directory e le regole di accesso condizionale formano una catena di dipendenze. Se la piattaforma wireless viene attivata prima che tale catena sia stata testata con account reali, gli utenti subiranno un'interruzione del servizio anche se la rete stessa è funzionante.
- Il rollback significa ripristinare la vecchia configurazione. Un backup salvato del controller non è un piano di rollback. È necessario un punto decisionale testato, un responsabile con l'autorità di dichiararlo e la conferma che i client possano riconnettersi al servizio precedente senza credenziali obsolete, SSID in conflitto o capacità DHCP esaurita.
Una checklist di migrazione incentrata sui numeri di serie dell'hardware non farà emergere questi problemi. Un piano utile mappa il comportamento dei client rispetto al flusso di lavoro aziendale. La reception ha bisogno di qualcosa di più della semplice copertura wireless. Richiede un accesso affidabile al PMS, ai servizi di pagamento, alle stampanti e alle applicazioni del personale durante una specifica finestra operativa.
Regola pratica: Tratta ogni client non documentato come una potenziale dipendenza di produzione finché il suo proprietario, il metodo di autenticazione, la policy di rete e il percorso di ripristino non vengono registrati.
La pianificazione è controllo del rischio
Un lavoro preliminare strutturato migliora anche la qualità del confronto durante la transizione. Invece di promettere che la modifica sarà invisibile, il team di progetto può indicare chiaramente quali servizi sono protetti, quali dispositivi richiedono un percorso di migrazione, quanto tempo richiederà la validazione e quali evidenze attiveranno un ripristino.
Questa disciplina è fondamentale perché un aggiornamento del WiFi raramente si limita alla sostituzione di un access point. Si tratta di un cambiamento coordinato che coinvolge switching, DHCP, DNS, firewall, identità, configurazione degli endpoint, supporto applicativo, accesso alle strutture e operazioni in prima linea. I team che pianificano queste interfacce in anticipo dedicano la fase di cutover a convalidare ipotesi note. I team che non lo fanno la dedicano a scoprirle.
Creare un inventario di rete completo e una mappa di discovery
Iniziate con un inventario che descriva come si comporta la rete, non solo quali apparecchiature possiede l'organizzazione. L'esportazione da un controller potrebbe elencare gli access point e le radio, ma non rivelerà necessariamente quale SSID utilizzi un sistema di controllo della stanza, quale policy RADIUS assegni la sua VLAN o se la porta dello switch disponga di un margine PoE sufficiente per il modello sostitutivo.
Costruisci la mappatura da quattro prospettive: configurazione logica, infrastruttura fisica, popolazione di client e dipendenza aziendale. Assegna a ogni risorsa un sito, un edificio o piano, un proprietario, un livello di criticità e una wave di migrazione. Dire "ala nord dell'hotel" è utile. Dire "ala nord dell'hotel, corridoio del terzo piano, modello AP, porta dello switch, stato PoE, SSIDs serviti, AP adiacenti e sistemi delle camere interessati" è operativo.
Catalogare la catena logica dei servizi
Registra la relazione tra gli SSID e i servizi sottostanti:
- Infrastruttura wireless: modello dell'access point, numero di serie, firmware, impostazioni radio, appartenenza al gruppo, piano dei canali, policy di potenza di trasmissione e controller o tenant cloud.
- Servizi di rete: identificatori VLAN, scopo della subnet, ambito DHCP, inoltro DNS, regole del firewall, policy di quality-of-service e dipendenze di routing.
- Servizi di identità: profili 802.1X, client RADIUS, autorità di certificazione, gruppi di directory, connettori SSO, impostazioni del Captive Portal e flussi di lavoro degli account guest.
- Classi di client: laptop del personale, terminali POS, scanner, terminali voce, televisori, sensori, stampanti, telecamere, tablet e dispositivi di residenti o ospiti.
Non affidarti a un'unica fonte di rilevamento. Confronta i dati del controller con la telemetria degli switch, i lease DHCP, i log RADIUS, i record di gestione degli endpoint, le interviste ai proprietari delle applicazioni e un sopralluogo fisico. Un singolo gruppo iPSK tralasciato durante questo processo può bloccare la transizione di un punto vendita quando gli scanner legacy perdono il loro accesso di rete previsto.
Acquisire i vincoli fisici
Le informazioni sulle strutture appartengono allo stesso registro di migrazione. Annotate l'altezza di montaggio, i requisiti di accesso, le condizioni dei cavi, la lunghezza del percorso, la posizione dello switch, il budget PoE, il tipo di soffitto, i requisiti del sollevatore e tutte le aree in cui le attività commerciali, il check-in, l'attività clinica o l'accesso dei residenti limitano l'attività ingegneristica.
La seguente checklist fornisce una struttura coerente a ogni sessione di discovery.
| Categoria di Asset | Esempi da Catalogare | Punti Ciechi Comuni |
|---|---|---|
| Access points | Modello, firmware, posizione, profilo radio, AP vicini | Unità non etichettate, soffitti inaccessibili, profili non standard |
| Controller e piattaforme cloud | Tenant, gruppi di configurazione, template, licenze, backup | Override specifici del sito, template inattivi, amministratori non documentati |
| SSID e VLAN | Scopo del SSID, mappatura VLAN, ambito DHCP, percorso del firewall | SSID dismessi ancora utilizzati dai dispositivi, policy sovrapposte |
| Autenticazione | Client RADIUS, profili 802.1X, certificati, gruppi di directory, iPSK | Catene di attendibilità scadute, impostazioni specifiche del vendor, chiavi legacy condivise |
| Switching e PoE | Modello di switch, porta, stato PoE, uplink, configurazione trunk | Alimentazione insufficiente, porte edge con override locali |
| Endpoint e applicazioni | Tipo di dispositivo, proprietario, applicazione, sistema operativo, contatto di supporto | IPTV, controlli della stanza, scanner, stampanti, dispositivi di pagamento |
| Ambiente fisico | Montaggio, cablaggio, finestra di accesso, vincoli di copertura | Zone di ristrutturazione, aree riservate, patching nascosto |
Utilizza un modello di campo strutturato anziché un altro foglio di calcolo non gestito. Un network multi-tool per il discovery strutturato del WiFi può affiancare le esportazioni dei controller e i site survey, a condizione che il team di progetto convalidi i record rispetto al comportamento reale.
Il risultato finale deve essere una mappa delle dipendenze di migrazione. Per ogni fase, mostra gli AP, gli switch, gli SSID, i servizi di identità, le applicazioni, i proprietari dei dispositivi, gli account di test e le risorse di rollback coinvolti. Se un elemento non ha un proprietario o un metodo di validazione, non è pronto per la produzione.
Mappatura degli stakeholder e definizione di tempistiche realistiche
La migrazione WiFi più rapida è spesso quella che evita una pianificazione irrealistica. Una transizione in un solo fine settimana può ridurre la durata del programma, ma concentra il rischio tecnico e l'interruzione operativa in un unico evento. Un rollout graduale richiede un maggiore coordinamento, ma offre al team la possibilità di imparare da un progetto pilota, verificare il comportamento dei dispositivi e modificare i modelli prima del sito successivo.
La scelta giusta dipende dal modello operativo. Un hotel potrebbe richiedere un accesso camera per camera e il coordinamento con il servizio di pulizia, la reception, il reparto tecnico e il fornitore del PMS. Un rivenditore deve proteggere gli orari di apertura, i servizi di pagamento, i sistemi antitaccheggio e i flussi di lavoro dell'inventario. Un operatore residenziale deve tenere conto di inquilini che non sono tenuti a seguire un runbook IT interno.
Mappare le decisioni, non solo i partecipanti
Crea una matrice di responsabilità che indichi chi approva, esegue, convalida e riceve gli aggiornamenti per ciascuna dipendenza.
- Sponsor esecutivo: Approva il rischio aziendale, il budget e la finestra di manutenzione finale.
- Team di rete: Gestisce la configurazione, lo staging, l'esecuzione delle modifiche, la telemetria e i meccanismi di rollback.
- Team di sicurezza e identità: Validano RADIUS, Microsoft Entra ID, Okta, certificati, appartenenza ai gruppi e criteri di accesso.
- Proprietari delle applicazioni: Confermano che i servizi PMS, POS, voce, clinici, dell'edificio e degli inquilini funzionino dalla rete di destinazione.
- Strutture: Forniscono l'accesso, coordinano il cablaggio e il montaggio e confermano i vincoli fisici.
- Operazioni e service desk: Comunicano l'impatto, gestiscono le escalation e registrano i sintomi degli utenti durante il supporto.
- Fornitori: Supportano le applicazioni o gli endpoint che i team interni non possono testare in modo indipendente.
La mappatura degli stakeholder dovrebbe registrare anche la disponibilità, non solo i nomi. Un ingegnere della sicurezza che può esaminare una policy ma non può partecipare alla chiamata di cutover non è una risorsa disponibile. Non lo è nemmeno un fornitore PMS il cui contratto di supporto esclude le modifiche notturne.
Integrare le dipendenze nella pianificazione
Una sequenza pratica inizia con i requisiti e il discovery, per poi passare alla progettazione della configurazione, ai test di laboratorio, alla distribuzione pilota, al rollout scaglionato e al supporto di produzione. Non pianificate il pilota finché l'inventario non è sufficientemente completo. Non pianificate il rollout completo finché il pilota non ha fornito prove per l'autenticazione, il roaming, l'accesso alle applicazioni e il ripristino.
Utilizzare criteri di ingresso e di uscita espliciti:
- Chiusura fase Discovery: Classi di client, SSIDs, VLANs, percorsi di identità, vincoli fisici e proprietari sono documentati.
- Chiusura fase Lab: Modelli target, flussi di autenticazione, certificati, DHCP, policy del firewall e client rappresentativi superano i test controllati.
- Chiusura fase Pilot: Dispositivi e applicazioni reali funzionano nel sito selezionato, le procedure di supporto sono testate e il rollback è stato dimostrato.
- Chiusura fase Wave: Il monitoraggio è pulito, le eccezioni sono registrate e il proprietario del sito accetta il risultato.
- Chiusura programma: Documentazione, credenziali, percorsi di escalation e attività di ottimizzazione sono stati trasferiti al team operativo.
Aggiungi un margine per il lavoro che tende sempre ad espandersi, in particolare i test di identità, la risoluzione dei problemi del fornitore, il coordinamento degli accessi e la remediation dei client. La data di consegna di un fornitore non corrisponde alla data di cutover. La continuità aziendale, le prove dei test e la capacità di supporto devono stabilire la pianificazione.
Una finestra di manutenzione è utile solo quando le persone responsabili del flusso di lavoro interessato sono presenti e autorizzate ad approvare la mossa successiva.
Punti di integrazione per SSO e strategia per i dispositivi legacy
L'autenticazione richiede una propria sequenza di migrazione. Non dovrebbe essere trattata come una semplice scheda di configurazione all'interno del progetto wireless, perché un'associazione riuscita dimostra ben poco se l'utente non può ottenere la policy, l'indirizzo, l'instradamento o l'accesso all'applicazione corretti.
Per l'accesso del personale, definire il percorso di identità prima di modificare lo SSID di produzione. Ciò può includere l'integrazione con Entra ID o Okta, RADIUS o RADIUS-as-a-Service, l'emissione di certificati, la mappatura dei gruppi di directory, l'accesso condizionale e il comportamento di revoca. Testare un utente ordinario, un utente con privilegi, un account disabilitato, un account al di fuori del gruppo target e un dispositivo con un certificato non valido o mancante.
Sequenziare la catena di fiducia
Un ordine sicuro si presenta così:
- Prepara i connettori di identità e i criteri. Crea i gruppi di destinazione, i profili di autenticazione, i certificati e le mappature dei criteri senza rimuovere il percorso esistente.
- Valida la catena di attendibilità. Conferma che il servizio wireless, il livello RADIUS, l'identity provider e le autorità di certificazione si riconoscano a vicenda.
- Esegui i test con endpoint rappresentativi. Includi dispositivi gestiti e non gestiti laddove siano previsti entrambi, e testa i sistemi operativi effettivi utilizzati nel sito.
- Introduci l'SSID o il criterio di destinazione a una popolazione controllata. Mantieni disponibile il servizio esistente mentre il gruppo pilota verifica l'accesso.
- Sposta gli utenti a ondate. Monitora i motivi di mancata autenticazione, l'assegnazione della VLAN, l'acquisizione DHCP e la raggiungibilità delle applicazioni.
- Disattiva il percorso legacy solo dopo che i dati si sono stabilizzati. La dismissione è un cambiamento separato, non una conseguenza automatica della messa in funzione del nuovo SSID.
I team che necessitano di una transizione RADIUS esterna possono seguire un approccio graduale, come quello descritto nella guida alla migrazione a RADIUS-as-a-Service, dove il nuovo servizio funziona in parallelo a quello esistente prima che i singoli SSID vengano spostati e il vecchio percorso venga dismesso una volta esaurito il traffico.
Fornire un percorso deliberato per i dispositivi legacy
I dispositivi legacy non sono un fastidio da nascondere sulla rete principale del personale. Richiedono una progettazione esplicita. Identifica i dispositivi che non possono supportare 802.1X, SAML, autenticazione tramite certificati o i moderni flussi di Captive Portal, quindi assegnali a un SSID dedicato o a un percorso di onboarding controllato.
Un design iPSK può fornire passphrase specifiche per dispositivo o per gruppo mappate sulla VLAN appropriata. Ciò offre a lettori di codici a barre, controlli per le camere, segnaletica digitale, sensori e simili endpoint un percorso di migrazione praticabile, preservando al contempo la segmentazione. Mantenere l'inventario collegato a ciascuna chiave, registrare la proprietà, definire le procedure di rotazione e limitare la VLAN risultante ai soli servizi di cui quella classe di dispositivi ha bisogno.
| Fase | Attività di Integrazione | Dipendenza | Rischio se Saltata |
|---|---|---|---|
| Progettazione | Definire le policy per personale, guest, IoT e dispositivi legacy | Inventario dei client e requisiti applicativi | I dispositivi ereditano un modello di accesso non idoneo |
| Preparazione | Configurare gruppi di identità, certificati, RADIUS e iPSK | Approvazione dell'identità e della sicurezza | Il passaggio di transizione espone dipendenze di chiavi o attendibilità non testate |
| Validazione in laboratorio | Testare endpoint rappresentativi e stati di errore | Account di test e dispositivi campione | I team scambiano il successo della configurazione per il successo dell'utente |
| Pilota | Spostare una popolazione controllata di utenti e dispositivi | Copertura del supporto e monitoraggio | I problemi colpiscono l'intero sito contemporaneamente |
| Rollout a ondate | Modificare SSID o policy per sito o classe di client | Evidenza del pilota e prontezza al rollback | Gli errori di autenticazione si diffondono in tutte le operazioni |
| Dismissione | Esaurire e rimuovere i servizi legacy | Traffico stabile e proprietà documentata | Il ripristino diventa più difficile dopo la disattivazione |
L'ordine più pericoloso è semplice: distribuire i nuovi AP, cambiare il SSID e sperare che il livello di identità si adegui. L'autenticazione deve essere pronta prima della migrazione dei client, mentre i dispositivi legacy necessitano di un percorso supportato piuttosto che di un'eccezione scoperta durante il cutover.
Validazione dei test e pianificazione del rollback
La dashboard di un controller può segnalare radio funzionanti anche quando gli utenti non riescono ad autenticarsi, hanno problemi di roaming o perdono l'accesso alle applicazioni. I test in lab rilevano gli errori di configurazione. Tuttavia, non riproducono il mix completo di dispositivi, traffico, interferenze, applicazioni dei fornitori e flussi di lavoro umani presenti in un hotel, in un negozio, in un campus o in un edificio residenziale.
Validare tre livelli di comportamento
Utilizza tre livelli di validazione, ciascuno dei quali risponde a una domanda diversa.
L'associazione e autenticazione verifica se i client sono in grado di rilevare l'SSID, associarsi, completare l'autenticazione, ricevere la policy prevista e ottenere i servizi di rete. Testate una flotta mista, inclusi dispositivi iOS, Android, Windows e ChromeOS laddove tali piattaforme siano presenti nell'ambiente. Includete gli endpoint legacy e i casi di errore, non solo un laptop aziendale gestito in condizioni perfette.
Il roaming verifica se un client in movimento rimane operativo mentre attraversa i limiti dei vari AP. Cammina per la sede con una chiamata vocale o VoWiFi attiva, testa i corridoi affollati e le aree operative, e registra cadute di linea, eventi di riautenticazione e variazioni nel comportamento dell'applicazione. Un test statico alla scrivania non rileverà un problema di handoff.
Le prestazioni dell'applicazione verificano se il flusso di lavoro aziendale è rimasto attivo. Il team di un hotel dovrebbe testare il PMS, i flussi di pagamento, le stampanti e i servizi per gli ospiti. I team retail dovrebbero convalidare POS, scanner, sistemi di inventario e flussi di prevenzione delle perdite. Non utilizzare uno speed test come sostituto della convalida dell'applicazione. Misura la capacità, non se il servizio di cui le persone hanno bisogno risponde.
Scegliere il rollback in base al sito
Il funzionamento in parallelo e il cutover radicale risolvono problemi diversi.
| Approccio | Punto di forza | Punto debole | Soluzione ideale |
|---|---|---|---|
| SSID paralleli con migrazione graduale | Limita il raggio d'impatto e consente uno spostamento controllato dei client | Aggiunge complessità temporanea di configurazione e supporto | Siti multi-tenant, hospitality, flotte legacy miste |
| Migrazione immediata con configurazione di rollback pianificata | Transizione più rapida e stato finale più pulito | Un eventuale guasto influisce rapidamente su tutta l'utenza | Campus controllati con client compatibili e un forte team di supporto |
| Progetto pilota seguito da roll-out a ondate | Fornisce riscontri operativi prima dell'espansione | Richiede maggiore pianificazione e coordinamento tra i siti | Portafogli distribuiti di hotel e punti vendita retail |
Prima della finestra di manutenzione, salva la configurazione sicuramente funzionante, conferma l'accesso al vecchio piano di gestione, verifica i passaggi di rollback di switch e firewall e identifica chi può autorizzare un annullamento. Durante il cutover, utilizza un albero decisionale:
- Il malfunzionamento è isolato a una specifica classe di client? Se sì, sospendi quella classe, applica la strategia legacy documentata e continua solo se i servizi critici rimangono stabili.
- L'autenticazione del personale o le applicazioni core presentano un guasto generalizzato? Interrompi la wave e ripristina il percorso di servizio precedente.
- Il team è in grado di spiegare il guasto e risolverlo entro la finestra temporale concordata? In caso contrario, procedi al rollback anziché prolungare l'incertezza.
- Dopo il rollback, i client rappresentativi si riconnettono e le applicazioni funzionano? In caso contrario, mantieni aperto l'incidente e non dichiarare il ripristino avvenuto.
Una decisione di rollback deve basarsi sull'impatto osservato sul servizio, non sulla speranza che un'ulteriore modifica della configurazione risolva il problema. I piani migliori rendono la scelta sicura facile da eseguire.
Monitoraggio post-migrazione e verifica del successo
L'attivazione dell'ultimo AP segna l'inizio della verifica operativa, non la fine della migrazione. Il team di supporto ha bisogno di prove che i client possano autenticarsi, ottenere servizi di rete, effettuare il roaming e completare i flussi di lavoro che hanno giustificato il cambiamento.
Utilizzare le osservazioni precedenti alla migrazione come punti di confronto. Esaminare i fallimenti di associazione, l'acquisizione dei lease DHCP, la risoluzione DNS, la risposta delle applicazioni, gli eventi di roaming, lo stato della radio e le richieste di supporto. Analizzare sia i dashboard aggregati sia i singoli incidenti. Una buona media può nascondere un'intera ala di camere non funzionante, uno stack di switch problematico o una famiglia di dispositivi che rappresenta una funzione operativa critica.
Trasforma la telemetria in decisioni
Configurate gli avvisi in base ai sintomi che richiedono un intervento, come ripetuti errori di autenticazione, ritardi DHCP anomali, errori DNS, cadute di roaming o deterioramento della risposta delle applicazioni. Le soglie dovrebbero riflettere la baseline e l'impatto sul business. Una breve interruzione durante il riavvio di un dispositivo può essere normale. Errori ripetuti da tutti i terminali della reception non lo sono.
Il feedback degli utenti colma le lacune che la telemetria non può coprire. Chiedere al personale della reception se il check-in è reattivo, ai colleghi del punto vendita se i lettori funzionano normalmente, ai team di gestione dell'edificio se i dispositivi di facility comunicano correttamente e ai residenti o ospiti se l'onboarding è chiaro. Mantenere i sondaggi brevi e collegare ogni segnalazione a sede, area, tipo di dispositivo e orario, in modo che i tecnici possano correlarla agli eventi di rete.
La guida all'analisi del WiFi può aiutare i team a organizzare la visibilità operativa, ma nessuna piattaforma di analytics elimina la necessità per i proprietari delle applicazioni e il personale di supporto di verificare i flussi di lavoro reali.
Rendere il passaggio di consegne parte del test di successo
Il team delle operazioni dovrebbe ricevere una baseline utilizzabile, non una cartella di esportazioni di dati. Il pacchetto di consegna dovrebbe includere:
- Baseline di configurazione: SSID, intenzioni VLAN, flussi di autenticazione, mappature delle policy, firmware, modelli ed eccezioni approvate.
- Registro degli asset: posizioni degli AP, porte degli switch, vincoli fisici, dispositivi legacy, proprietà delle iPSK e lacune di inventario non risolte.
- Modello di supporto: sintomi di primo livello, contatti per l'escalation, responsabilità del fornitore, procedure di accesso e autorità di rollback.
- Pacchetto di verifiche: risultati dei test di associazione, roaming, applicazioni, copertura e classi di dispositivi critici.
- Backlog di ottimizzazione: perfezionamenti della copertura, modifiche alle policy, aggiornamenti dei client, osservazioni sulla capacità e attività differite rispetto al passaggio definitivo.
Mantieni attivo il monitoraggio durante la finestra post-modifica concordata, con verifiche giornaliere da parte del team delle operazioni di rete e dei referenti di sede. Chiudi la migrazione solo quando i dati sul servizio, il feedback degli stakeholder, la documentazione e la responsabilità operativa sono tutti concordi. In questo modo la pianificazione della migrazione si trasforma in certezza operativa, anziché limitarsi a dichiarare che l'hardware è online.
Purple offre accesso WiFi basato sull'identità, integrazioni SSO, supporto iPSK per dispositivi legacy, opzioni RADIUS-as-a-Service e strumenti di analisi in grado di supportare le attività di rilevamento, autenticazione, cutover e verifica qui descritte. Esaminate le funzionalità di migrazione su Purple e valutate se si adattano ai vostri requisiti di rete, identità e operativi.
