Emergency SectorsCareers About us Blog Get in touch
NLNederlandsENEnglish
Network cabinet in a branch with a switch and an access point

Cloud-managed sites: when it fits, and when it does not

Bringing a branch online without anybody having to be there sounds like the answer to every multi-site problem. For a share of cases it is. This is where the line runs.

Updated August 2026 7 min read Written by the ITproposal team
Short answer

Cloud-managed networking is the right choice when you have many small, similar sites and no technical people at any of them. You ship a device, somebody plugs it in, and the configuration arrives from the cloud.

It is the wrong choice when you have one large building with complex requirements, when your environment is not allowed to talk outward, or when the licensing model does not suit you: with Meraki the device stops working when the licence expires.

We deploy it where it fits and say so when it does not. Both happen.

The problem it solves

An organisation with twenty sites and one network engineer does not have a technical problem, it has a travel problem. Every change that has to happen on site costs a day: out, do it, back. Every fault that needs somebody present takes as long as the drive there.

Cloud-managed networking removes the drive. The device pulls its configuration from a management environment you open from anywhere, and that environment is the same for every site. Bringing a new site online then means: ship the device, somebody plugs in power and the internet connection, and the rest happens remotely.

That is not a small gain. For a branch organisation the difference between “we will send somebody tomorrow” and “I am doing it now” is the difference between a day of trading and half an hour of inconvenience.

When it fits

Cloud-managed networking comes into its own when three things are true at once.

  • Many sites that resemble each other. Twenty shops with the same layout are the same configuration twenty times. One template, twenty devices. With three sites that are all different, that gain is not there.
  • No technical people on site. If every location has somebody who can configure a switch, you are paying for convenience you already had.
  • Management has to be handover-ready. One console showing everything is easier to hand over than twenty devices each with their own password.

The sector where this is true most often is retail, followed by hospitality groups with several venues and care organisations with small sites spread across a region.

When it does not fit

There are three situations where we advise against it, and we do that even when it would mean work for us.

  • One large building with its own requirements. A head office or a production site often has configurations that do not fit a template. At that point you are working against the product.
  • The environment may not talk outward. With cloud management the management plane sits outside your building. In an environment where that is not allowed — some industrial networks, some regulated estates — it is out, full stop.
  • The licensing model does not suit you. With Meraki the licence is not a service subscription but a condition: when it expires, the device stops. That is a deliberate choice by the manufacturer and it is manageable, but you have to know it before you buy rather than after.

In those cases we look at equipment you manage yourself. Fortinet where the firewall is the centre of gravity, Juniper for larger campus and datacentre switching, Ubiquiti where your own controller and predictable licensing matter more than remote management.

Where the cost sits

We do not put figures on this site, but the structure belongs here, because that is where the surprises are.

With cloud-managed equipment you pay for two things: the device and the licence attached to it. The second runs for as long as the device is in use. Compare that with equipment you buy once and the first option looks more expensive. Compare it with equipment you buy once plus the travel time of somebody visiting twenty sites once a quarter, and it tips.

That calculation depends on the number of locations, the distance between them and how often something has to happen. We do it with you, on your numbers, and we show it rather than reading a conclusion out of it.

The dependency you take on

Cloud management means your management plane sits with a manufacturer. That has two consequences you should weigh in advance.

The first is that you do not leave that manufacturer easily. The devices do not work with another vendor’s console. Switching means replacing hardware, and that is not an investment you want to make every three years.

The second is that your traffic keeps running when the management environment is unreachable. That is by design in this class of equipment: the configuration sits locally, the cloud is for management rather than for carrying traffic. That is an important distinction, and it is why we do put this kind of network into sites that cannot go down.

We name that dependency before anything is ordered. A choice you cannot explain in five years is not a good choice, even if it works today.

How we set it up

When we deploy this, we do it in this order.

  • One site first, then the rest. A template proven at one location is a template. A template that works on paper is an assumption.
  • Traffic separated from the start. Guests, staff and card payments do not belong on the same network. Separating afterwards is work; up front it is a checkbox.
  • Monitoring that reports itself. You hear about a site being down from the system, not from the branch manager.
  • Documentation that is yours. Passwords, licences and the setup are in your name. If management ever moves to somebody else, it comes with you.

How we design and manage a network across several locations sits under managed network.

Frequently asked

Questions we get about this

The ones that come up most often when this is on the table.

Does my site keep working if the connection to the management environment drops?

Yes. The configuration sits on the device itself; the cloud is for management rather than for carrying traffic. You cannot make changes during such an outage, but traffic on site keeps running. That is exactly why we also put this class of equipment into sites that cannot go down.

What happens when the licence expires?

With Meraki the device stops working. That differs from most vendors, where an expired licence only means no more updates. We monitor the end dates and flag them well in advance, but it matters that you know this before you choose rather than after.

Can you manage this if it is already installed?

Yes, and that is a large part of our work. We take over an existing estate, map what is there and what deviates from the template, and clean that up at a pace your business can absorb. Replacing things because we are used to another brand is not something we do.

Is this worth it for three sites?

Usually not. The gain from cloud management is in repetition, and with three locations that are all different there is barely any. There are cheaper ways to reach the same result. We say so even when you ask for it yourself.

Related services

Where this lands with us

The services this subject sits under.

Want to know whether this fits your sites?

Name the number of locations, how different they are and who currently drives out when something happens. That is enough to do the calculation.