Switching guest WiFi providers: a migration checklist for multi-site venues

Switching guest WiFi providers across multi-site venues requires exporting guest data, configuring cloud RADIUS under RFC 2865 and RFC 2866, and running a 14-day pilot before rolling out in waves. Existing hardware from vendors like Cisco Meraki or HPE Aruba integrates without replacing equipment, while maintaining parallel reporting over a 30-day overlap protects continuous service.

What does switching guest WiFi providers actually involve?

A guest WiFi provider switch moves three things: your guest data, your network settings and your reporting. Your access points stay where they are. With a cloud overlay such as Purple's Guest WiFi, the new provider sits on the hardware you already own. That hardware includes Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The reasoning is covered in Why your next WiFi upgrade doesn't need new hardware.

Three terms carry most of the work in a guest WiFi migration:

• Captive portal: the sign-in page a visitor sees before they get online.
• Walled garden: the list of domains a device can reach before sign-in, so the portal and any social login pages can load.
• RADIUS: the protocol defined in RFC 2865 that access points use to ask a server whether to admit a device. Its accounting extension, RFC 2866, reports session start, stop and duration back to the server.

The two failures that matter are a dark day and a lost list. A dark day is a site where guests cannot get online because a setting was missed. A lost list is a marketing database you can no longer email because the consent evidence stayed with the old provider. The order of work below exists to prevent both.

What do you need before you change guest WiFi provider?

Your contract dates and data clauses

Start with the old contract, not the network. Find three dates: the notice deadline, the end of service and any data return deadline. Under GDPR Article 28(3)(g), a processor must delete or return personal data at the end of the service, at your choice as controller. Write to the old provider and choose "return", in writing, before you serve notice.

Plan for an overlap of at least 30 days between the new service going live and the old one ending. You need that overlap for the parallel reporting run described later. If the notice period is 90 days, count backwards: export in the first fortnight, pilot by day 45, final wave by day 75.

An inventory of every site

You cannot sequence a cutover you cannot see. Build one sheet with a row per site and these columns:

• Access point vendor and controller or dashboard (for example, Cisco Meraki dashboard, HPE Aruba Central, Ruckus SmartZone).
• Guest SSID names and any VLAN (virtual LAN, a separate network segment) the guest traffic sits on.
• Who owns the firewall and broadband line at that site.
• A named local contact who can confirm the portal loads on a phone.
• Trading peaks and blackout dates.

A clean export from the old provider

Ask for the export in writing and specify the format. A vague request returns a vague file. This table sets out what to ask for.

Field	Why you need it	Format to request
Email address	Primary key for marketing and de-duplication	UTF-8 CSV, one record per row
Mobile number	SMS marketing and matching	ITU-T E.164 international format
Consent flag per channel	Email and SMS consent are separate under PECR	One true/false column per channel
Consent timestamp	Proves when consent was given (GDPR Article 7(1))	ISO 8601 with UTC offset
Consent wording or version	Proves what the visitor was told	Version ID mapped to archived portal copy
Capture site	Ties consent to the venue that collected it	Site ID matching your inventory
Withdrawals and unsubscribes	Stops you emailing people who opted out	Separate suppression file with dates
Visit history	Baseline for report reconciliation	Monthly totals per site, last 13 months

Check row counts on arrival. If the old dashboard shows 200,000 profiles and the file holds 160,000, ask why before you sign anything off.

Consent evidence that survives the move

GDPR Article 7(1) says that where processing relies on consent, the controller must be able to demonstrate it. The ICO's consent guidance names what that record holds: who consented, when, how, what they were told and whether they have withdrawn. A spreadsheet of email addresses with a "marketing = yes" column meets none of those tests.

Three steps carry consent across intact:

1. Archive the old portal wording. Screenshot every version of the sign-in page and privacy notice, dated, and map each to the consent version field.
2. Check whose name the consent is in. GDPR Recital 42 says the data subject should know at least the identity of the controller. Consent given to your venue brand carries over. Consent given to the old provider's own marketing does not.
3. Import the suppression list first. Anyone who unsubscribed must stay unsubscribed in the new system from the first day.

Records with no timestamp or no wording version are not marketable. Import them as contacts without marketing consent rather than deleting them, so visit history stays intact.

How do you run a guest WiFi migration site by site?

Step 1: import the list before you touch an access point

Import into Purple Engage first. Purple Engage takes consented guest records with their consent history, so each profile keeps its timestamp, channel and wording version. Doing this before any cutover means no marketing send goes out without the suppression list loaded. It also means returning visitors meet a database that already holds their record.

Purple Engage integrates with CRM and marketing platforms. If your email platform is the system of record for unsubscribes, connect it before the first campaign, not after.

Step 2: build the captive portal, walled garden and RADIUS settings

Purple Access handles the captive portal and cloud RADIUS on the access points you already own. Build one portal template per brand, then clone it per site so the site ID is correct from the start. Write the new consent wording with conscious-choice opt-ins, one per channel, and record its version before go-live.

