On-premises to Azure migration: strategy and cost
Moving servers from your own room to Azure promises less hardware hassle and more flexibility. But it isn't automatically cheaper, nor right for everything. Here's a sober look at how to approach the migration and what to avoid.
Contents
Why Azure — and why maybe not
Azure makes sense when your own hardware is ageing out, you need to scale flexibly, you want better availability or you want to be rid of maintaining a server room. Conversely, if you have new hardware, a stable and predictable workload and sensitivity to monthly cost, your own servers may work out cheaper. The decision isn't ideological but economic and operational.
Migration strategies
Not every server moves the same way. The three most common approaches:
Rehost (lift-and-shift)
The server moves to Azure as-is. Fastest and simplest, ideal to start. It doesn't fully exploit the cloud, but it works immediately.
Replatform
The server is partially adapted — for example replacing the database with a managed service. More work, but lower overhead and better cloud fit.
Refactor
The application is reworked for the cloud. The biggest investment, worthwhile only for key applications with a long horizon.
Most companies start with rehost and gradually move to replatform where it pays off. Trying to refactor everything at once is the fastest route to a blown budget.
Cost — the truth about cloud
Cloud isn't automatically cheaper. You pay for what runs, so a server on 24/7 without optimisation can cost more than your own. The keys to sensible cost:
- Size resources correctly — no more than you actually need.
- Switch off what needn't run continuously (test and dev environments).
- Use reserved capacity for steady workloads — it cuts the price significantly.
- Track cost from day one, not when a surprise bill arrives.
The most common post-migration surprise is a bill for data and oversized machines. Without cost tracking in place, the cloud can quickly get away from you.
Recommended approach
- Map what you have — servers, applications, dependencies and demands.
- Decide what moves, what becomes a managed service and what stays on-premises.
- Migrate in waves, starting with less critical systems.
- Set up monitoring, backup and cost tracking.
- After migration, right-size resources to actual load.
Common mistakes
- Moving everything at once without mapping dependencies.
- Oversized machines copying the original hardware 1:1.
- No cost tracking — the first bill as a shock.
- Assuming the cloud removes the need for backup and security. It doesn't.
Considering a move to Azure?
I'll assess your infrastructure and propose a migration strategy and cost estimate. The initial consultation is free.
Book a consultation