Managing a 50-location network: why it is not 50 separate projects

When a company runs five sales outlets or production sites, IT problems get solved "by phone call": something breaks, somebody on site reboots, reinstalls, reconnects. At fifty locations this model stops scaling. What stops working isn't individual printers — it's the very ability to manage the infrastructure.

We see this regularly: a business grows from 5 locations to 30, then to 50, and at some point the infrastructure starts consuming as many resources as the core operation. Not because there are too many locations — but because they are being supported as 50 unrelated projects.

Symptoms of "50 projects instead of one network"

They are easy to check. If you answer "yes" to at least three — that's exactly your situation:

• Each location has its own contractor or "the person who knows", and nobody remembers who set up the router at location 17.
• Opening a new location takes 3–6 weeks not because of walls and equipment, but because of "configuring IT for the new place".
• When the admin password needs to change — it takes a sprint, not a day. And somewhere the old one survives anyway.
• Incidents happen "out of nowhere": the cashier notices the POS or the network is down, and calls the office. The admin learns about it from the cashier.
• Backups exist, but nobody remembers when restore was last tested. On most locations — never.
• Licences and equipment are bought twice because nobody tracks where things went when a previous location closed.
• An auditor or security team asks about access policies — there is no answer.

None of these are "issues with a particular site" — they are issues with the model. The locations look the same; the infrastructure underneath each is unique.

Why "50 projects" falls apart at scale

It isn't about quantity. It's about three systemic effects that show up specifically past 15–20 locations.

1. Configuration drift

Ten locations, opened at different times by different people, mean ten slightly different configurations. By location eleven, the engineer can't remember what "right" was, and copies the closest one. Two years later you have 50 unique snowflakes — similar, but not identical. Any mass operation — antivirus update, certificate replacement, VPN key rotation — turns into a separate micro-project for every site.

2. No observability

50 disconnected sites are 50 black boxes. You don't know what is happening inside them until something breaks badly enough that a user complains. Without centralised monitoring it is impossible to see trends: that the disk on location 23 is filling faster than usual, that VPN on location 41 flickers once a week, that the UPS on location 7 switches to battery every Tuesday at 14:00.

3. Diffused responsibility

If every site has its own contractor, then every IT incident gets the same response: "not us". POS isn't working — that's the vendor's software. Network is slow — that's the ISP. Printer won't print — that's the printer supplier. Effectively, only the business owner is responsible for the chain end-to-end, while each individual provider covers a narrow strip.

What belongs at the centre, not on the site

The basic principle is centralised by default, local where required. On a site, only what must continue working when connectivity to the office is lost should remain. Everything else — into the shared infrastructure.

At the centre — without exceptions

• User accounts and access rights. One source of truth (Active Directory, Microsoft Entra ID, or an equivalent). When an employee leaves, access is revoked once and disappears everywhere. Local site administrators are the main source of "eternal" accounts that belong to people who left long ago.
• Monitoring and alerting. One Zabbix / Grafana / Prometheus that sees every site. Alerts go to a duty rotation, not to a chat with a cashier.
• Backups and a recovery plan. Backups happen against a single policy and end up in one verifiable location. Recovery is rehearsed on a schedule, not "when something breaks".
• Configuration templates. Workstation image, baseline router config, GPOs, antivirus policy — all driven by templates, not "as I remember".
• Logs and audit. All site logs collected centrally. Without this, investigating an incident at location 34 from three weeks ago is impossible.
• Endpoint management. A single MDM / SCCM that knows which laptop is where, who uses it, and which patches are installed.
• Network policies. Wi-Fi controllers, VPN concentrators, firewalls all managed centrally — otherwise during a security incident you'll be applying the same change by hand 50 times.

Local — only what must work offline

• POS and retail software cache, so receipts can still be printed during a connectivity outage.
• Local DHCP/DNS — a site shouldn't go down because the office link dropped.
• Video recorder — records locally; metadata and clips travel up.
• Backup connectivity (LTE/4G) with automatic failover.

How to move from "50 projects" to "one network" without stopping the business

This is not "rewrite everything from scratch". It is a phased migration, typically 4–9 months for a fleet of 50 locations, depending on the starting state.

1. Inventory. Before centralising anything, you need to know what you actually have. Every device, every link, every licence, every local "person who knows". 2–4 weeks of fieldwork for 50 sites.
2. Pick and stand up the central core. AD/Entra, monitoring, backup server, MDM, VPN concentrator. Built in parallel with the existing operation.
3. Reference configuration on one site. A pilot on 1–2 locations: the new workstation image, the new network, connection to the central monitoring and backup. The pilot ships 90% of the future problems.
4. Migration in waves. 5 sites a week is a realistic pace. Each wave ends with a short retrospective and an update to the reference.
5. Decommission the old. The most-forgotten step. Old VPNs, old accounts, old rented services — turn them off, otherwise they'll live for years and you'll keep paying for them for years too.

What changes in numbers

On real projects (anonymously — figures from our experience in retail networks, hospitality and logistics sites), moving to the centralised model usually delivers:

• Opening a new location drops from 4–6 weeks to 3–7 days for the IT part.
• Incident response time drops from "when a user notices" to 5–15 minutes (alert fires, someone picks it up).
• IT support spend drops by 25–40% by removing duplicate contractors and licences.
• Restoring from backup goes from "we never tried" to "we run drills quarterly".
• Security audits and compliance (Moldova Law 195/2024, GDPR for foreign clients) stop being last-minute fire drills and become routine.

Self-check: where are you today

Print this and walk your fleet. If the answer is "no" for more than 10% of your sites on any item — you are running the "50 projects" model.

• No site has local administrator accounts that live outside the corporate directory.
• Anyone who left the company last quarter has had access revoked across every site automatically.
• I can see the state of every site in one query: which are online, which were backed up today, which have less than 20% free space.
• The most recent location's backup has been restored to a test bench within the last 90 days.
• Opening location 51 takes no more than 5 working days for IT.
• Any network policy (e.g. blocking a domain) can be applied across the entire fleet within a single day.
• If an IT incident happens out of hours at one site, the on-duty engineer in the office hears about it — not the staff member at that site.

Frequently asked questions

What if our sites are in different jurisdictions — say Moldova and Romania?

This is not an obstacle to centralisation. Local data-residency rules are accommodated when choosing platforms (some data may stay in local data centres), but management and monitoring are still built as a single system.

Isn't standing up our own core more expensive than leaving things as they are?

Over 6–12 months — yes, an investment is required. Over 2 years a centralised model is almost always cheaper because of removed duplicate contracts, faster site openings, and fewer IT incidents reaching customers.

What about data that legally has to stay in country?

Architecturally this is solved by choosing the location for the data and separating "control plane / data plane": management can stay central, data can sit on the required territory. In Moldova this is particularly relevant for Law No. 133/2011 and personal-data handling.

We're small — only 12 sites. Is this too early for us?

Symptoms appear at around 15–20 locations. But if you plan to grow, putting the "as a network" model in place is cheapest at 8–15 sites — while it can still be reversed without large migrations.