Cloud that fits the workload, not the other way round
Some workloads belong in a public cloud. Some run better and cheaper on a private platform you control. Most organisations end up with both. We help you decide what goes where, then design, build and migrate it, including moving off VMware.
Four problems we see again and again
Lift and shift, then a big bill
VMs are moved to public cloud exactly as they were, sized for peak and running 24x7. The first full-year invoice is a shock.
The VMware renewal arrives
Broadcom's move to subscription bundles has pushed renewal costs up sharply for many teams, and the renewal date leaves little time to plan an exit.
Two clouds, two sets of rules
Each team opened its own cloud account. Nobody can say who has access to what, or where the audit logs are.
Private cloud nobody can run
An OpenStack platform was installed by a vendor and handed over without runbooks. Upgrades are now feared and postponed.
Four ways to run your workloads
| Model | What it means | Strong at | Watch out for |
|---|---|---|---|
| Private cloud | A self-service cloud on hardware you own or lease, often OpenStack on KVM. | Steady workloads, data that must stay put, predictable cost over 3 to 5 years. | You need the skills to run and upgrade it. |
| Public cloud | AWS, Azure, OCI or similar. You rent capacity by the hour. | Spiky load, fast start, managed services such as databases and analytics. | Cost grows quietly. Data transfer and always-on VMs add up. |
| Hybrid cloud | Private and public working together over private links, with one identity system. | Keeping core data at home while using cloud where it is stronger. | Connectivity, identity and DNS must be designed, not assumed. |
| Multi-cloud | More than one public cloud, usually for different workloads or by acquisition. | Using the best service from each provider, reducing dependence on one. | Every extra cloud multiplies governance and skills needed. |
Where should this workload run?
Answer five questions about one application. You will get a suggested starting point and the reasons behind it.
Guides and examples
Private cloud on OpenStack
How a production OpenStack platform is laid out, with sizing guidance and the decisions that matter.
Read the guide →VMware to KVM migration
A wave-by-wave method to leave VMware safely. Includes an animated migration simulation.
Read the guide →Hybrid cloud
Connectivity, identity and DNS between your data centre and a public cloud.
Read the guide →Public and multi-cloud landing zones
Accounts, guardrails, networking and logging set up before the first workload lands.
Read the guide →Running the platform (Day 2)
Monitoring, patching, upgrades, capacity and cost control after go-live.
Read the guide →Private vs public cloud cost
A calculator to compare five-year cost with your own numbers.
Read the guide →Use case: leaving VMware
An illustrative scenario: 300 VMs moved to OpenStack in six waves.
Read the use case →Cloud questions, answered
Lock-in, data residency, OpenStack skills, VMware licences and more.
Read the FAQ →For the full technical reference, see the cloud whitepaper.
How a cloud engagement runs
- Inventory. We start from an export of your VMs, applications and dependencies, not from a product brochure.
- Placement. Each application is assigned to private, public or hybrid, with the reason written down and agreed.
- Design. Target architecture, network and identity design, bill of materials, and a cost model you can check.
- Build. Platform built from code (Ansible, Terraform), tested for failure before any workload moves.
- Migrate in waves. Groups of related applications move together, each with a tested rollback.
- Hand over. Runbooks, monitoring and an upgrade plan your team can own, with support if you want it.
Planning a cloud move or a VMware exit?
Send us a VM inventory export (RVTools is fine) and a line on what is driving the change. We will come back with a plain first view: what could move where, in what order, and roughly what it would cost to run.