For the access point side, follow Purple's support article for your specific vendor rather than copying values from the old provider. Server addresses, shared secrets and walled garden domains differ between providers. A setting carried over from the old configuration is the most common cause of a failed cutover.

Step 3: cut over one pilot site

Pick a pilot that is typical, not easy. It should run your most common hardware, see normal visitor numbers and sit within reach of your IT team. Cut over during the quietest trading hours, with the old SSID configuration saved so you can roll back in minutes.

Test on at least four devices: a current iPhone, a current Android phone, a Windows laptop and a macOS laptop. Test every sign-in method you offer. Then leave the pilot running for 14 days before wave 1, because some faults only appear under real load.

Step 4: cut over in waves

Group sites so each wave reuses a configuration you have already proven. This decision matrix sets the order.

Site profile	Wave	Reason
Typical site, common hardware, close to IT	Pilot	Finds configuration faults at one site, not 30
Same controller or dashboard as the pilot	Wave 1	Proven template, lowest risk
Different hardware vendor	Own pilot, then next wave	Walled garden and RADIUS syntax differ by vendor
Seasonal or low-trade sites	Wave 1 or 2	Fewer visitors affected if a fault slips through
Flagship or highest-revenue sites	Final wave	Gets the most-proven configuration
Sites with event or peak dates inside the plan	Outside a 7-day buffer either side of the peak	No change freeze breach at your busiest moment

Keep each wave to a number your team can verify in one shift. A local contact should confirm the portal loads at every site before the wave is closed.

Worked scenario: a 30-hotel group

The figures below are a worked example, not a named deployment. A 30-hotel group runs guest WiFi on Cisco Meraki at 22 properties and HPE Aruba at eight. Its contract carries 90 days' notice. You can read more about the sector on our Hotels page.

What was done. The group chose "return" under Article 28 and served notice on day one. The export arrived in week two with 210,000 records. Of those, 31,000 had no consent timestamp and were imported into Purple Engage as non-marketable. The pilot ran at a 120-room Meraki hotel for 14 days. The remaining Meraki hotels moved in two waves of 10 and 11 using dashboard templates. The Aruba estate had its own pilot, then moved in one wave of seven.

Outcome. All 30 hotels were on the new portal by week seven. The longest interruption at any site was 12 minutes, inside an overnight change window. Daily sign-ins at the pilot matched the old provider's figures within 3%. The old contract ended with 40 days of overlap to spare.

How do you prove the new reports match the old ones?

Run both systems in parallel at the pilot

You cannot compare reports from two systems that never measured the same visitors. During the pilot fortnight, keep the old provider's dashboard live with exports enabled. Pull the same five measures from both systems for the same dates and site:

• Daily sign-ins.
• Unique visitors.
• New versus returning visitors.
• Average session length.
• Marketing opt-in rate.

Purple's WiFi Analytics reports these per site and across the estate. Session length depends on RADIUS accounting, so check accounting records are arriving before you trust that number.

Reconcile on definitions, not totals

Totals rarely match on day one, and that is not a fault in itself. Most gaps come from different definitions. One provider may count every device association as a visit. Another counts only authenticated sessions. One may merge sessions inside 30 minutes, another may not.

Write down each provider's definition, then compare like with like. Device privacy features also affect returning-visitor counts. Apple introduced private addresses in iOS 14, and Android randomises addresses by default from Android 10. A provider that identifies returning visitors by MAC address alone will report fewer returns than one that matches on sign-in identity.

Agree a tolerance before you start, for example 5% on daily sign-ins. Without a number agreed in advance, every gap becomes a debate.

Sign off before the notice period ends

Produce a one-page sign-off: the measures compared, each provider's definition, the gap and the explanation. Have IT, marketing and procurement sign it. Then take a final export of historic reports from the old provider, so year-on-year comparisons survive the switch.

Worked scenario: a 120-store retail chain

The figures below are a worked example, not a named deployment. A 120-store fashion chain runs Ruckus access points under a central controller. Group marketing needs year-on-year shopper visit trends to survive the switch. Our Retail page covers the sector in more detail.

What was done. The pilot store found that social login failed on Android devices. The walled garden held the portal domains but not the identity provider's sign-in domains. IT fixed this before wave 1. In parallel reporting, the old provider showed 18% more daily visits than Purple. The old provider counted every association. Purple counted authenticated sessions. Re-running the old export on authenticated sessions only closed the gap to 2%.

Outcome. All 120 stores moved in four weekly waves. No store lost guest WiFi during trading hours. The reconciliation was signed off at a 2% gap against an agreed 5% tolerance, three weeks before the old contract ended.

Which access point settings break most often during a captive portal migration?

Most failures trace back to a handful of settings. This table lists each one, the symptom and the fix.

