MDU Consolidation Has a Plumbing Problem

MDU Consolidation Has a Plumbing Problem

2 minutes and a half read time

Contribution by Magnus Johansson is the co-founder and CEO of WiBUZ

A companion to Maravedis' three-part series on the consolidation of MDU connectivity.

Maravedis named the real test. Its three-part series makes the case that MDU consolidation won't be won by door count. It will be won by the operators who can turn the networks, vendors, tools, tickets, billing, and support workflows they acquire into one coherent operating model. Part 3 says it plainly: buying doors is easy; stitching them together is not.

I build that operating layer for a living, so here is the operator's answer to the test Adlane diagnosed.

The gap isn't the radio

The radios are the visible part. The gap is underneath: provisioning, authentication, billing, monitoring, ticketing, resident portals, support history, and the workflows that tie them together. A roll-up can cross 100,000 doors by acquiring three operators, one on Ruckus, one on Cambium, and one on OpenWiFi, each with its own billing, ticketing, and portal, and still be running five companies under one logo.

WiBUZ is not buying doors

We are not another consolidator, nor another hardware bet. We build the layer above a mixed infrastructure that lets operators run different vendors, tools, and workflows through a single model. It is capability consolidation that is needed, but cannot be easily built into every roll-up.

Single-vendor standardization still has a place until you acquire

In a roll-up, standardizing on one vendor turns every off-standard acquisition into a migration: a multi-year project in occupied buildings, where every resident notices an outage. You can standardize by replacing hardware or by standardizing the operating model above the hardware. The second approach is the one that scales across a mixed estate.

The method

Integrate each vendor into a shared model once, where an access point, an SSID, a client, an event, a ticket, and a payment all mean the same thing regardless of brand. Build each workflow once on top of that model. Then the next vendor, property, or acquisition does not restart the integration project from zero.

That is what shrinks the migration from a custom build into mostly repeatable configuration and validation. Cap the inherited stacks, grow every new site on a single layer, then retire the old stacks on your schedule by repointing them to a model that is already running. Cap, grow, retire. Every integration becomes a reusable asset instead of a tax that compounds with each deal.

On cost: AI-assisted development has changed the economics of building and maintaining that layer. The comparison is no longer one vendor versus an expensive in-house science project. It is one operating layer versus five parallel operations.

Where the proof is

We are not asking the market to believe a whiteboard. wibipOS already runs national, multi-vendor, multi-subsystem networks across education and hospitality. The education rollout is in its final phase across more than 760 schools, with roughly 10,000 managed network elements, including access points, switches, firewalls, and ticketing systems. The operating problem there is the same one consolidation creates: provision users, normalize controllers, manage identity, monitor service, connect support workflows, and keep a small team in control of a large footprint. We have mapped new controllers, including Mist, Cambium, Meraki, Fortinet, and NetExperience, into the common model in days rather than months, with production hardening following the validation discipline any operator would expect.

MDU has its own workflows, but the underlying control-plane problem is the same: vendors, identity, monitoring, tickets, payments, and portals. That pattern is already running in production.

The question owners should actually ask

Not "how many doors do you run?" Ask "What happens operationally after your next acquisition?" Fast onboarding is evidence that the abstraction layer already exists. A long migration often means the acquisition is still being forced into the old operating model.

The market is consolidating exactly the way Maravedis describes. Larger will not automatically mean integrated. A door count can hide five controller stacks, five billing flows, and five teams. Who wins will not be decided by who buys the most doors. It will be decided by who can run what they bought as one system.


Read the Maravedis series on MDU consolidation: Part 1, Part 2, Part 3.

Magnus Johansson is co-founder and CEO of WiBUZ, the maker of wibipOS, a vendor-agnostic, API-first control plane that lets operators run mixed connectivity estates on a single model, proven in production across education and hospitality.

 

Back to blog

Leave a comment

Please note, comments need to be approved before they are published.