On-Premises Server or Cloud: A Decision Without Dogma

Why This Should Not Be a Matter of Faith

Hardly any IT decision in mid-sized businesses is debated as emotionally as this one: do the servers belong in your own building or in the cloud? On one side stands the sentence “My data stays with me”, on the other “The cloud is the future”. Both sentences sound like conviction, but in truth they are gut feeling. And gut feeling is a poor basis for a decision that will shape your ability to operate for years.

A quick clarification of terms: a server in your own building, known in the trade as on-premises, is hardware that you own, that sits in your rooms and that is operated by you or your service provider. Cloud means that you rent computing power, storage or complete applications from a provider’s data center and use them over the internet. In between lie intermediate forms, such as a server you own that is housed in a rented data center.

The honest answer to the question is almost always: it depends. Not on worldview, but on four sober criteria. What data do you process? How good is your internet connection? What does operation really cost, on both sides? And what happens in an outage? This article works through these criteria one by one.

What Data You Have and What You Are Allowed to Do With It

The first step is taking stock of your data, often called a data inventory. Not all data is equal. Personal data, meaning anything that can be linked to an individual, is subject to the Datenschutz-Grundverordnung (the EU General Data Protection Regulation, GDPR). Trade secrets such as costings, engineering data or customer lists are positioned differently in legal terms, but are often even more sensitive commercially. And a large share of the data in any business is simply uncritical: product photos, published documents, marketing material.

Relevant for the cloud question: as soon as a service provider processes personal data on your behalf, the GDPR requires a Vertrag zur Auftragsverarbeitung (a data processing agreement), that is, a written contract regulating what the provider may do with the data and how it protects it. Reputable cloud providers offer such contracts as standard. You should also check where the data is actually stored. With providers headquartered or operating servers outside the European Union, the question of third-country transfers arises, meaning the legal basis for transferring data to countries without a European level of data protection. That is not an automatic exclusion criterion, but it is a point you should not leave unexamined.

Important for perspective: data protection is not an argument that speaks against the cloud across the board. It is a criterion you go through per data type. A business can run its email infrastructure with a European provider and at the same time decide that engineering data never leaves the building. Exactly this differentiation is the core of a good decision.

The Internet Connection: Lifeline or Bottleneck

If you move applications to the cloud, your internet line becomes the most important infrastructure in the building. Three properties matter: bandwidth, meaning how much data per second fits through the line, latency, meaning the delay between request and response, and availability, meaning how often and for how long the line fails. A line can be fast on paper and still feel sluggish if latency is high.

Checking honestly means measuring real-world performance during normal operations, not the advertised maximum, and asking yourself what happens if the line goes down for a day. If nobody can work in that case, you need a second, independent connection before any cloud migration, for example through a different provider or over mobile networks. This redundancy, meaning the duplication of a critical component, is mandatory rather than optional once central applications run externally.

The reverse conclusion does not hold, however. A server in your own building does not make you independent of the internet either. Email, updates, remote access for home offices, connections to branch locations: all of that runs over the line anyway. The difference lies in the degree of dependence. With a local server, employees in the building can often keep working during a line outage; with a pure cloud setup, they usually cannot. How much this difference weighs depends on how much of your value creation takes place in the building.

Running Costs: Calculate Both Sides Honestly

The classic miscalculation with your own server: only the purchase is considered. A complete calculation includes depreciation of the hardware over its useful life, power and cooling, maintenance contracts and spare parts, an uninterruptible power supply, meaning a battery system that bridges short power outages, the backup infrastructure, the space required including a lockable room, and above all the working hours for administration, updates, and troubleshooting. Add to that the replacement cycle: server hardware is usually replaced after a few years, and that amount belongs in the calculation from the start.

The classic miscalculation with the cloud: only the monthly fee is considered. A complete calculation adds licenses, which in the cloud are often charged per user per month instead of once, costs for data transfer, especially for outgoing data, which some providers bill separately, growing storage costs, because data volumes practically never shrink, a stronger and redundantly designed internet connection, and continuing administration effort. Because cloud environments do not configure, monitor, and secure themselves either.