Setting	Symptom when wrong	Fix
Walled garden missing new portal domains	Phone connects, portal never loads	Add every domain in Purple's vendor guide, then remove the old provider's
Walled garden missing social login domains	Email sign-in works, social login fails	Add the identity provider domains listed in the vendor guide
RADIUS shared secret mismatch	Sign-in accepted, device never gets online	Re-enter the secret on both the controller and the new server
RADIUS accounting disabled	Sign-ins appear, session length shows zero	Enable accounting (RFC 2866) with interim updates
Firewall blocking RADIUS ports	Sign-in times out at one site only	Allow outbound UDP 1812 and 1813, the ports assigned in RFC 2865 and RFC 2866
Site identifier mapped wrongly	Sessions appear against the wrong venue	Match the controller's site identifier to the Purple site ID
Old redirect left on one access point group	Half a site shows the old portal	Audit every SSID and access point group, not only the default
Session timeout copied from the old provider	Guests re-prompted mid-visit	Set timeout to your visit length; see How to Implement Time and Bandwidth Restrictions on Guest WiFi

Policies that lived inside the old provider

Some providers apply content filtering or bandwidth limits in their own cloud, not on your hardware. When you switch, those policies disappear silently. List every policy the old provider enforced and rebuild each one before cutover. Late-night venues face this most often, as Nightclub and late-night venue WiFi providers: content filtering, peak capacity and staff access explains.

Clock and certificate problems

RADIUS accounting and portal certificates both depend on correct time. A controller with a drifting clock produces session records that fall on the wrong day. Point every controller at a reliable NTP (Network Time Protocol) source before the pilot.

What does a switch cost, and what do you get back?

The cost lines to budget for

A switch on existing hardware has four cost lines, none of them hardware:

• Overlap licence. Plan to pay both providers for at least 30 days.
• IT time per site. Template-based dashboards cut this sharply after the pilot. Sites on standalone controllers take longer.
• Data cleansing. Someone has to map consent versions, de-duplicate records and load the suppression list.
• Local verification. A named person at each site checks the portal loads on the day.

Purple licenses through three plans: Connect, Capture and Engage. Procurement should price the plan you need against the overlap period, not against a full year from cutover.

What you get back

You keep the access points you already own, so no capital spend on hardware. You keep a marketing list you can lawfully email, because consent evidence travels with every record. You get one reporting model across every site, so estate-wide comparisons stop depending on which provider ran which venue.

You also join a platform proven at scale. Purple runs in 80,000+ venues across more than 90 countries and handles 500 million users and logins a year. Purple delivers 99.999% uptime, holds ISO 27001 certification and is GDPR compliant.

Frequently asked questions

Do we need new access points to switch guest WiFi provider to Purple?

No, Purple runs on the access points you already own. Purple is hardware-agnostic and works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The switch changes the captive portal, walled garden and RADIUS settings on your controller or dashboard. Your access points, cabling and switches stay in place, so a provider change is a configuration project, not a hardware refresh.

Can we keep emailing our existing guest list after we switch?

Yes, provided the consent evidence moves with the list. GDPR Article 7(1) requires you to demonstrate consent, so each record needs a timestamp, channel, capture site and the wording the visitor saw. Purple Engage imports consented records with that history attached. Records without evidence should be imported as non-marketable. Consent given to the old provider in its own name, rather than to your brand, does not transfer.

How long does a multi-site guest WiFi migration take?

Plan for six to eight weeks across most estates of 20 to 150 sites. That covers a two-week export, a 14-day pilot, and cutover waves sized to what your team can verify in one shift. Sites sharing a cloud dashboard move faster because one proven template applies to many. Start the plan from your old contract's notice date, leaving at least 30 days of overlap for parallel reporting.

Will our sites go offline during the cutover?

No, not if you follow the pilot-then-waves order. Each site changes during its quietest trading hours, with the old configuration saved for a rollback in minutes. Most interruptions last as long as the controller takes to push new settings. The faults that cause longer outages, such as missing walled garden domains or blocked RADIUS ports, are caught at the pilot site rather than across the estate.

Is moving guest data between providers GDPR compliant?

Yes, when you act as controller and both providers act as processors under contract. GDPR Article 28(3)(g) requires the old processor to return or delete personal data at the end of service, at your choice. Choose "return" in writing before serving notice. Carry the suppression list across first, so anyone who opted out stays opted out. Purple is GDPR compliant and ISO 27001 certified.

What happens to the data the old provider still holds?

The old provider must delete it once the service ends, if your contract follows GDPR Article 28. Ask for written confirmation of deletion after you have verified your export and completed the reporting sign-off. Take a final export of historic reports first, because year-on-year comparisons depend on that history. Keep the deletion confirmation with your records of processing in case a regulator or visitor asks.

How do we prove Purple's reports match our old provider's numbers?

Run both systems in parallel at the pilot site for 14 days and compare five measures: daily sign-ins, unique visitors, new versus returning, session length and opt-in rate. Most gaps come from different definitions of a visit, not faulty data. Document each provider's definition, agree a tolerance such as 5% in advance, and sign off before the old contract ends.

Can Purple connect to our existing CRM and email platform?

Yes, Purple integrates with CRM and marketing platforms. Imported guest profiles, new sign-ins and consent changes can flow to the system your marketing team already uses. Connect the integration before your first post-migration campaign, so unsubscribes from either side are honoured from the first send. This keeps one consent record across WiFi sign-in and email, which is what the ICO's consent guidance expects you to hold.