Decide why first
Cloud migration is not automatically cheaper. A workload lifted unchanged onto an oversized instance frequently costs more than the server it replaced, and the team has taken on new operational complexity in exchange.
The reasons that genuinely justify it are specific: demand that varies enough for elasticity to matter, a need for managed backups and failover, geographic distribution, or hardware approaching end of life. Write down which of those applies before choosing a provider — it determines the whole approach.
The six strategies
Every migration is some mix of these. Most systems use two or three across different components.
| Strategy | What it means | Best when |
|---|---|---|
| Rehost | Move as-is onto cloud VMs | Deadline pressure, stable app |
| Replatform | Minor changes, e.g. managed database | Quick wins available |
| Repurchase | Switch to a SaaS product | Commodity function such as email |
| Refactor | Rebuild for cloud-native services | Scaling limits in current design |
| Retire | Switch it off | Nobody has used it in a year |
| Retain | Leave where it is for now | Compliance or a pending rewrite |
The retire category is worth real attention. Most inventories contain services that nobody has used for a long time, and not migrating them is the cheapest possible outcome.
Inventory before you plan
The step that most often gets skipped, and the one that causes the surprise outage three weeks later. You cannot migrate what you have not written down.
- Every application, service and scheduled job, with an owner named against each
- What talks to what — including the reporting script on somebody's desktop
- Data volumes and growth rate, which drive both transfer time and storage cost
- Peak versus average load, so instances are sized on evidence rather than guesswork
- Compliance constraints, particularly any data that must remain in a specific country
- Hard-coded IP addresses and hostnames, which are a reliable source of post-cutover failures
Sequencing the move
Order the work so that the first migration teaches you something cheaply.
- Start with a low-risk, low-dependency service to validate the pipeline and monitoring
- Set up networking, identity and access control before moving anything important
- Move the database with replication running, so the cloud copy stays current
- Run both environments in parallel and reconcile the outputs until they match
- Cut over during a genuine low-traffic window, with a tested rollback path
- Keep the old environment available for a defined period, then decommission it deliberately
The parallel-run step is what turns a risky migration into a routine one. If the two systems disagree, you find out while the old one is still authoritative rather than after you have switched.
Moving the data without a long outage
Database migration determines your downtime window more than anything else. A large dump-and-restore can take hours; replication reduces the cutover to minutes.
Set up replication from the existing database to the cloud instance, let it catch up, verify row counts and checksums, then stop writes briefly, allow the last transactions to replicate, and repoint the application. Practise the sequence on a copy first and time it, so the maintenance window you announce is based on a measurement.
Costs teams underestimate
The instance price is the part everyone budgets for. These are the line items that produce the surprising first invoice.
- Egress — moving data out of the provider is charged, and it adds up quickly for media-heavy sites
- Inter-zone traffic between availability zones inside the same region
- Snapshots and backups accumulating indefinitely because nobody set a retention policy
- Load balancers, NAT gateways and managed service base fees charged per hour regardless of use
- Non-production environments left running overnight and at weekends
- Oversized instances chosen from peak load and never revisited
Set budget alerts on the first day, tag every resource with an owner, and put a calendar reminder to review sizing after a month of real traffic. That single review usually pays for itself several times over.
What to have in place before cutover
A short checklist worth being strict about, because each item on it has caused a real incident somewhere.
- Monitoring and alerting configured and verified in the new environment, not after
- Backups taken and, more importantly, a restore actually tested
- DNS TTL lowered a day or two ahead so the switch propagates quickly
- TLS certificates issued and installed for every hostname, including redirects
- A written rollback procedure that somebody other than the author has read
- A named person on call for the window with the authority to trigger the rollback
After the move
Migration finishing is not the project finishing. The month afterwards is when you right-size instances against real load, tune autoscaling thresholds, set backup retention, and remove the temporary access granted during the cutover.
Done well, the result is a system that costs a little more per month than the old server and considerably less in the hours nobody spends nursing it. Done without the inventory and the parallel run, it is an outage with an invoice attached.
Planning a migration?
We handle cloud setup, migration and ongoing management across AWS, Google Cloud and Azure — including the sizing review a month in, which is where most of the savings are.