Moving UniFi Network off a Windows or Linux server and onto a CloudKey can simplify day-to-day administration. The important part is moving device management cleanly, with a usable backup and a way back if something goes wrong.
Start with the supported backup-and-restore process. Manual SSH commands are a troubleshooting option for devices that do not reconnect, rather than a compulsory step for every access point and switch.
For a business network, treat this as an IT infrastructure change: schedule it, document it and test the services people actually use.
Check the migration fits your equipment
This guide focuses on a single-site, self-hosted UniFi Network Server moving to a supported CloudKey running UniFi OS. Ubiquiti now also offers UniFi OS Server for self-hosting; identify which platform you have before choosing a backup method.
A CloudKey hosts management applications. It does not replace your router or firewall. Supported access points, switches and independently managed gateways can remain in place, subject to model and software compatibility. A Dream Machine or another UniFi Cloud Gateway already runs its own Network application and cannot simply be adopted into the CloudKey. See Ubiquiti’s hosting and gateway compatibility guidance.
If the source manages several sites, plan a supported site-by-site export/import workflow instead of assuming a whole-server restore suits every destination.
1 Prepare access, versions and a maintenance window
Before making changes:
- Record the source Network version, CloudKey model, device inventory and management addresses.
- Check that the destination supports the required Network release and your device workload. Older CloudKey hardware needs particular care.
- Bring the destination to a supported Network version at least as new as the source. Check release notes for any required upgrade steps; matching UniFi OS versions alone is not enough.
- Confirm administrator access and arrange onsite assistance if losing remote access would leave you stranded.
- Give the CloudKey a stable management address, such as a DHCP reservation, without creating an IP conflict.
- Record existing inform-host settings, controller DNS records and DHCP adoption options.
Avoid combining the move with unrelated VLAN, firewall or device-firmware changes. That makes failures easier to isolate. Application upgrades can reprovision devices, so review Ubiquiti’s release notes for your selected release before scheduling the work.
2 Save a fresh backup and recovery details
Download a Network backup, normally a .unf file, from the source application. Menu names vary by release: older versions use System > Backup, while current guidance refers to Control Plane > Backups.
Keep the original file and a second access-controlled copy. Treat backups as confidential configuration data; do not place them in a public share.
Also securely retain the adopted devices’ SSH credentials. Ubiquiti’s current location is UniFi Devices > Device Updates and Settings > Device SSH Settings. These are separate from the CloudKey console’s SSH settings and from your web sign-in. There is no need to enable console SSH just to restore a backup. See Ubiquiti’s SSH guidance.
3 Set up the CloudKey and restore
Connect and power the CloudKey using its model’s supported method. Complete its setup, update the required software and confirm you can reach its management interface.
Restore the .unf file through the destination’s supported backup interface. Ubiquiti currently documents Settings > Control Plane > Backups for this migration. Keep the existing network cabling unchanged.
After restoration, compare the imported site, device inventory, Wi-Fi networks and VLAN settings with your records. A Network backup is not a complete copy of the old server, other UniFi applications or every host-level customisation. Follow Ubiquiti’s backup and migration instructions for the installed versions.
4 Reconnect devices through the normal migration path
First allow devices to reconnect following restoration. If they come online correctly, per-device SSH is unnecessary.
Where devices still point to the old server, use the supported migration or inform-host controls. Ubiquiti documents setting Override Inform Host on the original Network application to the new host’s reachable address. Keep the source accessible for that handover, and review any DNS or DHCP adoption settings that would send devices back to it.
The CloudKey must be reachable from each device’s management network. Check TCP 8080 for device communication; discovery and other functions have additional requirements. Apply only the rules your topology needs, using Ubiquiti’s ports reference. Do not broadly expose management services to the internet to fix an adoption problem.
5 Use SSH only for devices that need it
If a supported access point or switch remains disconnected, first check its address, routing, DNS and firewall path. An experienced administrator can then use device SSH to correct its inform destination:
ssh <device-ssh-user>@<device-management-ip>On that device:
set-inform http://<cloudkey-reachable-address>:8080/informReplace every placeholder before running the command. Use an address the device can reach, and check model-specific instructions for gateways or devices with different SSH support.
TCP port 8080 is part of the inform URL. The command runs on the affected device, not on the CloudKey. Some devices may need it repeated after appearing in Network. Follow Ubiquiti’s device adoption guidance; investigate errors rather than repeatedly resetting equipment.
6 Verify service before retiring the source
A green device icon is only the start. Compare the expected and connected device counts, then test:
- Staff and guest Wi-Fi, including new client connections
- DHCP, DNS, internet access and VLAN separation
- Business applications, printers and phones
- Gateway, VPN, RADIUS or guest-portal functions used at the site
- Authorised local and remote administration
Allow time for provisioning and investigation rather than promising a five-minute migration. If internet access fails, check the wider network too. Osmicro’s firewall outage example shows why healthy-looking equipment is not enough to confirm service.
Once management and services are stable, stop the old Network instance and prevent unintended restarts. Use the method appropriate to its installation; it may be an application, service or container.
Keep a practical rollback path
Retain the source installation and pre-change backup until the migration is accepted. Do not erase the old host or factory-reset devices as routine cleanup.
If rollback is needed, stop the new management instance, restore the original inform/DNS settings as required and bring the original host back deliberately. Devices already redirected may need their inform destination returned too. Avoid competing configuration changes from both hosts.
Finally, take a fresh destination backup, check ongoing backup arrangements and update the network documentation. For help planning the move and maintaining the result, explore Osmicro’s managed IT services.