Here is something the cloud marketing materials will not tell you.
Many companies that rushed to the cloud between 2020 and 2023 are now moving workloads back. Not all of them. But enough that “cloud repatriation” became a boardroom topic in 2024 and 2025.
The reason? Cloud costs can spiral when you scale. What looked cheap at 10,000 transactions per day becomes expensive at 10 million. Especially for stable, predictable workloads where you are paying cloud margins on capacity you could own outright.
At the same time, companies that stayed on-premise face new compliance demands. DORA in Europe. Proposed HIPAA Security Rule updates in the US. Both push toward capabilities that older infrastructure may not deliver without upgrades.
So what actually makes sense in 2026? This guide breaks it down.
The Cloud Cost Reality
Cloud pricing is simple when you are small. You pay for what you use. No hardware. No data center. Just a monthly bill.
The problem starts when your usage grows and stabilizes.
At high, stable utilization, fully-loaded on-premise or co-location can be cheaper. This is especially true when you commit to 1 to 3 year steady-state capacity. But the comparison is not as simple as “cloud bill vs. server lease.”
True cost comparison requires Total Cost of Ownership (TCO):
• People (operations, security, on-call)
• Security tooling and compliance implementation
• Resiliency and redundancy setup
• Data center costs (power, cooling, physical security)
• Hardware refresh cycles and depreciation
• Licensing (OS, databases, monitoring)
• Network connectivity and data transfer
Many cloud repatriation stories skip these details. They compare a cloud bill to a hardware quote and declare savings. In reality, the math depends on your specific situation: workload patterns, team capabilities, compliance requirements, and time horizon.
The key variable is workload stability. If your workload is predictable (same volume, same patterns, month after month), owned infrastructure often costs less over 3 to 5 years. If your workload spikes and drops, cloud economics still win because you only pay for peaks when they happen.
The Hidden Cost Drivers in Cloud
Two costs catch FinTech and HealthTech teams off guard:
Data egress and inter-region traffic. Moving data out of the cloud or between availability zones adds up fast. A platform that processes high transaction volumes or syncs data across regions can see egress charges exceed compute costs.
Multi-region resiliency. Regulators increasingly expect geographic redundancy. Running active-active across two regions roughly doubles your cloud spend. On-premise, this means two data centers. Neither is cheap, but the cloud version scales with usage while on-premise is fixed.
DORA: What It Actually Requires
The Digital Operational Resilience Act applies from 17 January 2025 across the EU. If you operate in financial services in Europe, it covers you.
Here is what DORA actually demands:
• A complete inventory of all your ICT providers (cloud, software, APIs)
• Risk assessments for each provider
• Incident reporting to regulators within defined timelines
• Regular resilience testing (threat-led penetration testing for significant entities)
• Documented exit strategies for critical vendors
• Concentration risk management
That last point matters most for cloud decisions.
DORA does not say “use cloud” or “avoid cloud.” It says: if you rely on a cloud provider, you must prove you can exit if needed. You must show you are not over-reliant on any single vendor.
AWS, Google Cloud, and Microsoft (Azure) are among the Critical Third-Party Providers (CTPPs) designated by the European Supervisory Authorities in November 2025. The list includes other providers and will be updated over time. Designation means regulators directly oversee these providers. It also means using them creates concentration risk that you must document and actively manage.
The misconception: “Moving to AWS makes us DORA compliant.”
The reality: Moving to AWS creates new compliance obligations under DORA. You need exit plans. You need multi-vendor strategies or documented justification for concentration. You need to prove portability.
What “Exit Strategy” Actually Means
Auditors expect specific artifacts, not vague statements about portability:
• Data portability plan: How you extract your data, in what format, within what timeframe
• Contract clauses: Termination rights, data return obligations, transition assistance
• Tested runbooks: Actual procedures to migrate away, exercised periodically
• RTO/RPO targets: Recovery time and recovery point objectives for transition scenarios
• Alternative provider assessment: Documented evaluation of where you would go
This does not mean cloud is wrong. It means cloud is not a compliance shortcut. The compliance work happens regardless of where your servers sit.
HIPAA: What Is Actually Changing
The US Department of Health and Human Services published a Notice of Proposed Rulemaking (NPRM) to update the HIPAA Security Rule in December 2024. This is a proposal, not a final rule. Changes are subject to revision before any final rule is issued, likely in late 2025 or 2026.
The proposal would strengthen requirements around:
• Encryption (moving toward mandatory rather than “addressable”)
• Multi-factor authentication for remote access to PHI
• Risk analysis documentation and frequency
• Network segmentation (specifics depend on final rule language)
• Incident response documentation
The details matter. “Mandatory encryption for all ePHI” is a simplification. The final rule will define scope, exceptions, and implementation timelines. Watch the HHS Office for Civil Rights (OCR) for official guidance.
Breach Notification: Clearing Up Confusion
You may have heard about a “24-hour notification requirement.” Here is what that actually refers to:
The federal HIPAA Breach Notification Rule requires Business Associates to notify Covered Entities “without unreasonable delay” and no later than 60 days after discovering a breach. Many organizations use contractual SLAs of 24 to 72 hours for this BA-to-CE notification, but that is contract-driven, not a federal HIPAA mandate.
Some state laws impose stricter timelines. Your contracts may as well. But do not confuse contractual or state requirements with federal HIPAA.
For infrastructure decisions, the key point: both cloud and on-premise can meet HIPAA requirements. Neither does it automatically. Compliance is about how you configure, document, and operate your systems.
The Shared Responsibility Model
Cloud providers will sign a Business Associate Agreement for HIPAA. They hold SOC 2, ISO 27001, and other certifications. This does not make you compliant.
Under the shared responsibility model:
The provider is responsible for: physical security of data centers, hypervisor security, network infrastructure, and the security of managed services at the platform level.
You are responsible for: access controls, encryption configuration, network security groups, logging and monitoring, patch management for your applications, identity management, data classification, and compliance documentation.
A misconfigured S3 bucket is your breach, not AWS’s. A database without encryption at rest is your compliance gap, not Azure’s. Cloud provider compliance covers their layer. Your layer is still yours.
When Cloud Makes Sense
Cloud wins in specific situations. Not all situations.
Variable workloads
If your traffic spikes and drops, cloud makes sense. You pay for peaks only when they happen. On-premise means buying hardware for your maximum load, then watching it sit idle most of the time.
New products and experiments
Building something new? Cloud lets you spin up infrastructure in hours rather than weeks. If the product fails, you shut it down with no hardware to sell.
Geographic expansion
Need to serve customers in a new region with data residency requirements? Cloud providers offer access to compliant regions within days. Setting up on-premise in a new country takes months.
Small teams without infrastructure expertise
If you have five engineers and none of them know how to manage servers, cloud managed services make sense. The alternative is hiring infrastructure specialists you might not need full-time.
Early-stage companies preserving capital
Startups usually benefit from cloud. Speed matters more than optimization. Cash is tight. Teams are small. Cloud lets you move fast without capital expenditure on hardware.
When On-Premise or Co-location Wins
On-premise (or co-location in a data center) wins in other situations.
High-volume, stable workloads
A payment processor handling millions of transactions daily with predictable patterns will often pay less on dedicated hardware over a 3 to 5 year horizon. The math depends on your specific volumes, but at high stable utilization, cloud margins add up.
Ultra-low latency requirements
Trading platforms and real-time payment systems where sub-millisecond determinism matters typically require venue-adjacent co-location. Cloud with dedicated connectivity (Direct Connect, ExpressRoute) can achieve low millisecond latency for many use cases. But for sub-millisecond consistency to exchanges or payment networks, co-location remains the standard.
Strict data control requirements
Some contracts and regulations require data to never leave your physical control. Government work, defense-adjacent projects, and certain healthcare scenarios fall here.
Long planning horizons with existing infrastructure
If you already own hardware, have a trained team, and plan to operate for 5+ years with similar workloads, the TCO often favors staying on-premise. Just make sure you are comparing full costs, not hardware vs. cloud bill.
The Hybrid Reality in
Most companies in regulated industries end up with a mix. Not because “hybrid” sounds good in a strategy deck, but because different workloads have different requirements.
A common pattern in 2026:
• Core transaction processing: On-premise or private cloud (cost control, latency)
• Customer-facing applications: Public cloud with CDN (global reach, burst scaling)
• Analytics and reporting: Public cloud (burst capacity, managed services)
• Development and testing: Public cloud (spin up and down as needed)
• Disaster recovery: Multi-region public cloud (geographic redundancy)
This is not about picking a winner. It is about matching infrastructure to workload requirements.
A Note on Platform Lock-in
Self-managed Kubernetes on cloud can erase expected savings. Managed services (RDS, DynamoDB, BigQuery) can create lock-in that complicates your DORA exit strategy.
Consider this when designing your architecture. The convenience of managed services comes with switching costs. Document those costs as part of your exit planning.
The Migration Reality Check
“Lift and shift” migrations rarely deliver the promised savings.
Taking an application built for on-premise servers and running it on cloud VMs usually costs more, not less. You get cloud prices without cloud benefits.
To actually realize cloud economics, you typically need to re-architect applications. That means rewriting code. Moving to serverless or containers. Adopting managed databases. This takes months or years, not weeks.
Budget accordingly. A migration project that promises instant savings is probably underestimating the work required.
Realistic timelines:
• Assessment and planning: 4 to 8 weeks
• Pilot migration (non-critical systems): 2 to 3 months
• Core system migration with re-architecture: 6 to 18 months
• Optimization and cost tuning: Ongoing
A Decision Framework That Actually Helps
Forget “cloud-first” or “on-premise-first.” Start with workload-first.
For each workload, ask:
1. Is the load predictable or variable? Stable high-volume favors owned infrastructure. Variable favors cloud.
2. What are the latency requirements? Sub-millisecond determinism needs co-location. Low-ms tolerant applications work on cloud with dedicated connectivity.
3. What is the data egress profile? High outbound data transfer inflates cloud costs significantly.
4. What compliance applies? Map specific requirements. Check if cloud providers meet them and what your responsibilities remain.
5. What is your 3 to 5 year volume projection? Growth trajectory matters. Cloud scales easily but costs grow linearly.
6. Do you have the team to manage it? No infrastructure team favors managed cloud services.
7. What are the exit requirements? DORA and similar rules require documented, tested alternatives.
The answers will differ by workload. That is why most regulated companies end up hybrid.
What We Have Seen Across 500+ Projects
Code & Pepper has worked on over 500 projects in FinTech and HealthTech since 2006. Here is what that experience shows:
Startups usually benefit from cloud. Speed matters more than optimization. Cash is tight. Teams are small. Cloud lets you move fast without capital expenditure.
Scale-ups often revisit the decision. Once you have product-market fit and predictable workloads, the economics shift. Some move workloads back. Others optimize within cloud (reserved instances, committed use discounts, architecture changes). The worst outcome is ignoring the math.
Compliance is a process, not a feature. Cloud providers offer compliant configurations. You still need to implement them correctly, document them, and prove them to auditors. The work happens regardless of where your servers sit.
Some examples from our work:
GaiaLens (ESG analytics for institutional investors): Cloud-based platform cut reporting time by 50%. Variable analytical workloads with burst compute needs made cloud the right fit.
Finbourne (asset management platform): Cloud architecture supported global expansion to US, UK, Ireland, Singapore, and Australia. Geographic reach and fast market entry were the priority.
Pelago (digital health clinic): HIPAA-compliant cloud setup enabled 35% improvement in patient engagement. Managed services let a small team focus on the product rather than infrastructure operations.
Curious to learn more? Here’s more about our Cloud Cost Optimization & Cloud Migration services.
The Bottom Line
There is no universal answer to cloud versus on-premise. Anyone who tells you otherwise is selling something.
What works depends on your workloads, your scale, your compliance requirements, and your team. The companies that get this right evaluate each workload on its merits rather than following a blanket strategy.
In 2026, with DORA adding vendor management complexity and HIPAA potentially adding security requirements, the decision is more nuanced than ever. The path forward is workload-by-workload analysis, honest TCO comparison, and architecture that supports your compliance obligations.
Need a second opinion on your infrastructure?
Code & Pepper has 19 years of experience building software for regulated industries. We work with FinTech and HealthTech teams on architecture decisions, cloud migrations, and compliance implementation. Our engineers have hands-on experience with FCA, PSD2, GDPR, HIPAA, and DORA requirements.
If you want an honest assessment of your infrastructure options, get in touch: hello@codeandpepper.com or click here for our Code & Pepper Contact Form.