Multi-site RADIUS migration: sequencing sites, access points and policy

You can move a multi-site estate to cloud RADIUS in four phases without a flag day when old and new servers run side by side. Every SSID lists both, and every device trusts the new server certificate. Each site cuts over under IEEE 802.1X with a written exit test. On Purple, the cutover itself is usually a weekend exercise.

What changes in a multi-site RADIUS migration, and what stays put?

The end state is one cloud RADIUS policy serving every site, with identity setting the VLAN. RADIUS, defined in RFC 2865, is the protocol your access points use to ask a server whether a device may join. The server accepts or rejects the device. It can also return attributes such as the VLAN, the network segment the device lands on.

On a secure network, that exchange runs inside IEEE 802.1X, the standard for port-based network access control. 802.1X carries EAP (Extensible Authentication Protocol) between the device, the access point and the server. EAP-TLS, defined in RFC 5216, authenticates both sides with certificates. PEAP wraps a password exchange inside a TLS tunnel.

Four things change:

• Each access point or controller points at a new server address and shared secret. RADIUS calls that device the NAS (network access server).
• Devices see a new server certificate during the EAP handshake.
• Policy reads groups from Microsoft Entra ID, Okta or Google Workspace rather than a local directory.
• Logs move to a new console.

The things that stay the same matter more. You keep your access points, SSID names, VLAN IDs, switch trunks and firewall zones. Nobody changes a password or joins a new network.

The same approach applies to all three networks on Purple Access. On open networks, many captive portals authorize devices through RADIUS. Secure networks use EAP-TLS or PEAP. On xPSK networks, RADIUS gives each device or resident its own pre-shared key. This guide follows the secure network, because it carries the most risk.

{"tone":"warning","title":"The risk that bites: server certificate trust","text":"Devices on EAP-TLS or PEAP check the RADIUS server certificate, and many trust only the old server's certificate authority. Push the new CA to every device profile before the first site moves, or those devices will fail to join and keep retrying."}

Once you have dealt with certificate trust, the rest of the migration is configuration work and holding periods.

What has to be true before phase 1?

Five conditions must be in place before any policy is built. If one is missing, it will cause problems in a later phase.

A complete NAS inventory

List every device that sends requests to the old server. That includes access points, wireless controllers, switches doing wired 802.1X and VPN gateways. Build the list from the old server's RADIUS client list, not from the network diagram. If a NAS is missing from the inventory, you cannot switch the old server off in phase 4.

A policy map, row by row

Write down every rule the old server applies, with its condition, its result and the attributes it returns. Typical rows look like this: staff group to staff VLAN, contractors to a restricted VLAN, corporate laptops by certificate to the corporate VLAN. Note which attributes carry the VLAN. RFC 3580 defines the standard set: Tunnel-Type, Tunnel-Medium-Type and Tunnel-Private-Group-ID. Some estates use vendor-specific attributes instead, and you must mirror those exactly.

A certificate plan

Decide which certificate authority (CA) issues the new server certificate. On managed devices, push that CA through Microsoft Intune, Jamf or your mobile device management (MDM) platform before any site moves. For EAP-TLS, the new server must also trust the CA that issued your device certificates.

An identity source the new server can read

Connect your identity provider and confirm that every group in the policy map exists there. If a group lives only on the old server, recreate it in the identity provider first.

Reachability, owners and change windows

Each site needs a network path to the cloud server, using the addresses and ports in Purple's onboarding documentation. Name an owner for each site and agree on change windows with site managers. Write down the rollback trigger before anything moves.

