techone --guide=cloud-migration
Cloud Migration: When It Pays Off and How to Keep It Affordable
Cloud can be cheap and flexible, or expensive and slow. The decision is made before anything moves.
Last updated:
TL;DR
- Main decision
- Every application needs its own decision: lift-and-shift, refactor, replace with off-the-shelf, or do not move. Without these decisions, migration overspends.
- 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 self-hosted
- Pick dedicated servers when you need consistent high performance, large databases and predictable costs, or when applications are not worth rewriting as cloud-native.
- Hybrid scenarios
- Combining cloud and self-hosted often works best: Azure for elastic services and compliance, dedicated servers 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.
- Who delivers
- Prague-based team, CET timezone, EU contracts, English projects. Helvetia: 3+ years on Azure across 7 countries.
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. A well-built cloud-native application has significantly better operational economics 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 data center 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. Cloud-native foundation is also a prerequisite for AI services and automation, see our <a href="/en/guide/ai-automation">AI automation guide</a>.
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 higher than before, nothing got faster and nothing scales. The conclusion: "cloud is expensive". The actual issue is the migration approach.
How to Decide for Each Application
The first step of a good migration is not "pick your Azure regions" but deciding what to do with each application. Some belong in the cloud as-is, others need a rewrite, some should be replaced with off-the-shelf solutions, and some should not move at all. 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 data center, 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 out-of-the-box 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 data center 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-premises)
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 Drives Cloud Costs
Cloud costs are not just the price of CPU. The main drivers are storage, managed databases, and egress (data leaving the cloud). Calculate these three upfront for a realistic projection.
Managed database: when it makes sense
Managed databases (Azure SQL, RDS) take over patching, backups and high availability. For smaller databases and teams without a DBA, this makes sense. For large databases with continuous load, it is worth considering whether to manage the database in-house.
Egress: data leaving the cloud
Data going into the cloud is free, data going out is charged per GB. For analytics, inter-region transfers, backups and public-facing content, this adds up. Regular exports to BI or backups to external storage are line items worth including in the calculation.
Storage: operation and retrieval fees
Object storage (Azure Blob, S3) charges separately for storage itself and for operations (LIST, GET, PUT). Scripts walking all objects generate additional operations. The Archive tier suits long-term retention but has minimum retention rules and access fees.
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 aren't hidden, they're fully documented in vendor pricing. The problem is that few teams read the documentation in advance, and even fewer build the numbers into the ROI case. That's why migrations keep launching with expectations reality cannot meet.
Cloud, Self-hosted or Hybrid: Pick by What You Actually Need
The cloud is not one thing. Cloud and dedicated servers 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, dedicated server 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.
Dedicated server, 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 dedicated server with fixed configuration provides predictable costs regardless of usage. If the application is not worth rewriting as cloud-native, a dedicated server is the rational choice.
Hybrid: Azure for frontend, dedicated server 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 a dedicated server, 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-premises 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 data center 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-premises, 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, longer for larger systems. For Helvetia we rewrote a large desktop Visual Basic application into C# .NET on Azure, and that took us over a year. The most common mistake is planning around a rehost timeline and then finding out replatform or refactor takes much longer.
Will the cloud be cheaper than our current on-premises setup?
It can be, but it isn't guaranteed. Lift-and-shift rarely leads to savings and often goes the other way. Actual savings come with replatform and refactor, where applications use managed services and you pay for what you consume. Combined with savings on hardware management and electricity, the cloud typically pays off, provided it's built well.
Why are storage and databases expensive in the cloud?
The main cost drivers are managed databases, object storage and egress (data leaving the cloud). For large datasets and large databases this can become the biggest line item on the cloud bill. Options include a cloud-native architecture (cache, CDN, tiering), a hybrid setup with a dedicated server for storage, or reconsidering whether migration makes sense at all.
Does combining cloud and self-hosted make sense?
Yes, and for some projects it is the optimal setup. Cloud provides elastic services, compliance and integration. Dedicated servers provide raw performance at a fraction of the price, if you have the skills to manage them. A typical hybrid setup: Azure App Service or Functions for frontend and API, Azure Entra ID for authentication, databases and large storage on a dedicated server. 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's an old application running on a VM. 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 substantial 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, which matters for GDPR compliance. During migration, pick the right region (typically West Europe or North Europe) and set data residency for every service. For services like AI and analytics, verify what data actually leaves the EU. Azure's EU Data Boundary is a significant factor for GDPR-sensitive workloads.
What are your biggest cloud migration references?
Our largest cloud migration was Helvetia: a desktop Visual Basic backoffice rewritten into C# .NET on Azure, running across 7 European markets. A full refactor (rewrite), not a lift-and-shift, and over a year of work. The application has been running on Azure for years and we still maintain it. Smaller migrations and hybrid deployments (cloud plus dedicated servers) are ongoing work for clients with production systems. For cloud operations after migration, see our cloud and server management guide.
Not sure which path to take?
We'll review your applications and tell you what belongs in the cloud and what does not.
Book a discovery call