Migrating a multi-site UniFi controller to UniFi OS Server

The case for migrating is less about a single feature than about trajectory. Ubiquiti’s own self-hosting documentation already recommends running UniFi Network on a dedicated console compatible with UniFi OS, citing the compatibility risks of third-party hardware and software.² Beyond that, the practitioners and hosting providers who track Ubiquiti’s release notes describe the standalone Network application as having entered maintenance mode: it continues to receive security patches and bug fixes, but new functionality — Site Magic, Teleport VPN, UniFi Identity, Fabrics — is being built only for UniFi OS, and Ubiquiti now points users toward UniFi OS Server when it publishes new releases.¹⁰¹¹

That makes staying on the standalone application a slowly-depreciating position rather than a stable one. There is no announced end-of-life and no deadline forcing your hand this quarter — but the direction is unambiguous, and the question for a multi-site operator is when and how to move, not whether. The rest of this article assumes you have accepted that and want to do it well.

The data move is genuinely straightforward, and for small estates it is close to trivial. The shape of it:³⁹

1. Back up properly first. From the existing Network Server, download a server-wide backup (.unf) at Settings → Control Plane → Backups (a settings-only backup is enough; add a short historical backup if you want the data). Snapshot the old VM too, so you can roll back if anything goes sideways.
2. Stand up UniFi OS Server and restore. Install UniFi OS Server, complete the setup wizard without restoring inside the wizard, launch the Network application, then restore the .unf at Settings → System → Backups. Sites, devices and clients re-appear within a few minutes.
3. Get the devices to re-adopt. If the new host resolves at the same hostname the devices already inform to, they re-adopt automatically — no per-device set-inform. Otherwise use Override Inform Host on the old controller, a DHCP option-43 entry, or a bulk SSH script to point devices at the new address.³¹⁰ A device that still shows Managed by Another Console after the restore is factory-reset and re-adopted (the fallback the docs give when the restore itself doesn’t reclaim it).³

The traps are operational, not conceptual: close the old Network Server before installing UniFi OS Server; reach the new Network application on 11443, and note captive portals now serve on 8444 (changed from 8843); and do not clone the UniFi OS Server VM except for genuine high-availability, because cloned VMs share the same Site Manager and Fabrics tokens and will behave unpredictably.¹ Sizing is modest — a 4-vCPU, 4–8 GB, 40 GB-plus SSD VM comfortably carries around fifty small-to-mid sites, scaled up with device count.⁹

One honest field note before you assume it is painless at scale: small two-site migrations via backup-and-restore “just work,” and larger multi-site restores generally do too — but this path is not officially blessed for large multi-site deployments, and the reports include real wrinkles, the most important of which is the subject of the next section.⁸ Keep the old controller running as a fallback until you have verified every site.

Here is the migration’s sharpest edge, and it is the reason some MSPs have paused the move. An operator running roughly fifty sites who migrated from the classic Network controller to UniFi OS reported that the fundamentals of user and site administration feel unfinished — and the specific failure is per-site admin assignment.⁷ When you add a user and grant them access to one site, the role picker is a long, scrolling list of roles that are not clearly tied to a site name; “Site Admin” appears multiple times with no visible site context, so you scroll and guess which entry maps to the site you actually want.⁷ At fifty sites that is slow and error-prone. And it is not an isolated gripe: in a separate community report, operators who moved their sites onto a self-hosted UniFi OS Server found that admins could initially only be scoped to the Default site — not every migrated site showed up under Admins to assign against.¹⁸

A workaround circulates in the same community discussion, and it is exactly as unintuitive as it sounds: in the scrolling list, the correct site-scoped Site Admin entry is the one sitting directly above the clearly-labelled Hotspot Operator for [site name] entry — the Site Admin line itself just omits the site name.⁷ Pick that one and the admin is scoped to that single site. The cleaner route is to add admins from Site Manager at unifi.ui.com — People → New Admin, select one or multiple sites, and assign per-application permissions, with a Site Specific option to differ them per site.⁵

For a single-site shop, none of this matters. For an MSP, per-site admin scoping is the whole game — it is the difference between giving a client (or a regional technician) access to their site and accidentally handing them global access to every client you run. The classic controller did per-site assignment by default; the transition made it clumsy.¹² That is the gap to plan around — and the reason to do the next section before you migrate anything important.

The durable point — the one that survives whatever Ubiquiti does to the per-site list next month — is that Ubiquiti is not trying to perfect per-site hand-assignment. It is moving multi-site access onto a different construct: UniFi Fabrics.

A Fabric lets you define roles once, at the Fabric level, and apply them consistently across all applicable sites, instead of assigning access site by site.⁴⁶ Admin permissions within a Fabric range from full administrative access through view-only to granular, application-specific permissions; roles are created once and bound to a chosen set of sites; and people can be added manually or — the part that matters most for an MSP — synchronised from an identity provider over SCIM, with SAML authentication, so onboarding and offboarding a technician becomes a change in your IdP rather than a manual sweep across fifty consoles.⁶ Above the Fabric sits the Organization, the higher-level grouping that UniFi OS Server supports.¹ UniFi’s documentation now frames Fabric-level management as the way to scale administrative access without duplicating configuration per site.⁵⁶