{"title":"Multi-site RADIUS migration checklist","groups":[{"heading":"Before phase 1","items":[{"text":"Export the old server's RADIUS client list and reconcile it with the NAS inventory","why":"A forgotten NAS blocks decommission"},{"text":"Map every policy rule: condition, result and returned attributes"},{"text":"Confirm every policy group exists in Microsoft Entra ID, Okta or Google Workspace"},{"text":"Push the new server CA to managed devices through your MDM"},{"text":"Open the paths in Purple's onboarding documentation at each site"},{"text":"Name an owner and a change window per site, and agree the rollback trigger in writing"}]},{"heading":"Phase 1: build","items":[{"text":"Freeze policy changes on the old server"},{"text":"Recreate each policy row on the new server"},{"text":"Test one identity per row against both servers and match the replies"}]},{"heading":"Phases 2 and 3: pilot and waves","items":[{"text":"Record a baseline reject rate per site before cutover"},{"text":"Add the new server alongside the old on each SSID"},{"text":"Confirm every device class authenticates on the new server"},{"text":"Hold each wave for one full business cycle before the next"}]},{"heading":"Phase 4: decommission","items":[{"text":"Remove the old server from every SSID and NAS"},{"text":"Confirm zero requests on the old server for the agreed quiet period"},{"text":"Export and retain old server logs under your retention policy"},{"text":"Retire the shared secrets used with the old server"},{"text":"Update the runbook and file each site's exit-test record"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

What are the 4 phases, in order?

The plan has four phases. Each one ends with an exit test you can pass or fail. Nothing moves to the next phase until the test passes, which is how you avoid a big-bang cutover.

{"kind":"timeline","direction":"lr","caption":"An illustrative 40-site estate: four phases, each closed by an exit test","alt":"Timeline showing preparation, then phase 1 build, phase 2 pilot, phase 3 waves and phase 4 decommission across roughly 12 weeks.","nodes":[{"id":"p0","label":"Before phase 1","sub":"Inventory, policy map, CA push, identity source","tone":"neutral","when":"Weeks 1-2"},{"id":"p1","label":"Phase 1: build and mirror","sub":"Policy rebuilt on cloud RADIUS, lab replies match","tone":"brand","when":"Week 3"},{"id":"p2","label":"Phase 2: pilot site","sub":"One site, old server kept as secondary","tone":"brand","when":"Weeks 4-5"},{"id":"p3","label":"Phase 3: waves","sub":"Five, then 10, then the remaining 24 sites","tone":"brand","when":"Weeks 6-10"},{"id":"p4","label":"Phase 4: decommission","sub":"Zero requests on the old server, then shut down","tone":"success","when":"Weeks 11-12"}],"edges":[{"from":"p0","to":"p1","label":"prerequisites met"},{"from":"p1","to":"p2","label":"lab replies match"},{"from":"p2","to":"p3","label":"pilot exit test"},{"from":"p3","to":"p4","label":"all sites cut over"}]}

{"caption":"Phase plan for a multi-site RADIUS migration","asOf":"2026-06-10","columns":[{"key":"phase","label":"Phase"},{"key":"scope","label":"Scope"},{"key":"owner","label":"Owner"},{"key":"exit","label":"Exit test"}],"rows":[["Before phase 1","NAS inventory, policy map, CA push, identity source, site paths","IT manager with identity and access lead","Every NAS listed, every policy group in the identity provider, new CA on managed devices"],["Phase 1: build","Policy rebuilt on cloud RADIUS, no live traffic","Identity and access lead","One test identity per row gets the same reply and VLAN from old and new"],["Phase 2: pilot","One representative site, new server primary, old secondary","Network architect","One business cycle with no unexplained rejects and every device class seen on the new server"],["Phase 3: waves","Remaining sites in growing waves, grouped by console template","Network architect with site owners","Each wave passes the pilot exit test before the next starts"],["Phase 4: decommission","Old server removed from every SSID and NAS","IT manager","Zero requests on the old server for the quiet period, logs retained, secrets retired"]],"footnote":"Owners are roles, not named people. Set the quiet period to at least one re-authentication cycle plus one business week.","download":{"filename":"radius-migration-phase-plan.csv"}}

What happens inside each phase?

Phase 1: build and mirror the policy

Rebuild the policy map on the new server before any live request reaches it. Connect the identity provider, then recreate each row with its condition, result and returned attributes. Keep the VLAN IDs identical, so that switch and firewall configuration never changes.

Test every row from a lab. Use eapol_test, a tool from the wpa_supplicant project. It sends a real EAP exchange to a RADIUS server and prints the reply. Run one identity per row against both servers and compare the replies. The exit test is a match on every row, with the same accept or reject and the same VLAN.

Phase 2: pilot one site

Pick a site that represents the portfolio, not the easiest one. It should have every device class you run, including the difficult ones. Think handheld scanners, payment terminals on WiFi and older laptops. You also need someone on site who can test a device when asked.

Add the new server alongside the old, test it, then make the new server primary. Leave it for one full business cycle. For a hotel, that means a week of shift patterns. For an office, it means a week of Monday-morning logins. The pilot passes when two things are true. First, every device class has authenticated on the new server. Second, the reject rate is no worse than your baseline.

Phase 3: move the portfolio in waves

Make each wave larger than the last as the earlier ones pass. A 40-site portfolio might move one pilot site, then five, then 10, then the remaining 24. Group each wave by console template or group, so that one change reaches every site in it. Meraki configuration templates, Juniper Mist WLAN templates and HPE Aruba Central groups all suit this approach.

Cut over while site staff are present, not at 3 a.m. A change that nobody tests until morning is a change you have not tested. Avoid bundling other network changes into the same window.

Phase 4: decommission the old server

Remove the old server from every SSID and every NAS in the inventory, then watch its logs. Requests should fall to zero. Anything that still arrives comes from a NAS you missed. Keep the quiet period going for at least one re-authentication cycle plus a business week. Then export the logs under your retention policy, shut the server down and retire its shared secrets.

Worked scenario: a 40-hotel group on Cisco Meraki

Take a 40-hotel group running staff WiFi on Cisco Meraki. It uses PEAP against an on-premises RADIUS server at corporate headquarters. Every request crosses the WAN to one building, so a headquarters outage takes staff WiFi down in every hotel.

The group pushes the new CA through its MDM in week one. It rebuilds five policy rows on cloud RADIUS against Microsoft Entra ID, then pilots at a 120-room city hotel. Waves of five, 10 and 24 hotels follow, each one a Meraki configuration template. One hotel rolls back for an afternoon because a housekeeping tablet trusts only the old CA. It moves again a week later.

The outcome:

• All 40 hotels move in six change windows.
• One site rolls back once.
• Corporate headquarters is no longer in the authentication path.

How do the old and new RADIUS servers run side by side?

Parallel running depends on how access points fail over. A NAS sends each request to the first server in its list. It tries the next server only when the first does not answer within the timeout.

An Access-Reject counts as an answer, not a failure, so the NAS will not retry the request elsewhere. That has two consequences:

• Both servers must give the same answer. If they differ, a device's experience depends on which server happened to reply.
• Parallel running is a safety net, not a test. Test policy in phase 1 and at the pilot. Do not test it by waiting to see what failover does.

Check timeouts before the first site moves. A cloud server is further away than a server in your server room. Compare each site's NAS timeout and retry settings with its round-trip time. If the settings are too tight, requests will fail over to the old server for no real reason, and that hides problems. Move RADIUS accounting to the new server at the same moment as authentication, so session records live in one place.

The cutover at each site is simply swapping the order of the two servers. These steps apply to every site, with the vendor differences shown inside step 2.

{"title":"Cut over one site without a flag day","steps":[{"title":"Confirm the site is ready","body":"Check the site against the migration checklist: NAS listed, new CA on managed devices, path to Purple open, owner on site.","check":"Every prerequisite for the site is checked."},{"title":"Add the new server alongside the old","body":"Add Purple cloud RADIUS to the SSID's RADIUS server list, using the shared secret Purple issues for the site. Leave the old server first for now.","check":"The console shows both servers against the SSID.","variants":[{"label":"Meraki","body":"In the Meraki Dashboard, add the server in the SSID's access control settings, ideally in the configuration template."},{"label":"Aruba","body":"In HPE Aruba Central, add the server to the authentication server group the WLAN uses."},{"label":"Ruckus","body":"Add the server to the AAA server profile the WLAN uses, as the secondary server."},{"label":"Mist","body":"In the Juniper Mist portal, add the server to the WLAN's RADIUS authentication servers, ideally in the WLAN template."},{"label":"UniFi","body":"In the UniFi Network application, add the server to the RADIUS profile assigned to the WiFi network."}]},{"title":"Test before you swap","body":"From a test host registered as a RADIUS client, send one identity per policy row to the new server.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Each identity gets Access-Accept or Access-Reject as the policy map says, with the expected VLAN."},{"title":"Swap the order","body":"Make the new server primary and keep the old server as secondary. This is the cutover.","check":"New server logs show requests from every access point at the site."},{"title":"Hold for one business cycle","body":"Compare the reject rate with your baseline and confirm every device class has authenticated.","check":"No unexplained rejects, and the site passes its exit test."}]}

How do you roll back a site or a wave?

Rolling back is the cutover in reverse: you put the old server first again. On each console named above, that is one configuration change. It only works if the old server is still running, unchanged, with its shared secrets intact. That is why decommission comes last. It is also why you freeze policy on the old server at the start of phase 1.

Agree on the triggers before you start. Typical triggers are:

• A device class that cannot join and has no same day fix.
• VLAN assignments that differ from the policy map.
• A reject rate above baseline that you cannot explain within the change window.

{"title":"Go, hold or roll back a wave","start":"q1","nodes":[{"id":"q1","question":"Is any device class failing on the new server that passed on the old?","help":"Compare rejects by device type with the baseline you recorded before cutover.","options":[{"label":"Yes","to":"q2"},{"label":"No","to":"q3"}]},{"id":"q2","question":"Is the failure confined to one device class with a known fix?","help":"A missing CA in one profile is a known fix. Rejects across several classes are not.","options":[{"label":"Yes","to":"o2"},{"label":"No","to":"o3"}]},{"id":"q3","question":"Does every test identity land on the expected VLAN at every site in the wave?","options":[{"label":"Yes","to":"q4"},{"label":"No","to":"o3"}]},{"id":"q4","question":"Has the wave run one full business cycle with no unexplained rejects?","options":[{"label":"Yes","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Go: start the next wave","detail":"Record the exit-test result per site and schedule the next wave.","link":"[One policy across every location](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Hold: fix, then retest","detail":"Put the old server first on the affected SSID only, fix the profile or rule, and rerun the exit test."},{"id":"o3","outcome":"Roll back the wave","detail":"Put the old server first on every SSID in the wave, capture logs from both servers and find the cause before trying again.","link":"[When RADIUS is unreachable](guide:radius-server-down-wifi)"}]}

After any rollback, export logs from both servers for the failed window. Find the cause and fix it in the new policy. Then rerun the phase 1 lab test for the affected row before the site moves again.

How do you know the migration is finished?

The migration is finished when the evidence says so, not when the last site moves. Five tests close it:

1. The old server has logged zero requests for the agreed quiet period.
2. Every NAS in the inventory appears in the new server's logs.
3. A real device has exercised every policy row and landed on the expected VLAN.
4. The reject rate is at or below the baseline you recorded before phase 2.
5. The old server is off, its logs are retained, its secrets are retired and the runbook is updated.

Keep a one-page record for each site, with the date, the exit-test result and any rollback. Together with the new authentication logs, those records are your evidence for the ISO 27001 access-control and PCI DSS logging controls. They also serve as change-control evidence for the next audit cycle.

Failure modes seen in the field

Devices that trust only the old certificate

This is the most common failure. Unmanaged PEAP devices may prompt for the new certificate or refuse it outright. Some managed profiles pin the server name as well as the CA. Check both before the pilot.

A NAS nobody listed

Forgotten controllers, wired 802.1X switches and VPN gateways keep the old server busy long after the WiFi has moved. The quiet period in phase 4 is how you catch them.

Policy that lived on the old server

Local groups, hard-coded MAC lists and time-of-day rules often exist only on the old server. If they are not in the policy map, they disappear at cutover.

Shared secret and attribute mismatches

A mistyped secret fails silently on some consoles. A VLAN returned by name rather than by ID can drop devices onto the default VLAN. Both should show up in phase 1 testing, and you should check again at the pilot.

Timeouts tuned for a server in the building

Tight timeouts on a NAS cause spurious failover to the old server. Everything appears to work until the old server is removed.

Worked scenario: a 120-store retailer on two consoles

Take a 120-store retailer with older stores on HPE Aruba and newer ones on Juniper Mist. Store handhelds and laptops use EAP-TLS against a pair of on-premises RADIUS servers. The pilot and waves go cleanly, grouped by Aruba Central group and Mist WLAN template.

In phase 4, the old servers keep logging requests from three addresses after every SSID has moved. Two are distribution-center controllers outside the store estate. The third is a VPN gateway for corporate office laptops. The team adds all three to the inventory, moves them in one extra window and restarts the quiet period. Decommissioning finishes two weeks late, with no outage at any store.

Where Purple fits

Purple Access runs open, secure and xPSK networks on one platform, using the access points you already own. The secure network carries this migration. It provides cloud RADIUS, EAP-TLS and identity from Microsoft Entra ID, Okta or Google Workspace. It also supports Passpoint, also called Hotspot 2.0, which lets devices join a secure network automatically with a credential. Purple is hardware-agnostic, so one policy serves sites on these platforms:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme
• Fortinet

That means a mixed estate can migrate on one plan.

Purple runs the largest cloud RADIUS in the world. It comes with a 99.9% RADIUS uptime SLA, on a platform that runs at 99.999% uptime. Because the Purple side is built before phase 2 starts, each site's cutover is usually a weekend exercise. The phasing exists to manage the risk in your estate, not on our platform.

{"items":[{"value":"80,000+","label":"live venues","note":"Purple's own data"},{"value":"90","label":"countries"},{"value":"99.9%","label":"RADIUS uptime SLA","note":"On a platform running at 99.999%"}]}

{"tone":"proof","title":"Staff WiFi at branch scale","text":"JPMorgan runs staff WiFi on Purple across 5,000 branches."}

See cloud RADIUS on Purple Access for the product detail, and the enterprise WiFi security guide for the wider control set. Guest marketing sits in Engage and DNS filtering sits in Shield. Neither changes during a RADIUS migration.

Frequently asked questions

How long does a multi-site RADIUS migration take?

Plan for weeks across the portfolio and a weekend per site. On Purple, each site's cutover is usually a weekend exercise. The portfolio takes longer because each wave holds for one business cycle before the next starts. An illustrative 40-site portfolio runs about 12 weeks from inventory to decommission. Most of that time goes on preparation and holding periods, not on change work.

Do I need new access points to move to cloud RADIUS?

No. Cloud RADIUS changes the server your access points ask, not the access points themselves. Purple works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You add the new server to each SSID's RADIUS server list in the console you already use. Your SSIDs, VLAN IDs and switch configuration stay as they are.

How should I model the cost of cloud RADIUS across many sites?

Model it on two numbers: sites and identities. Count every site that authenticates and every identity that joins, including devices on EAP-TLS. Then compare that with the full cost of the old server: hardware, licenses, patching, high availability and the WAN path to corporate headquarters. Our guide to modeling cloud RADIUS cost per site walks through the calculation.

Can I keep the old RADIUS server as a fallback after the move?

Keep it during parallel running, then switch it off. While it is listed as secondary, it covers timeouts at sites still in the waves. After phase 4, a server holding a frozen copy of the old policy becomes a risk, because any answer it gives uses stale rules. From then on, resilience comes from the 99.9% RADIUS uptime SLA and an outage recovery plan.

Will staff have to re-enroll their devices?

Not if the new server certificate is trusted before cutover. Push the new CA to managed devices through your MDM during the build phase. EAP-TLS devices keep their existing client certificates, provided the new server trusts the CA that issued them. Unmanaged PEAP devices are the exception, because some prompt once to accept the new certificate. Send those staff a short notice before their site moves.

Does the migration affect our ISO 27001 or PCI DSS evidence?

It changes where your evidence comes from, so plan for that from the start. Authentication logs, policy definitions and change records move to the new platform. Retain the old server's logs under your retention policy and file each site's exit-test record. Purple holds ISO 27001 certification, which gives your auditors evidence for the platform side. Your own controls still need their own evidence.

How is this different for an MSP running many estates?

The phases are the same. What differs is isolation between estates. An MSP runs the same four phases for each estate, but each one needs its own policy, identity source and logs on a shared platform. Waves usually follow contract boundaries rather than console templates. Our guide to multi-tenant RADIUS for MSPs covers how to keep each estate separate during and after the move.