ARTICLE
Hybrid cloud is not a compromise between public and private cloud: it is a decision-making framework that enables organizations to allocate each workload to the most appropriate environment, optimizing TCO (Total Cost of Ownership) and the speed of innovation. In this article, we analyze the objective criteria for workload placement, the correct calculation of Total Cost of Ownership, and the principles of hybrid governance that distinguish a mature architecture from one that is simply complex.
Why is hybrid cloud at the center of the IT agenda in 2026-2027?
According to the Politecnico di Milano Observatory “Cloud Ecosystem & Sovereignity”, Italian companies’ planned investment in Cloud for 2026 is around 35%, confirming Cloud as the main platform for technological innovation. This figure reflects not only an acceleration in investment, but also growing architectural complexity: more workloads in the cloud means more decisions to make, more costs to govern, and more interdependent variables to keep under control.
In this scenario, the hybrid cloud model is emerging as a structured response to a very specific question: where is it really most convenient to run each workload? This is not an ideological choice between public and private cloud, but rather a methodological approach that requires clear criteria, comprehensive cost analysis, and a consistent governance model.
Organizations that adopt hybrid cloud in a mature way do not simply distribute workloads across multiple environments: they define explicit rules for doing so, update them over time, and measure them against business KPIs. Those that do not end up with two parallel infrastructures to manage, without the benefits of either.
The decision-making framework for workload placement
Not all workloads are equivalent, and treating them in the same way is the main cause of inefficient architectures. A structured framework for workload placement begins with the analysis of four objective variables.
1. Workload variability
Workloads with stable and predictable consumption benefit from the unit economics of on-premise infrastructure or private cloud. By contrast, applications subject to unpredictable spikes, marketing campaigns, seasonal batch processing, and e-commerce systems benefit from the elasticity of the public cloud, which makes it possible to scale without over-provisioning. Workload variability is the first key factor in making a rational placement decision.
2. Security and compliance requirements
Regulatory constraints (FADP, GDPR, NIS2, DORA, PCI-DSS, and sector-specific regulations such as those issued by FINMA), together with data residency requirements, may require certain data or applications to remain within controlled environments or specific geographic regions.
These constraints must be treated as real architectural requirements, not preferences. At the same time, compliance and data sovereignty do not automatically mean avoiding the public cloud: many providers now offer Swiss and European regions, certifications, and specific controls to meet even stringent requirements.
3. Latency and application dependencies
Applications that require sub-millisecond latency, such as industrial control systems and real-time processing at the edge, or that have close dependencies on legacy on-premise systems, are not always ideal candidates for an immediate migration to the public cloud.
Mapping application dependencies is a prerequisite for any placement decision: moving a workload without considering its interdependencies can introduce unexpected latency or require a complete re-architecture.
4. Total cost over time (Total Cost of Ownership, TCO)
Cost is often the determining factor in infrastructure decisions, but it is also the hardest to calculate correctly. An incomplete or asymmetric TCO leads to poor decisions, whether in favor of the cloud or on-premise. The next section explores this point in detail.
TCO calculation: correctly comparing public and private cloud
The most common mistake in infrastructure analysis is an asymmetric comparison. Cloud provider cost estimates — compute, storage, licenses — are added together and compared with the apparent cost of on-premise infrastructure, often already depreciated. The result is a comparison between apples and oranges, not between two truly comparable options.
A correct TCO analysis for the public cloud includes:
- Compute, storage, and networking costs, including outbound data transfer costs, which are often underestimated.
- Software licenses and enterprise support costs.
- Skills and training costs required to manage the cloud environment accurately.
- Initial migration and re-architecture costs.
For on-premise:
- Hardware refresh every 3–5 years and disposal costs.
- Energy, cooling, and physical space, such as data centers or co-location.
- Specialized staff for infrastructure management.
- High operations costs: patching, monitoring, and disaster recovery.
- The cost of accumulated technical debt and missed innovation opportunities.
Only with a complete and symmetrical TCO can placement decisions become accurate and sustainable over time. In many cases, this analysis restores the public cloud as the more cost-effective choice even for workloads traditionally considered “better suited to on-premise”, not because it is always cheaper in the short term, but because it eliminates hidden costs and frees internal resources from low-value activities.
Hybrid cloud as a governance choice, not a compromise
Defining your model as “hybrid” without an explicit governance strategy simply means having two separate infrastructures to manage. The difference between a well-designed hybrid cloud and a poorly managed one does not lie in the technology adopted, but in the decisions that govern it.
A mature hybrid model requires:
- Unified identity and access policies (Identity and Access Management, IAM) across all environments, to eliminate security silos.
- Centralized observability: metrics, logs, and tracing must be aggregated regardless of where the workload runs.
- Consistent security and patching procedures that do not vary according to the target environment.
- Teams with hybrid skills, capable of working effectively across both cloud and on-premise environments.
- A periodic placement review process: conditions change, and the right decision today may no longer be right in 18 months.
Who decides where each workload runs, based on which criteria, and how frequently the decision is reviewed: these three questions define the maturity of a hybrid model. Without clear answers, hybrid cloud is not a strategy, but architectural debt.
Public cloud as the starting point, not the exception
For most workloads, the public cloud should represent the starting point of the evaluation. The advantage is not only economic: it is above all the ability to quickly access managed services, AI and machine learning, fully managed databases, integrated security, and advanced observability tools.
Keeping a workload on-premise that could be moved to the cloud often means giving up some of this speed of innovation and continuing to bear operational costs that could be reduced.
The decision-making framework and TCO analysis therefore primarily serve to identify the exceptions: workloads that, for concrete reasons of latency, compliance, legacy constraints, or technical dependencies, require a different placement. These constraints must be specific, documented, and reassessed over time.
The questions every CTO and IT architect should ask periodically are: Which workloads could I make more efficient or modernize by moving them to the public cloud? What constraints prevent me from doing so, and are they truly insurmountable? What security risks am I accepting by keeping obsolete systems on-premise? What are the real operations costs I could eliminate by adopting fully managed services?
Operational takeaways
Adopting a rigorous decision-making framework for workload distribution is necessary, but not sufficient if it is not accompanied by a clear strategic vision. The public cloud should be the starting point for every architectural decision. On-premise remains the right answer in cases where there are real constraints related to compliance, latency, or security that justify it. Not as the default, but as a documented exception.
These are the operational takeaways:
- Classify workloads using objective criteria (workload variability, compliance, latency, application dependencies) before making any placement decision. A “cloud first” or “on-prem first” approach without proper analysis inevitably leads to inefficiencies.
- Build a symmetrical TCO model that compares all costs, including hidden on-premise costs (refresh, energy, staff, operations) and often underestimated cloud costs (data transfer, training, migration). Only complete data leads to sound decisions.
- Treat constraints to public cloud adoption as exceptions that must be documented and reduced over time. Organizations that govern this transition methodically gain a real competitive advantage: faster innovation, less infrastructure to maintain, and greater focus on the product and core business.