The implication for the migration decision is the one most teams miss: moving to UniFi OS Server is not merely “lift and shift the controller.” It is an invitation to re-platform your access model onto Fabrics and, ideally, your identity provider. Done deliberately that is more powerful than the old per-site model — define once, sync from your IdP, offboard cleanly — but it is a genuinely different mental model with real setup, and it will not feel like the per-site admin assignment you are used to. Plan for the Fabric model; do not expect to recreate fifty ad-hoc Site Admins by hand and have it feel the same. And because the raw per-site UI was rough in early 2026 while this model was still landing, treat the current state as something to pilot and verify, not to take on faith — including from this article.

“Migrate to UniFi OS Server” quietly assumes self-hosting is the right destination. For an MSP, it often is not the only sensible one. There are three places the modern UniFi OS experience can live:¹²

• Self-hosted UniFi OS Server — licence-free, you own the VM and everything on it.
• Official UniFi Hosting — functionally the same, run in Ubiquiti’s cloud on a subscription, with Ubiquiti owning uptime and OS patching.
• A hardware console or CloudKey Enterprise — an on-premise appliance, optimised by Ubiquiti to run UniFi Network and (on full consoles) the other applications.

The security reality should weigh heavily here, and it is the same argument we make in our management-plane hardening guide. A self-hosted UniFi OS Server is an internet-facing management plane, and UniFi OS itself was squarely in the 2026 CVE streak — the May and June advisories named UniFi OS Server among the affected products, fixed in specific releases you are responsible for applying.¹⁴¹⁶¹⁷ Self-managed means you patch it the day a CVSS-10 advisory drops, you keep it off the open internet, and you segment, back up and monitor it. Official UniFi Hosting trades a subscription for offloading that operational burden. It is no accident that some managed hosts argue, bluntly, that MSPs should not self-host controllers for client networks at all — that uptime and security are too consequential to do by hand.¹³ That view is self-interested, since those companies sell hosting, but the underlying point about operational ownership is sound.

So the calculus for a multi-site operator is honest and specific: self-host UniFi OS Server if you have the operational maturity to run a hardened, patched, monitored, backed-up management plane and you want zero per-controller cost. Otherwise, Official UniFi Hosting — or a managed host such as HostiFi — buys you someone else owning uptime and OS patching for a predictable fee.¹¹

The data restore is the part you have already seen is easy. The discipline is everything around it.

1. Inventory — including the access map. Record the controller and Network versions, the UI account that holds Owner, SSH credentials, site count and device count — and, crucially, your current admin-to-site map: who has access to which sites today. You cannot rebuild access cleanly if you never wrote down what it was.
2. Choose the destination first. Self-hosted UniFi OS Server, Official UniFi Hosting, or hardware — decide using §06 before you touch anything, because it changes the rest of the plan.
3. Pilot on a copy, and test admin scoping. Stand up a non-production UniFi OS Server, restore a backup, and assign an admin to a single client site before you migrate the fleet. This is where the RBAC reality bites; confirm you can scope an admin to one site — via Site Manager → People, or via a Fabric — before it is your clients’ access on the line.
4. Design the access model up front. If you are adopting Fabrics or an IdP, lay out the roles and (where used) the SCIM/SAML mapping now. Do not plan to recreate fifty Site Admins by hand under time pressure.
5. Migrate the data. Backup .unf → install UniFi OS Server → restore → re-adopt (same-host or Override Inform Host), reaching the new app on 11443. Keep the old controller as a fallback and verify every site’s devices and admins reappear.
6. Re-establish access deliberately. Rebuild and verify per-site or Fabric roles; confirm each client and technician sees only their own sites; remove any “just give them global for now” shortcuts before they calcify.
7. Harden before you expose. MFA on every account, a segmented management VLAN, no WAN port-forward, and patched to current UniFi OS — the full posture from our hardening guide.¹⁴
8. Decommission the old controller once everything is verified — forget the migrated devices on the old side, or remove it entirely.

• The per-site admin UI is a moving target. The “messy scrolling list” reports are from early 2026, and Ubiquiti is actively building the Fabric and Organization model around exactly this problem — so the raw experience may be materially better by the time you read this.⁷⁶ Pilot and verify against the current build; bet on the model shift, not on the bug.
• “Maintenance mode” is a characterisation, not an official EOL. Ubiquiti still ships security and bug fixes for the standalone Network application and has announced no end date. The trajectory (new features only on UniFi OS) is clear; there is no deadline forcing the move today.¹⁰¹¹
• UniFi OS Server is Network-only. If your service depends on Protect cameras or Access door control on the same box, UniFi OS Server will not host them — that requires a hardware console.¹
• Large multi-site backup-and-restore works but is not officially blessed for scale. Reports are positive for many operators yet include the per-site admin-scoping quirks covered above; treat a big migration as a tested, scheduled maintenance event, not a casual restore.⁸⁷¹⁸
• Self-hosting is an operational commitment, not a free lunch. You own uptime, OS patching of an actively-targeted management plane, backups and security. If that is not a fit, the subscription options exist for a reason.¹³¹⁴
• Provider perspectives are self-interested. The hosting companies cited here sell hosting and migration; their facts hold up, but weigh the “don’t self-host” advice against your own operational maturity rather than taking it at face value.¹³
• Do not strand yourself or your clients. Keep a known-good Owner account and a tested management path throughout. The fastest way to turn a migration into an outage is to lose scoped admin access to fifty client sites at once.

None of this changes the headline. UniFi OS Server is where Ubiquiti is taking self-hosted UniFi, the data migration is a backup-and-restore that mostly takes care of itself, and the real work — the work that decides whether the move is smooth or a fortnight of cleanup — is rebuilding multi-site administration on the new model before you cut over, not after.