Cloud or on-prem: what actually makes sense for an SME

Today the reflexive answer is "put everything in the cloud". For a startup with no infrastructure team and loads that vary unpredictably, it is often the right one. But for the typical Italian SME - predictable load, sensitive data, a defined budget - the cloud default deserves to be questioned: not because cloud is wrong, but because the decision is almost always made on the least relevant factors. Let me state my position up front: for small companies I tend to prefer self-host. But it is a case-by-case judgment, and what follows is the framework to make it with the facts in hand - regulations, real costs and documented cases included.

The cost that grows: egress and per-seat

Cloud looks cheap at the start, and that is where the misjudgment hides: the costs that really weigh are the ones that grow over time and rarely make it into the initial budget. The first is egress: the major providers charge for outbound traffic - the cost of moving your own data off their infrastructure - a line item that grows with volume and that effectively discourages even backing up elsewhere. The second is per-seat: every SaaS at a fixed price per user per month, multiplied by your headcount and the number of tools adopted, becomes a recurring expense that rises in lockstep with the company's growth.

This is not theory. In 2022 37signals - the company behind Basecamp and HEY - publicly announced its exit from the cloud, documenting the migration to its own hardware: a one-time outlay reported at around 600,000 dollars in servers and an estimated saving of over a million dollars a year, roughly seven million over five years. Years earlier Dropbox had taken a similar path, moving its storage off AWS onto its own infrastructure (the "Magic Pocket" project) and reporting, in its stock-market filing, savings on the order of 75 million dollars. These are large companies with enormous, predictable workloads: the figure does not transfer automatically to an SME. But the principle is clear - beyond a certain load stability, owning the infrastructure costs less than renting it. On-prem requires a larger upfront investment (the hardware), but at steady state it is predictable, and for many organizations that steady-state predictability beats "I only pay for what I use".

Where your data lives: sovereignty and GDPR

It is the most underrated aspect in Italy, and for many companies it is the one that ends the discussion. "Cloud" means, literally, data on someone else's computer - often in another jurisdiction - and that opens a concrete legal problem, not an ideological one.

Two sets of rules collide. On one side the GDPR, which restricts transfers of personal data outside the European Union. On the other the US CLOUD Act of 2018, which lets US authorities compel an American provider to hand over the data it holds regardless of where it is physically stored - even if it sits in a European data center. The two do not reconcile easily, and that is the heart of the Schrems II case: in 2020 the Court of Justice of the European Union invalidated Privacy Shield, the agreement that governed EU-US data transfers, precisely because European data was insufficiently protected from US surveillance. It did not stay theoretical: in 2022 the Italian Data Protection Authority (Garante) - in line with the Austrian and French authorities - ruled the use of Google Analytics non-compliant, because it transferred personal data to the United States without adequate safeguards.

The industry's response confirms how serious the matter is: the European Gaia-X initiative for a sovereign data infrastructure, and the "sovereign" offerings announced by the hyperscalers themselves (Microsoft's EU Data Boundary, AWS's European Sovereign Cloud), exist precisely to answer this need. For an SME handling client, health or financial data, the question is sharp: where does my data physically reside, and which authority can legally compel access to it? Keeping the data in-house, or on EU-sovereign infrastructure, provides a verifiable answer. It is not paranoia: it is due diligence.

Lock-in: a dependency built one service at a time

The cloud ties you in through managed services, proprietary APIs and formats that exist only on that platform, with egress acting as an exit cost. Migrating off a deep cloud stack is expensive, and not by accident: the difficulty of leaving is part of the business model. The more you lean on the provider's specific services, the less free you are to switch. Open source and portable infrastructure keep that leverage in your own hands. It is the same reasoning as build vs buy, applied to infrastructure: every managed service is convenience today and dependency tomorrow.

Latency, control and the network dependency

For certain workloads - local line-of-business apps, production systems, the point of sale - on-prem gives low latency and availability that do not depend on the internet line. The cloud adds a hard dependency: if connectivity drops, operations drop. And there is control: you see the machine, you touch it, you know where it is. For a company that cannot afford to stop when the fiber goes down, that is a concrete factor.

When the cloud is the right choice instead

It would be dishonest to paint the cloud as the adversary. The cloud is the right answer when you lack the staff to run the infrastructure - and above all the continuity to maintain it over time (the same "3 AM problem" from build vs buy): it is better to pay someone who handles it than to end up with a server nobody knows how to administer anymore. It is the right choice when the load is variable, because pay-as-you-go beats hardware sitting idle most of the time; when you need to scale quickly or reach global markets; and when you want certified compliance and geo-redundant disaster recovery ready to use, hard to replicate on a single on-site server. The rule stands: don't run in-house what you are not able to run.

The third way: hybrid architecture and professional self-host

Almost no SME is entirely cloud or entirely on-prem: the realistic balance point is hybrid. You keep close - on-site or on EU-sovereign infrastructure - what is sensitive and steady, and entrust to the cloud what is variable, commodity, or meant for disaster recovery. One misconception needs clearing up, though: "self-host" today does not mean a server forgotten in a closet, but a small infrastructure run with discipline - virtualization, containers, verified backups, monitoring.

It is the principle the platforms I develop are designed around. Presidio, the XDR platform I built, is deliberately self-hosted: a client's security data - logs, alerts, indicators of compromise - stays under their control and on their infrastructure, without passing through a third-party platform and without a cost that grows with every endpoint added. For a product that collects an organization's most sensitive information, data sovereignty is not an incidental detail: it is a design requirement.

A checklist to decide

• How sensitive is the data? The more regulated, the more sovereignty tilts toward keeping it close.
• Is the load predictable or spiky? Steady → on-prem pays off; spiky → cloud.
• Do you have someone to run the box, with continuity? If not, the cloud is more honest.
• What is the 3-year TCO? Count egress and per-seat at your real user count, not the starting price.
• How much does leaving hurt? Measure lock-in before you go in, not after.
• Is connectivity a single point of failure? If stopping is unacceptable, consider on-prem.

The takeaway

"Cloud or on-prem" is not an identity to embrace once and for all: it is the problem of placing each workload where it belongs. My position, for a small Italian company, remains the one stated at the outset: keep close what is sensitive and steady, entrust to the cloud what is variable and commodity. Don't choose the cloud out of inertia, nor on-prem on principle, but weigh each workload by what it truly costs - in money, in regulatory risk, and in the real ability to run it over time.