techone --guide=cloud-migration
Cloud Migration: When It Pays Off and How to Build It So the Cloud Stays Affordable
The cloud can be cheap, flexible and secure, or expensive, slow and bloated. Which one you get depends on how much effort you put in before you move anything.
Last updated:
TL;DR
- Main decision
- The 6 R strategies: rehost, replatform, refactor, repurchase, retire, retain. Every application in your company belongs to one of them. If you skip this, you will overspend.
- When Azure
- Pick Azure when you need cloud-native services, elastic scaling, EU Data Boundary compliance and integration with Microsoft 365 or Dynamics 365.
- When Hetzner
- Pick Hetzner when you need consistent high performance, large databases and predictable costs, or when applications are not worth rewriting as cloud-native.
- Hybrid scenarios
- Combining Azure and Hetzner is a real option: Azure for elastic services and compliance, Hetzner for compute-heavy workloads and large datasets where Azure costs would grow linearly with volume.
- Timeline
- Rehosting a small application: weeks. Replatform: 2-4 months. Full refactor of a monolith into a cloud-native application: 6-12 months, longer for larger systems.
Why Cloud Migrations Disappoint When You Treat Them as a Server Move
Cloud is sold as a cost saver. The reality is that most companies that call their migration "a disappointment" disappointed themselves. Not the technology. They treated the migration as a server move instead of a change in architecture and operating model.
Cloud has three levels of quality. The higher an application sits on this scale, the more it actually benefits from the cloud, and the less you pay for it. A well-built cloud-native application is many times cheaper than the same functionality running in "we just moved it there" mode.
Level 1: Lift-and-shift (cloud-hosted)
The application runs in the cloud but has no awareness of it. It is an old VM that now lives in a cloud datacenter instead of yours. You gain a few operational benefits (backups, availability) but you pay for infrastructure you do not use. It works as a transition step, not as an end state.
Level 2: Cloud-ready (replatform)
The application has been adjusted to use managed services: App Service instead of a VM, Azure SQL instead of your own SQL server, Azure Storage instead of local disk. You get auto-scaling and predictable operations. This is still not cloud-native, but it is a solid middle ground.
Level 3: Cloud-native (refactor or rewrite)
The application is designed for the cloud: serverless, event-driven, horizontally scalable. You only pay for what you actually use. This is where the cloud starts to make economic sense, not just operational sense.
Where the most expensive mistakes happen
A company buys Azure, moves old VMs one-to-one, shuts down the original servers. The cloud bill is three times what it used to be, nothing got faster and nothing scales. The verdict: "cloud is expensive". The verdict is wrong. The mistake was in the approach, not the cloud.
The 6 R Strategies: How to Decide for Each Application
The standard framework for cloud migration is called the 6 Rs. It describes six ways to handle every application. The first step of a good migration is not "pick your Azure regions" but sorting every application in the company into one of these categories. Some applications belong in the cloud, some do not, and some should simply be switched off. How we run this assessment in practice is covered on our cloud migration service page.
Rehost (lift-and-shift)
Move the application to the cloud without changes. Fastest and cheapest to implement, but you are not using cloud features. Useful as a temporary step to empty a datacenter, or for applications you know you will replace within a year.
Replatform (lift-and-reshape)
Move with small adjustments: replace your own SQL server with Azure SQL, your own web server with App Service. The application does not need to be rewritten, but you gain managed services, backups and scaling. A typical compromise for applications that are fine but not worth rewriting.
Refactor (re-architect)
Rewriting the application to take full advantage of the cloud. A monolith breaks into services, VMs get replaced by containers or serverless functions, tight integrations get replaced by event-driven messaging. The most expensive option, but the cheapest to operate long-term and the most valuable.
Repurchase (move to SaaS)
Instead of moving the old application, you replace it with a SaaS product. Replace your old CRM with a cloud CRM like Dynamics 365 Sales. Replace custom accounting with a cloud ERP. No development needed, you get standard functionality. Fastest route when the process the application handles is not your competitive advantage.
Retire (switch off)
An audit typically shows that 10-20% of applications in a datacenter are no longer used, or their function is covered by another system. The cheapest migration is the one you do not have to do. Switching something off is a migration strategy in its own right.
Retain (keep on-premise)
Some applications do not belong in the cloud. Older systems with hardware dependencies, applications with regulatory constraints, or systems where migration would cost more than it would save. They stay in place until something replaces them.
What the Cloud Actually Costs: Storage, Databases, Egress and Other Pain Points
Cloud pricing looks simple until the first bill arrives. What makes the cloud expensive is not the price of CPU. It is storage, managed databases, and above all, data going out of the cloud. Underestimate these three things and the invoice will surprise you.
Managed databases cost 2-3x a database on a VM
Azure SQL Database removes the pain of patching and backups, but for the same performance you pay roughly two to three times what you would pay for the same SQL Server on a VM. For small databases this is worth it. For large databases running around the clock the cost grows fast and is usually the single biggest item on a cloud bill.
Egress: you pay for data leaving the cloud
Data going into the cloud is free. Data going out costs around $0.087 per GB. For analytics, inter-region transfers, backups and public-facing content, this adds up quickly. A single nightly export to a BI system can double your monthly bill.
Storage has hidden fees for operations and retrieval
Azure Blob Storage charges separately for storage itself and for operations (LIST, GET, PUT). A nightly script that walks all blobs can cost more than the storage itself. The Archive tier is cheap to store but expensive to retrieve and has minimum retention rules: early deletion or tier change comes with penalties.
Soft delete and snapshots quietly inflate the bill
Soft delete and frequent snapshots protect data but consume additional storage. Without controls on retention, they can double or triple your storage bill without anything actually changing in the data.
These costs are not hidden maliciously. They are fully documented. But few teams read the documentation in advance and fewer build the numbers into the ROI case. That is why migrations keep launching with expectations reality cannot meet.
Azure, Hetzner or Hybrid: Pick by What You Actually Need
The cloud is not one thing. Azure and Hetzner solve different problems, and the best architectures often combine them. The decision is not about what is "modern" but about what your applications really need and how they are built.
The rule we follow: elastic and highly variable services belong in Azure, AWS or Google Cloud. Steady compute-heavy and data-heavy workloads belong where you are not paying a premium cloud rate for something you can manage yourself. For the latter, Hetzner and similar providers are far cheaper. We run Medicalface in exactly this kind of setup and handle the ongoing maintenance on both sides. What that looks like in practice is described in our cloud and server management guide.
Azure, when you need cloud-native
An application that can use App Service, Functions, Cosmos DB, Event Grid, Service Bus. You need elastic scaling under load, global availability, integration with Microsoft 365 or Dynamics 365, and compliance covered by the EU Data Boundary. For this profile, Azure is not only the best option but often the only reasonable one.
Hetzner, when you pay for raw performance, not elasticity
An application that needs strong and steady performance: large databases, compute-intensive processing, high-volume storage. A Hetzner EX44 has 64 GB of RAM and 14 cores, and comparable performance in Azure costs many times more. If the application is not worth rewriting as cloud-native, Hetzner is the rational choice.
Hybrid: Azure for frontend, Hetzner for data
A practical setup for companies with large datasets but an elastic frontend. The web application runs in Azure App Service, users connect through a CDN, authentication goes through Entra ID. The data layer and the analytical database live on Hetzner, where you pay a fraction of the cost for the same performance. The two sides are connected over VPN.
When the cloud is not the right answer
A legacy application that is not worth rewriting runs on stable hardware and has predictable operations. Migration would cost more than it would save. In this case, retain is a valid strategy. Not everything has to be forced into the cloud.
Who Should Migrate Now and Who Should Wait
Not every company needs to migrate to the cloud right now. Here are the situations where it is the right move, and where it is better to wait.
Good fit
- Datacenter or server room running out of capacity
- Large legacy application blocking further growth
- Need for global availability or elastic scaling
- Compliance requirements on-premise cannot cover
- Migration to a new ERP that is in the cloud anyway
- Infrastructure consolidation after a merger or acquisition
Not yet
- On-premise works and costs are predictable
- Applications are too old to rewrite
- No team capacity for a project alongside ongoing operations
- No stable project leadership on the client side
| Strategy | Typical situation | Outcome |
|---|---|---|
| Rehost | You need to empty the datacenter quickly | Application in the cloud, no operational improvement |
| Replatform | Application is functional but you want managed services | Auto-scaling, backups and patching included |
| Refactor | Monolith blocking growth, valuable part of the business | Cloud-native operations, long-term savings |
| Repurchase | The process is not a competitive advantage | Replaced by SaaS, no in-house development |
| Retire | The application is unused or duplicated | Switched off, zero operational cost |
| Retain | Regulatory or hardware constraint | Stays on-premise, migrate when needed |
swipe to see the full table
Frequently Asked Questions
How long does a cloud migration take?
It depends on scope and strategy. Rehosting a small application takes weeks. Replatforming a mid-size application takes 2-4 months. A full refactor of a monolith into a cloud-native application typically runs 6-12 months, and longer for larger systems. For Helvetia we rewrote a large desktop VB6 application into .NET and deployed it on Azure. We spent more than a year on it. The most common mistake is planning against a rehost timeline and then finding out replatform or refactor takes many times longer.
Will the cloud be cheaper than our current on-premise?
It can be, but it is not guaranteed. Lift-and-shift rarely leads to savings and often goes the other way. Real savings come with replatform and refactor, where applications use managed services and you pay for actual consumption. Combined with savings on hardware management and electricity bills, the cloud typically pays off in 12-24 months, provided it is built well.
Why are storage and databases expensive in the cloud?
Managed services cost many times more than self-managed equivalents. Azure SQL Database costs 2-3x more than SQL Server on a VM. Azure Blob Storage on the premium tier runs around $0.115 per GB per month, and egress out costs around $0.087 per GB. For large datasets and large databases this becomes a significant line item. Options include a cloud-native architecture (cache, CDN, tiering), a hybrid setup with Hetzner for storage, or reconsidering whether to migrate at all.
Does combining Azure and Hetzner make sense?
Yes, and for some projects it is the optimal setup. Azure provides cloud-native services, compliance and integration. Hetzner provides raw performance at a fraction of the price, if you have the skills to manage it. A typical hybrid setup: Azure App Service or Functions for frontend and API, Azure Entra ID for authentication, databases and large storage on Hetzner. The two sides are connected over VPN. It requires an experienced DevOps team, but the economics often work out.
What does cloud-native mean versus cloud-hosted?
A cloud-hosted application runs in the cloud but has no awareness of it. It is an old application on a virtual machine. A cloud-native application is designed for the cloud from the start: serverless, event-driven, managed databases, horizontal scaling. You pay only for what you actually use. The cost difference between cloud-hosted and cloud-native can be five times or more for the same functionality.
How do we handle the EU Data Boundary and GDPR in Azure?
Microsoft completed the EU Data Boundary in February 2025 (see the official Microsoft Learn documentation). Customer data, diagnostic data and service data all stay in EU regions. This matters for GDPR compliance. During migration, the key is to select the right region (typically West Europe or North Europe) and set data residency for every service. For some services, notably AI and analytics, you need to verify what happens outside the EU. This is also a key Azure advantage over AWS and Google Cloud for European enterprise workloads.
What are your biggest cloud migration references?
Our largest cloud migration was Helvetia: a desktop VB6 application rewritten into .NET and deployed on Azure. It was a full refactor (rewrite), not a lift-and-shift, and we spent more than a year on it. The application has been running on Azure for years and we still maintain it. Smaller migrations and hybrid Azure/Hetzner deployments are part of ongoing work for clients with production systems. For cloud operations after migration, see our cloud and server management guide.
Continue Reading
Cloud and Server Management
What ongoing infrastructure prophylaxis looks like after migration. Monitoring, backups, security patches.
IT Partner for International Companies
Audit and takeover of cloud implementations, Azure for multi-site companies, compliance across markets.
Why Dynamics 365 BC
ERP comparison, cost breakdown and decision matrix.
Not sure which path to take?
We will go through your applications and tell you what belongs in the cloud and what does not.
Free consultation