Moving to the Cloud, Sensibly
Last updated:
What you actually gain
- Capacity that changes with demand, instead of hardware sized for a peak
- Managed databases, backups and failover you no longer operate
- Geographic presence without shipping equipment
- Recovery measured in minutes rather than in days
- No hardware refresh cycle to budget for
Those are real and they are why most businesses should move most things eventually. What is not automatic is the saving.
Why the bill often goes up first
A server lifted from a rack to a virtual machine of the same size costs more per month than the electricity it used to consume, because you are now renting capacity you previously owned outright.
Lift-and-shift is the most common cloud migration and the one that most reliably increases the monthly bill without improving anything.
Savings come from what the cloud makes possible: shutting things down when unused, scaling to demand, replacing servers you maintain with managed services you do not. That requires changing how things run, not just where.
Migration order
- Backups and disaster recovery first. Immediate benefit, no risk to production.
- Development and test environments. Learn the platform where mistakes are cheap.
- Stateless applications. Web servers and APIs move easily.
- Databases. Real planning, real downtime windows, real rehearsal.
- Legacy systems. Last, and honestly, sometimes never.
Ordering by reversibility rather than by value means the first three moves teach you the platform before anything critical depends on that knowledge.
Controlling the cost
- Tag everything on day one; untagged resources become permanent mysteries
- Right-size after two weeks of real metrics, never at provisioning time
- Commit to reserved capacity only for genuinely steady workloads
- Shut down non-production environments outside working hours — a large saving for near-zero effort
- Watch egress charges, which surprise almost everyone
- Set a budget alert before you need one
What to stay wary of
Managed services are convenient and some of them are difficult to leave. A queue or object store is portable; a proprietary serverless database with a bespoke query model is not.
Our rule is to use managed services freely for anything with a standard interface, and to think carefully before adopting one whose model has no equivalent elsewhere. The convenience is real and so is the eventual cost of the exit.
What a migration costs
| Scope | Cost | Duration |
|---|---|---|
| Backups and DR only | £3k–£8k | 2–4 weeks |
| Web application and database | £10k–£35k | 6–12 weeks |
| Multi-system estate | £40k–£150k | 4–9 months |
| Re-architecting for the cloud | Project-dependent | Ongoing |
Frequently asked questions
Will the cloud save us money?
Which provider should we use?
Is the cloud secure enough?
Can we move back if we need to?
Keep reading
Deployments still an event rather than a routine?
A week or two of setup usually turns that around. We document it so your team can run it without us.
Related services
What we build for problems like this one