Choosing between a hyperscaler and an on-premises data center is not a fundamental strategic decision. It is a downstream consequence of architectural choices. Only once it is determined which systems can be operated, migrated, or replaced regardless of location, and which functions must remain available on-site, can you make a sensible decision about which infrastructure to source them from.

The platform alone creates no value. A hyperscaler can provide computing power on demand, automate services, and scale capacity flexibly. However, these benefits only materialize if applications and operational processes are designed to leverage them. The 2024 Accelerate State of DevOps Report by DORA and Google Cloud reaches a clear conclusion: flexible cloud infrastructure can improve organizational performance. Conversely, a cloud migration that fails to utilize this flexibility can be more detrimental than remaining in a traditional data center.

Simply moving an existing server to a different infrastructure does not create an adaptable architecture. Dependencies, rigid capacities, and inflexible operational processes remain. Furthermore, new requirements for network connectivity, identity management, and the control of distributed services arise. In this case, the cloud is merely a different location for the same design.

Commercial lock-in is losing its significance

For a long time, the primary argument against cloud platforms was vendor lock-in. Switching was considered expensive, contractually difficult, or unattractive due to high fees. The European Data Act addresses exactly these obstacles.

The regulation has been in effect since September 12, 2025. Providers of data processing services must remove barriers to switching to another provider or returning to their own infrastructure. During the transition period, they may only charge costs directly related to the switch. As of January 12, 2027, switching fees are completely prohibited under Article 29(1). According to the Federal Network Agency, these rules regarding provider switching under the Data Act apply to both new and existing contracts.

This does not mean all forms of dependency disappear. However, the decisive lock-in will increasingly lie where it has technically always been: in your own architecture. Applications can be tied to proprietary databases, identity services, interfaces, or automation. Data may be exportable, but the associated application might not run on another platform without significant re-engineering. A legally possible provider switch is therefore not yet a technically simple one.

The central question, therefore, is not which provider appears to be the right long-term platform today. It is whether the environment is built in such a way that services can be replaced, moved, or operated in parallel temporarily. Those who do not plan for this portability create the strongest form of lock-in themselves.

The provider debate is a false dilemma

If applications are portable, interfaces are documented, and data is available in usable formats, the infrastructure provider becomes a mere source of supply. A function can then be provided by a hyperscaler, a traditional data center, or a local environment. The deciding factor remains whether performance, availability, security, and the operating model fit the specific process.

Operational practice shows that migrations are far from being one-way streets. Systems move from traditional data centers to hyperscalers, between different hyperscalers, or back to a data center. Hyperscalers are particularly suitable where capacities need to be changed on short notice. In our experience, their cost level is often higher than that of static infrastructure. This is not a universal cost comparison, but a reason to purchase scalability only where it is actually used.

The same applies to the comparison between central and local servers. A central environment reduces hardware at individual locations and simplifies maintenance and updates. At the same time, dependency on network connections increases; the central platform can become a single point of failure, and latency directly impacts normal operations. Local systems offer short access paths and can keep a site operational during connection outages. In return, data must be synchronized, hardware must be maintained in multiple locations, and changes must be rolled out in a distributed manner.

None of these variants is the right one in isolation. The architecture must determine which dependency is acceptable for the respective process.

Hybrid emerges from the operational remainder

The boundary between central and local infrastructure is most evident during a line failure. Everything that must continue to function on-site constitutes the local remainder. This does not arise from a preference for proprietary hardware, but from the operational process and from regulatory or technical constraints.

In medical practices, this remainder is clearly visible. The version of the KBV IT security directive to be implemented as of October 2025 includes requirements for cloud services for the first time. At the same time, the requirements from Annex 5 apply to decentralized components of the telematics infrastructure, regardless of practice size. On its information page, the KBV specifically mentions card terminals and connectors as components that are located in the practice and must be protected.

Annex 5 requires, among other things, the protection of these components against unauthorized physical access, the securing of the connection to a hosted connector via a VPN tunnel, and the secure storage of administrative data. It thus explicitly regulates an infrastructure that remains at least partially physically or functionally tied to the location.

Card readers, connectors or TI gateways, and the associated authentication means are therefore not an argument against central platforms. They mark the gap that a purely central architecture cannot close. Above this local remainder, applications, data processing, and central services can move to where they are most sensibly operated. The prerequisite is that a connection failure does not uncontrollably shut down the entire site.

Hybrid is therefore not a half-hearted compromise between the cloud and an on-premises data center. It is the consequence of a clean separation: what is physically bound or required for autonomous site operation remains local; central functions are sourced where operation, scaling, and interchangeability best align.

The robust decision is therefore not "hyperscaler or data center." It is: which functions must remain available on-site, which may depend on the connection, and how can we prevent a platform from becoming technically indispensable? Once that is answered, the source of supply follows from the architecture.

‍

FAQ: Hyperscalers vs. on-premises data centers

Does portability mean that every application must be movable at any time?

No. Full portability is not economically or technically feasible for every application. The key is to choose dependencies consciously, document data access and interfaces, and establish a realistic migration path for business-critical services.

Does the Data Act make switching providers automatically easy?

No. The Data Act reduces contractual and financial barriers and mandates that providers support switching processes. However, it does not eliminate self-imposed technical dependencies within an application or operating architecture.

Is a hybrid architecture inherently more resilient?

Not automatically. While it can limit the impact of a network or platform failure, it also increases the number of transitions, systems, and synchronization processes. Resilience is only achieved when it is clearly defined which functions must continue to run locally, what data is required for this, and how subsequent reconciliation will occur.

When is a hyperscaler worth it?

A hyperscaler is particularly useful when its flexibility is actually leveraged—for example, for fluctuating capacity, automated provisioning, or rapidly changing services. If, however, you are simply moving a static server environment, the expected benefits may not materialize; the 2024 DORA report specifically warns against this type of migration that fails to utilize cloud flexibility.

What question should be answered before any infrastructure decision?

First, you must determine what needs to remain functional if the site connection fails. This operational baseline dictates the necessary local components; only then should you consider whether to use a data center, a hyperscaler, or a combination of both for the remaining functions.

‍

‍