UniFi Adoption, Migration and Closeout Runbook
UniFi equipment may be reachable on the network yet remain tied to another console, wait for adoption, or receive configuration that does not match the site. TechRunz verifies console ownership, backup and migration method, Layer 2 or Layer 3 adoption requirements and the final operational handoff before devices are reset or moved.
Make each dispatch repeatable and recoverable
Define prerequisites, remote ownership, method of procedure, acceptance evidence and rollback before technicians arrive onsite.
Ownership, backup and adoption planning
Identify the existing console, destination console, owner account, site, Network application version and installed device models. Verify that the client has authorized access before resetting, removing or transferring equipment. A reset without source ownership or a current backup can turn a routine migration into a rebuild.
Create and protect the appropriate backup or use the current supported migration process. Record VLANs, networks, SSIDs, authentication, switch profiles, static addresses, VPNs, port forwards, identity dependencies and third-party services. Confirm version compatibility before restoring data to a different console.
Adoption work hinges on account facts, so the field instructions should state which console the devices currently answer to, the owner account that will hold them, the backup that exists, and the destination site. Onsite, match serials to planned positions and flag anything already adopted elsewhere instead of resetting it.
- Authorized source and destination
- Current protected backup
- Version and migration compatibility
- Adoption network prerequisites
Device installation, adoption and migration
Map each gateway, switch and access point serial to its location, uplink, switch port and power source. Confirm Layer 2 discovery or the approved Layer 3 adoption path, required DNS/DHCP behavior and firewall reachability before dispatch.
Install and adopt devices in a controlled sequence that preserves management. Wait for provisioning and reboots to finish, and watch for adoption loops, duplicate IP addresses, isolated devices or unexpected factory defaults. Do not repeatedly reset a device before the remote owner reviews its actual state.
The riskiest steps in a migration are the ones that cannot be photographed, so write down the console version, the backup file used and the restore point before the first device is touched. Leave the source console running until the new one holds the fleet, and note each device that needed a manual set-inform.
- Serial and physical mapping
- Controlled adoption sequence
- Provisioning and reboot hold points
- Remote escalation before reset
| Area | Acceptance check | Evidence |
|---|---|---|
| Ownership | Correct console, site and administrators | Console inventory |
| Adoption | Connected, provisioned and correctly named | Device status record |
| Service | Gateway, switching, Wi-Fi and applications | Representative tests |
| Recovery | Backup, update policy and rollback ownership | Protected handoff record |
Network, wireless and recovery validation
Validate gateway addressing, internet, routes, VLANs, DHCP, DNS, NAT, VPN and required inbound services. Check switch trunks, native VLANs, profiles, spanning tree, negotiated links and PoE. Test every required SSID with representative clients for authentication, addressing and applications.
Exercise the approved gateway, uplink or power recovery scenario when redundancy is part of the design. Confirm that all devices return to connected state and that alerts, topology and client history are useful. Apply updates only under the approved policy after release-note and backup review.
Sign-off should show the console listing devices as connected with their expected firmware, next to client-side results from each SSID and VLAN a user will touch. Capture topology and uplink assignments as they settled, not as designed. Report adoption failures with the device MAC, the console version and what the LED was doing.
- Gateway, VLAN and DNS tests
- Trunk, profile and PoE checks
- SSID and representative clients
- Approved recovery scenarios
Closeout, access and lifecycle ownership
Reconcile console inventory, names, sites, firmware, switch ports, AP positions and client networks with the field worksheet. Record offline or pending devices, temporary profiles, failed updates and any hardware that remains owned by a prior console.
Transfer ownership to named client administrators, enable strong account protection and document backup, update and alert responsibilities. Store recovery material and credentials in the client repository. The public project record should contain official help links, not exported backups or controller secrets.
Hand over the things a rebuild would need and a screenshot cannot give: the console owner account, where backups are written and on what schedule, the firmware policy chosen, and which devices are still pending or offline. Keep the backup files and recovery codes client side and point the public record at official guides.
- Console and field reconciliation
- Offline and temporary conditions
- Protected access and backups
- Named update and alert ownership
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Confirm ownership
Identify which console holds each device today and who can release it before any reset is considered.
Back up first
Capture the current Network application backup and note its version so restore paths stay open.
Adopt and migrate
Install devices, adopt them on the correct console and apply site configuration using the required adoption method.
Validate and transfer
Confirm wireless behavior, failover and recovery, then move console access to the named owner with them watching.
Information to gather before design
Adoption depends on console ownership, application version and reachability between device and controller, so those answers belong in hand before anything is reset.
- Console holding each device today
- Network application version and backup file
- Controller reachability across site subnets
- Named owner for console access
- Existing SSIDs and VLAN assignments
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Should a UniFi device be factory-reset when adoption fails?
Only after verifying ownership, network reachability, inform state and recovery. An unnecessary reset can erase useful configuration or complicate migration.
Can a backup from any Network application version be restored?
Compatibility varies. Review the current Ubiquiti migration guidance and test the supported path before the maintenance window.
What causes Layer 3 adoption problems?
Routing, DNS or DHCP options, inform settings, firewalls, NAT, prior ownership and version compatibility are common factors.
What is required at closeout?
Correct ownership, complete inventory, network and client tests, backup and update policy, exceptions, recovery information and named administrators.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Migrating UniFi sites to your own console
Who owns the console these devices answer to now, and where should they answer after the move? Send the site list, application version, backup status and the access arrangement you want at handover.