Migration Guide

This guide walks you through migrating from an existing RADIUS solution to IronWiFi. Whether you are moving from Cisco ISE, FreeRADIUS, Microsoft NPS, or another RADIUS server, the process follows the same pattern: export your current data, set up IronWiFi, import users, test in parallel, and cut over.

Migration Overview

┌─────────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  1. Assess &    │ ──▶ │  2. Set Up   │ ──▶ │  3. Import   │ ──▶ │  4. Test &   │
│     Plan        │     │  IronWiFi    │     │  Users/Data  │     │  Cut Over    │
└─────────────────┘     └──────────────┘     └──────────────┘     └──────────────┘

Typical migration timeline:

Phase	Duration	Activities
Assessment	1-2 days	Document current setup, export data
IronWiFi setup	1-2 days	Create Networks, configure policies
User import	1 day	Import users, verify attributes
Parallel testing	3-7 days	Run both systems, validate
Cutover	1-2 hours	Switch access points to IronWiFi

Phase 1: Assess Your Current Environment

Before migrating, document what you have today.

Inventory checklist

Gather this information from your current RADIUS deployment:

User accounts -- Total count, usernames, email addresses, group memberships
Authentication methods -- PEAP-MSCHAPv2, EAP-TLS, PAP, MAC auth, etc.
RADIUS policies -- Bandwidth limits, session timeouts, VLAN assignments, time restrictions
Network equipment -- Access point models, controllers, switch configurations
Certificates -- CA certificates, server certificates, client certificates (for EAP-TLS)
Identity provider integrations -- Active Directory, LDAP, Azure AD, Okta
Captive portals -- Splash pages, customizations, authentication providers
Accounting/reporting -- Data retention requirements, compliance needs

Export your user data

From Cisco ISE

Export users from Cisco ISE's internal identity store:

Navigate to Administration > Identity Management > Identities > Users
Click Export to download the user list as CSV
Note group memberships under Identity Groups
Document authorization policies under Policy > Policy Sets

Key fields to capture:

Username, Email, First Name, Last Name, Identity Group, Status

From FreeRADIUS

Export users from the FreeRADIUS database:

# If using SQL backend (MySQL/MariaDB)
mysql -u root -p radius -e "
  SELECT username, attribute, op, value
  FROM radcheck
  ORDER BY username;" > radcheck_export.csv

mysql -u root -p radius -e "
  SELECT username, attribute, op, value
  FROM radreply
  ORDER BY username;" > radreply_export.csv

mysql -u root -p radius -e "
  SELECT groupname, attribute, op, value
  FROM radgroupcheck
  ORDER BY groupname;" > radgroupcheck_export.csv

mysql -u root -p radius -e "
  SELECT username, groupname, priority
  FROM radusergroup
  ORDER BY username;" > radusergroup_export.csv

# If using flat files
cat /etc/freeradius/3.0/users > users_export.txt

From Microsoft NPS

Export NPS configuration and user data:

Open Network Policy Server console
Right-click NPS (Local) > Export Configuration to save as XML
For user accounts stored in Active Directory, export with PowerShell:

# Export AD users in the RADIUS-enabled group
Get-ADGroupMember -Identity "RADIUS Users" -Recursive |
  Get-ADUser -Properties EmailAddress, MemberOf |
  Select-Object SamAccountName, EmailAddress, Enabled,
    @{Name='Groups'; Expression={($_.MemberOf | Get-ADGroup).Name -join ','}} |
  Export-Csv -Path "nps_users.csv" -NoTypeInformation

Document Network Policies under Policies > Network Policies -- note conditions, constraints, and RADIUS attributes for each policy

Map your policies

Create a mapping table between your current RADIUS policies and IronWiFi equivalents:

Current Policy	Current Setting	IronWiFi Equivalent
Bandwidth limit	`WISPr-Bandwidth-Max-Down := 5000000`	Group reply attribute: `WISPr-Bandwidth-Max-Down`
Session timeout	`Session-Timeout := 3600`	Group reply attribute: `Session-Timeout`
VLAN assignment	`Tunnel-Private-Group-ID := 100`	Group reply attributes: `Tunnel-Type` , `Tunnel-Medium-Type` , `Tunnel-Private-Group-ID`
Time restriction	`Login-Time := Mo-Fr0800-1700`	User check attribute: `Login-Time`
Concurrent sessions	`Simultaneous-Use := 1`	User check attribute: `Simultaneous-Use`

IronWiFi uses standard RADIUS attributes, so most policies translate directly. See Attributes for the complete attribute reference.

Phase 2: Set Up IronWiFi

Create your account and Networks

Register at console.ironwifi.com/register
Create a Network for each region where you have access points
Note the RADIUS server IPs, ports, and shared secret for each Network

