Cloud migrations and costs: pay for what you use and switch without surprises
Know where each part of the bill goes, cut what is surplus and, if it pays off, switch provider with testing and a plan to go back.
Usual tools
- ClickHouse
- Elasticsearch
- Kafka
- Kubernetes
- Hetzner
- MongoDB
- MySQL
- Proxmox
In short
A cloud cost review is an analysis of what you pay your provider, to separate what is necessary from what is surplus. We review your AWS, Google Cloud or Azure bill and propose in writing what to cut and how much effort it takes. If switching provider pays off, for example to Hetzner, we plan the migration with prior testing and a rollback plan.
- Languages
- Spanish, Catalan or English
- Response
- The next business day, during business hours
- Method
- In your account and your repository, in code and documented
What is included
- Breakdown of the bill by service, environment and team, adding tags if there are none.
- List of oversized, forgotten or orphaned resources.
- Written savings proposal, prioritised by impact and effort.
- Budget alerts so the bill holds no surprises.
- Phased migration plan, with criteria for moving forward or rolling back.
- Target infrastructure in code (Terraform).
- Data migration with verification and an agreed cutover window.
- Final report with the before and after.
Why does the cloud bill go up?
Hardly ever for a single reason. What we find most often when we review an account:
- Machines and databases still at the size chosen on day one and never reviewed.
- Test or demo environments still running months later.
- Unused disks, snapshots and IP addresses that are paid for every month.
- Egress traffic and cross-zone transfers that nobody had worked out.
- Logs and metrics kept for longer than necessary.
- Usage commitments or reservations that are not being used.
Which measure should come first?
Not every saving costs the same or carries the same risk. In the proposal we rank them like this:
| Measure | Effort | Risk | When it makes sense |
|---|---|---|---|
| Switch off or delete what is unused | Low | Low, if confirmed first | Always, it comes first |
| Right-size machines and databases | Low to medium | Medium, tested first | When average usage is far below what is provisioned |
| Switch off test environments out of hours | Low | Low | Environments only used during business hours |
| Reduce log and metric retention | Low | Low, if agreed | When more is stored than is ever queried |
| Usage commitments or reservations | Low | Medium, because of the lock-in period | Stable workloads with at least a year ahead |
| Switch provider | High | Medium to high | Stable workloads and a team that takes on more maintenance |
Changing provider is not always moving to another cloud: sometimes it means moving virtual machines to your own servers with Proxmox VE, or replacing one of the provider’s managed services with your own, such as a cache with Valkey.
How do we migrate between providers?
A migration is not copying machines: it is rebuilding the environment on the target, testing it and switching the traffic over once everything meets the criteria. This is the order:
Inventory and dependencies
Which services there are, which of the provider’s managed services they depend on and what alternative exists on the target.
Target in code
Network, machines, databases and permissions in Terraform, so it can be repeated and reviewed.
Data replication
Initial copy and continuous sync until switchover day.
Testing
Load and functionality on the target, with written criteria for what has to be met.
Switchover and rollback
An agreed window, a DNS or load balancer change, and a tested plan to go back to the source.
What about personal data?
If you are moving personal data, the provider and the region matter. When needed, we choose data centres in the European Union with you and record in writing where each piece of data is held. If we are going to process that data during the migration, we sign the data processing agreement beforehand.
What experience do we have?
In a CTO role we have managed the cloud budget of a platform with 99.9% availability, and in DevOps at a B2B SaaS we have worked with environments across several providers described in code. We know AWS, Google Cloud, Azure, Hetzner and DigitalOcean, and what each one really costs once maintenance is added in.
Frequently asked questions
How much can we save?
It depends on each account, and we do not give a figure before looking at it. The review tells you what savings are possible, how much effort each measure takes and what risk it carries, so you can decide based on data.
Is it worth moving from AWS to Hetzner?
Sometimes it is and sometimes it is not. It pays off with stable workloads and teams that can maintain more moving parts; it does not if you depend on many managed services or need a presence in several regions. We compare it using your numbers.
Will there be downtime during the migration?
It is planned to keep it to a minimum: data replicated in advance, testing on the target and an agreed cutover window. If anything fails to meet the criteria, we go back to the source.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on