It is recommended that you make eduroam the main Wi-Fi network for your staff, students, and visitors. By requiring your own users to connect to eduroam while on their home campus, you ensure that their devices are correctly set up before they travel (possibly to another country). This will make it easier for your Help Desk. If eduroam is the only Wi-Fi network (SSID) available, your users will find it easier to automatically connect to eduroam when they are in other places where it is available.
We are often asked how campuses can switch to using only eduroam while reducing risks and the support needed. Instead of making a sudden, large change, we suggest making small, gradual changes that slowly encourage the use of eduroam over old Wi-Fi networks. If you use separate SSIDs for staff and students, you can further reduce the risks and workload by staggering these transitions. For example, you might start the staff migration six months after students.
This document outlines a plan to complete this transition over a two-year period. If any issues arise during the process, it is easy to pause or return to a previous stage, which helps reduce risk.
.
Make sure that connecting to eduroam offers the same user experience as connecting to your current legacy SSIDs. For example, if you have a "Staff" SSID, staff members should be able to access the same network and have the same experience when logging in with their institutional credentials on the eduroam SSID.
This approach is recommended even if you keep separate SSIDs, as staff and students will likely connect to eduroam at some point—since most devices automatically connect to the last-used SSID.
To achieve this, set up your RADIUS server(s) and Wi-Fi infrastructure to assign VLANs dynamically to eduroam users. This will ensure that different user groups are connected to the correct network. Most Wi-Fi systems use the Tunnel-Private-Group-Id attribute in RADIUS responses for this purpose (more info).
You can test this with your own IT staff, and it will also naturally be tested by users connecting on their own.
Before beginning any transition, make sure that your user-facing documentation is up-to-date. You should remove any references to your legacy Wi-Fi and only provide information on connecting to eduroam. This is the first step towards making an eduroam-only campus a reality.
Google for mentions of your legacy SSID and eduroam on your web page, and make sure out-of-date documentation is removed or updated. You'll be amazed at how many places your Wi-Fi connection information is replicated.
Ideally, you should be making use of an onboarding app like geteduroam, where you can provide a single coherent set of instructions regardless of what device people make use of.
You will inevitably need to let visitors who don't have eduroam access the Internet, be they conference delegates or simply people from institutions that don't participate. You can continue to use a separate SSID for these users, together with whatever management system you already use. Or you can consider adopting the eduroam Visitor Access service.
You may also need to think about IoT devices and should consider a dedicated hidden SSID for those. These would not normally be eligible for eduroam, and you probably already separate them from your staff and students.
.
The start of the academic year is an ideal time to introduce changes for students. Ensure that all first-year students and new staff use only the eduroam SSID.
If your documentation is up-to-date, many users will follow the correct process automatically. However, it's important to make sure that IT support staff, library staff, residence teams, etc provide the right information. Running an awareness campaign for these staff members can help ensure students receive accurate guidance when they need it
Take advantage of natural transitions to move existing users to eduroam over time. When a user gets a new device, ensure it is only set up to connect to eduroam. Similarly, if a user brings a device to the Help Desk for troubleshooting, use the opportunity to reconfigure its Wi-Fi settings to connect to eduroam before returning it.
As the first year progresses, plan to formally announce the deprecation of the old SSIDs. By the end of the year, approximately a third of your student population—and ideally some staff—should already be using eduroam. This gradual transition helps minimise disruption and ensures a smoother migration for remaining users.
At the start of the new academic year, hide the legacy SSIDs across your Wi-Fi infrastructure. Devices already configured for these networks will still connect, but users setting up a new connection won’t see them, encouraging them to switch to eduroam.
Continue migrating existing users whenever possible, ensuring a smooth transition.
Set a clear date for shutting down the legacy SSIDs and communicate this to all users. Run an awareness campaign encouraging users to migrate on their own, providing self-help documentation to guide them through the process.
Emphasise that the change does not need to happen immediately, but ensure users know the final deadline by which they must switch to eduroam.
As the end of the year approaches, remind users of the upcoming deadline to switch to eduroam. Continue directing them to self-help documentation and reinforce the need to migrate whenever possible. Clear and consistent communication will help prevent last-minute issues and disruptions.
Be sure to inform final-year students who are leaving that they can safely ignore these messages, as the change will not affect them.
At the start of the third year, before students return, fully decommission the legacy SSIDs. This is the first point where users may experience disruptions, so ensure your help desk is prepared for any support requests.
By this stage, most students will have already migrated—those who started using eduroam in their first year are now in their third. Ideally, nearly all staff will have also transitioned through gradual migration efforts. If the process has been managed well, only a small number of users should still be relying on the old SSIDs.
You can either disable the SSIDs entirely or reconfigure them to display a captive portal or walled garden with an error message and instructions on how to switch to eduroam.
.
If you make use of on-premise RADIUS, you shouldn't have any off-campus dependencies. So long as your Wi-Fi controller can reach your RADIUS server(s), and your RADIUS server(s) can authenticate your users, you can continue to make use of eduroam as an islanded Wi-Fi network. This is because authentication of your own users should short-circuit, and never be forwarded to the eduroam FLR servers.
This is no different to what would happen on your legacy SSIDs.
Of course, if your Wi-Fi already has cloud dependencies, that doesn't change. And eduroam visitors won't be able to authenticate.
This comes from an assumption that there's a one-to-one relationship between Wi-Fi SSIDs and the underlying network (VLAN). While that's generally true with WPA2-PSK, it's not true with enterprise Wi-Fi. Instead, the relationship is between the user and the network based on dynamic VLAN responses from your RADIUS servers.
Well, don't give them the same access! Put your network restrictions at the network (VLAN) layer, not the SSID layer.