See the Quick Start Guide for detailed setup instructions.

Configure Groups and Policies

Recreate your existing policies as IronWiFi Groups:

Navigate to Users > Groups
Create groups matching your current policy structure
Add the corresponding RADIUS attributes to each group

Example: Recreating a "Standard Employee" policy:

Create a group named "Standard Employee"

Add reply attributes:

```
Session-Timeout := 28800
```
(8-hour session limit)
```
WISPr-Bandwidth-Max-Down := 10000000
```
(10 Mbps download)
```
WISPr-Bandwidth-Max-Up := 5000000
```
(5 Mbps upload)
```
Tunnel-Type := VLAN
```
```
Tunnel-Medium-Type := IEEE-802
```
```
Tunnel-Private-Group-ID := 100
```

See Groups for complete configuration options.

Set Up Identity Provider Integration

If your current RADIUS server authenticates against an external identity provider, configure the equivalent in IronWiFi:

Current Integration	IronWiFi Solution
Active Directory (on-premises)	Connector for AD sync
Microsoft Entra ID (Azure AD)	SCIM provisioning or Connector
Google Workspace	Connector for Google sync
Okta	SCIM provisioning or Connector
LDAP	Connector for LDAP sync

tip

If you currently authenticate against Active Directory using PEAP-MSCHAPv2, you can continue the same authentication flow with IronWiFi. Set up a Connector to sync AD users, and they will authenticate with their existing AD credentials.

Configure Captive Portals (if applicable)

If you are migrating a guest WiFi deployment with a captive portal:

Navigate to Captive Portals in the IronWiFi Console
Create a new captive portal linked to your Network
Configure authentication methods (email, social login, vouchers)
Customize the splash page to match your current branding
Note the splash page URL and walled garden settings

See the Quick Start Guide for captive portal setup.

Phase 3: Import Users

Preparing your user data

Format your exported user data into a CSV file with these columns:

username,email,fullname,password,group
john.doe,john@example.com,John Doe,TempPass123,Standard Employee
jane.smith,jane@example.com,Jane Smith,TempPass456,Executive
visitor.kiosk,kiosk@example.com,Lobby Kiosk,,Guest Access

warning

If your current system stores only password hashes (NT-Password, MD5, etc.), you cannot migrate the plaintext passwords. Users will need to set new passwords, or you should connect IronWiFi to the same identity provider (AD, LDAP) so passwords continue to work.

Importing via the Console

For smaller deployments (under 100 users):

Navigate to Users
Click Add User for each user
Enter username, email, and password
Assign the appropriate group
Click Save

Importing via the API

For larger deployments, use the REST API to automate user creation:

# Create a user
curl -X POST "https://console.ironwifi.com/api/users" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "john.doe",
    "email": "john@example.com",
    "fullname": "John Doe"
  }'

Example batch import script:

import csv
import requests
import time

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://console.ironwifi.com/api"
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

with open("users_export.csv", "r") as f:
    reader = csv.DictReader(f)
    for row in reader:
        # Create user
        user_resp = requests.post(
            f"{BASE_URL}/users",
            headers=HEADERS,
            json={
                "username": row["username"],
                "email": row["email"],
                "fullname": row["fullname"]
            }
        )
        user = user_resp.json()
        print(f"Created user: {row['username']} (ID: {user.get('id')})")

        # Set password if provided
        if row.get("password"):
            requests.post(
                f"{BASE_URL}/attributes",
                headers=HEADERS,
                json={
                    "userid": user["id"],
                    "attribute": "Cleartext-Password",
                    "operator": ":=",
                    "value": row["password"],
                    "table": "radcheck"
                }
            )

        # Brief pause to respect rate limits
        time.sleep(0.5)

note

The API has a rate limit of 100 requests per minute. Add a brief delay between requests for large imports. See Rate Limiting for details.

Using Identity Provider Sync

If you are connecting to an identity provider instead of importing users manually, the sync handles user creation automatically:

Configure the Connector or SCIM provisioning
Run the initial sync
Verify users appear in the IronWiFi Console
Assign groups to synced users

Phase 4: Parallel Testing

Run IronWiFi alongside your existing RADIUS server before cutting over. This lets you validate that authentication works correctly without disrupting production.

Test strategy

Reconfigure a test access point to point to IronWiFi's RADIUS servers
Connect test devices and verify:
- Authentication succeeds with correct credentials
- Authentication fails with incorrect credentials
- VLAN assignment works correctly
- Bandwidth limits are applied
- Session timeouts behave as expected
- Captive portal redirects work (if applicable)
Compare results between IronWiFi and your current system

Validation checklist

