Leaving Unifi

In 2018, UniFi still had a strong pull for homelab and small-network people. The gear was approachable, the controller software was familiar, and the product line made it possible to build something better than consumer networking without jumping straight into enterprise pricing.

That was exactly why the direction change bothered me.

UniFi had been attractive because it felt like an open, locally managed network platform. You could run the controller yourself, own the configuration, and treat the hardware as part of a network you controlled. Over time, the center of gravity started moving away from that model.

Cloud Encumbrance

The first problem was the growing pressure toward cloud-connected management. Remote access can be useful, but it is different when cloud attachment starts feeling like the preferred path instead of an optional convenience.

For a home lab, local control matters. The network should not depend on a vendor account, a hosted service, or a product direction that can change faster than the hardware lifecycle. If the controller is local, the network should remain understandable and manageable locally.

That was the standard I wanted to preserve.

The Dream Machine Shift

The release of the Dream Machine line made the direction clearer. Instead of controller software being something you could run independently, UniFi seemed to be steering users toward appliance-based control tied to specific hardware.

For some customers, that packaging made sense. It simplified buying and support. For me, it looked like the beginning of a tighter vertical stack: gateway, controller, switching, wireless, cameras, phones, door access, and more, all encouraged to live inside one vendor’s ecosystem.

The concern was not that Ubiquiti wanted to sell more products. The concern was that the network platform was starting to feel less like flexible infrastructure and more like a bundled small-business appliance strategy.

The Meraki Pattern

At the time, it felt like UniFi was trying to chase the small and midsize business market by copying some of the worst instincts of Cisco Meraki: more cloud gravity, more appliance packaging, more ecosystem pressure, and less interest in users who wanted local control without vertical lock-in.

Meraki works for organizations that want that model and accept the tradeoffs. I did not want those tradeoffs in the lab. I wanted switching, wireless, routing, and controller visibility without feeling pushed into phones, video, door security, or a vendor-managed operating model.

The network needed to stay a network, not become a subscription-shaped product universe.

Why Omada Made Sense

TP-Link Omada looked like the natural successor for the parts of UniFi that had originally been useful: centralized network management, approachable pricing, capable switching, solid access points, and a controller model that still fit local operation.

Omada was not exciting in the marketing sense, and that was part of the appeal. It felt like network equipment first. The controller managed the network. The switches switched. The access points handled Wi-Fi. The gateway routed. That division of responsibility was exactly what I wanted.

The goal was not to find a brand to be loyal to. The goal was to avoid a platform that was becoming harder to separate from the vendor’s broader ecosystem ambitions.

The Lesson

The lesson from leaving UniFi was that homelab decisions are not only about features. Product direction matters. Management model matters. Whether a vendor is making local control easier or harder matters.

A good lab platform should let the operator keep learning, testing, replacing, and integrating. It should not turn every future network choice into a referendum on whether to buy deeper into the same vendor stack.

That is why the lab moved toward Omada. It kept the parts I wanted from UniFi while avoiding the vertical lock-in I had no interest in carrying forward.