You should know two structural differences. First: with your own server, the costs sit mainly in tied-up capital and staff time; with the cloud, in ongoing usage fees that the provider can adjust. Price increases hit you there directly, without any short-term way to sidestep them. Second: cloud costs grow with usage. That is an advantage if your demand fluctuates, and a disadvantage if it rises steadily. Calculate both options over a period of about five years with all the cost types mentioned, otherwise you are comparing apples with oranges.

When Things Fail: Two Worlds, Two Failure Patterns

If the server in your building fails, the typical causes are hardware defects, power outages, water or fire damage, theft, or ransomware, meaning malicious software that renders your data unusable and demands payment. Recovery is entirely your responsibility: you need replacement hardware, working and tested backups, and someone who can bring the two together. The decisive questions are: how quickly can you get spare parts or a replacement device, and when was the restore last rehearsed?

If the cloud fails, the picture looks different: a disruption at the provider, an outage of your internet line, a locked account, or a misconfiguration on your side. The uncomfortable part: during a provider disruption, there is nothing you can do except wait and watch the status page. Availability commitments are set out in the service level agreement, SLA for short, the contractual assurance of how much downtime may occur at most. In practice, breached commitments usually mean credits on the monthly invoice, not compensation for your lost revenue.

One rule applies in both worlds: backups are your job. Cloud providers work on the principle of shared responsibility: the provider secures the operation of the platform, while you remain responsible for your data and its backup. Anyone who has experienced accidentally deleted files, a compromised account or a faulty bulk import quickly notices that the cloud itself is not a backup. Plan an independent data backup for every application, no matter where it runs.

Hybrid: The Most Common Honest Answer

In practice, the decision in mid-sized businesses rarely comes down to an either-or. The most common result of a sober analysis is a hybrid environment, meaning a deliberate split: standardized services such as email, calendars, and video conferencing run in the cloud because they are needed from everywhere and are laborious to operate yourself. Applications with a local focus stay in the building, for example an inventory management system with attached label printers, a production control system, or large engineering files that are opened daily from local workstations.

A proven pattern is also backing up across both worlds: the local server additionally backs up to the cloud so that a fire or theft does not hit the original and the backup at the same time. Conversely, cloud data is regularly backed up to local storage to stay independent of the provider. In this way, the hybrid environment uses the strengths of both worlds where they actually lie.

The downside should not be concealed: hybrid means two worlds that both have to be secured, updated, and monitored, plus managing user accounts across both. Hybrid is therefore not an end in itself, and not an excuse to keep every legacy system in the basement running. It is the result of an assignment per application, not the convenient middle path taken to avoid the decision.

Typical Misjudgments and a Five-Step Approach

Misjudgments in favor of the cloud: “We won’t have to take care of anything anymore” underestimates that configuration, user management, permission assignment and data backup remain your job. “The cloud is automatically secure” confuses the security of the platform with the security of your usage: weak passwords and missing two-factor authentication, meaning confirming a sign-in via a second device, are just as dangerous in the cloud as in the building, only easier to attack remotely.

Misjudgments in favor of your own server: “Data is safer in the building” is only true if patch levels, access protection and backups reach a level comparable to a professionally operated data center. An outdated server behind an office door is not more secure than the cloud; it only feels that way. “But it’s still running” ignores that a single old server is a single point of failure, meaning a component whose failure shuts everything down. And “the cloud is out of the question because of data protection” is just as wrong as a blanket judgment as its opposite.

The approach itself is not rocket science. First: data inventory. What data do you have, how sensitive is it? Second: application list. Which programs does the business use, who accesses them from where, how long can each application be down? Third: measure the connection and mentally play through a line outage. Fourth: calculate both operating models over five years with all cost types. Fifth: decide for each application individually, not for the whole company at once.

You can handle the first three steps internally; they mainly require honesty and a few hours of time. For the cost comparison, the evaluation of providers, and at the latest for the migration, meaning the orderly move of data and applications, external experience makes sense. Because that is where the expensive mistakes happen: incomplete moves, forgotten dependencies between applications, and backups that were never tested.