Test	Expected Result	Pass?
Valid user authenticates	Access-Accept
Invalid password rejected	Access-Reject
Disabled user rejected	Access-Reject
VLAN assigned correctly	Correct `Tunnel-Private-Group-ID` in reply
Bandwidth limit applied	Rate limiting active after authentication
Session timeout enforced	Session ends after configured duration
Accounting data recorded	Sessions appear in IronWiFi Reports
Captive portal redirects	Splash page loads correctly
EAP-TLS with client cert	Certificate authentication succeeds

Extending the parallel run

If initial tests pass, expand gradually:

Add more access points to IronWiFi over several days
Monitor Reports for unexpected rejections
Set up monitoring for the IronWiFi RADIUS servers
Keep your old RADIUS server running as a fallback

Phase 5: Cutover

Pre-cutover checklist

All users imported or synced to IronWiFi
Groups and policies recreated and tested
Parallel testing completed successfully for at least 3 days
Monitoring configured for IronWiFi RADIUS servers
Rollback plan documented (old RADIUS server details saved)
Maintenance window communicated to users

Cutover procedure

Schedule during low-usage hours -- Early morning or weekend
Reconfigure all access points to use IronWiFi RADIUS servers:
- Update Primary RADIUS server IP and port
- Update Backup RADIUS server IP and port
- Update shared secret
- Keep accounting configuration updated too
Verify authentication -- Connect a test device from each location
Monitor reports -- Watch for rejections in the IronWiFi Console for the first hour
Confirm success -- All users connecting without issues

Rollback plan

If critical issues arise during cutover:

Revert access point RADIUS settings to the old server
Investigate failures in IronWiFi authentication reports
Resolve the issue and schedule another cutover attempt

warning

Keep your old RADIUS server running and accessible for at least 2 weeks after cutover. This gives you a fast rollback option while you validate the new setup in production.

Source-Specific Notes

Migrating from Cisco ISE

ISE authorization policies map to IronWiFi Groups with reply attributes
ISE identity groups map to IronWiFi Groups
ISE profiling policies (device type detection) can be replicated using MAC-based attributes
ISE guest portals map to IronWiFi Captive Portals
ISE posture assessment is not available in IronWiFi -- evaluate whether you need it

Migrating from FreeRADIUS

FreeRADIUS
```
radcheck
```
and
```
radreply
```
tables map directly to IronWiFi user check and reply attributes
FreeRADIUS
```
radgroupcheck
```
and
```
radgroupreply
```
map to IronWiFi Group attributes
Custom FreeRADIUS modules (e.g.,
```
rlm_python
```
,
```
rlm_perl
```
) need to be replaced with IronWiFi API integrations or webhooks
FreeRADIUS
```
unlang
```
policies need to be recreated as IronWiFi attribute-based rules

Migrating from Microsoft NPS

NPS Network Policies map to IronWiFi Groups
NPS Connection Request Policies are handled automatically by IronWiFi's RADIUS infrastructure
If NPS authenticates against Active Directory, set up an IronWiFi Connector for AD sync
NPS RADIUS client configurations (access points) need to be updated to point to IronWiFi
NPS accounting logs are replaced by IronWiFi Reports

Post-Migration Tasks

After a successful cutover:

Monitor closely for 2 weeks -- Check authentication reports daily for unexpected rejections
Update documentation -- Record IronWiFi RADIUS server details in your network documentation
Set up long-term monitoring -- Configure monitoring and alerting
Decommission old server -- After 2-4 weeks of stable operation, decommission the old RADIUS server
Train your team -- Ensure network administrators know how to manage users and policies in the IronWiFi Console

Quick Start Guide -- Initial IronWiFi setup
Deployment Planning -- Architecture and capacity planning
Networks -- RADIUS server configuration
Groups -- Access policies and attributes
Connectors -- Identity provider integration
REST API -- Programmatic user management
Configuration Guides -- AP-specific setup instructions

Was this page helpful?

Migration Overview​

Phase 1: Assess Your Current Environment​

Inventory checklist​

Export your user data​

From Cisco ISE​

From FreeRADIUS​

From Microsoft NPS​

Map your policies​

Phase 2: Set Up IronWiFi​

Create your account and Networks​

Configure Groups and Policies​

Set Up Identity Provider Integration​

Configure Captive Portals (if applicable)​

Phase 3: Import Users​

Preparing your user data​

Importing via the Console​

Importing via the API​

Using Identity Provider Sync​

Phase 4: Parallel Testing​

Test strategy​

Validation checklist​

Extending the parallel run​

Phase 5: Cutover​

Pre-cutover checklist​

Cutover procedure​

Rollback plan​

Source-Specific Notes​

Migrating from Cisco ISE​

Migrating from FreeRADIUS​

Migrating from Microsoft NPS​

Post-Migration Tasks​

Related Topics​