The overlap week.
A wave occupies its target from its first day and frees its source only after the cutover, minus a rollback reserve. Rymvard plans both sides, week by week.
Private cloud and migrations
Every wave lands.Every host can be patched.
For private-cloud providers and their teams — operations, migration, platform and sales: Rymvard checks week by week whether a migration or onboarding wave fits its target through the overlap, whether every host can be emptied for maintenance, what staying on a platform costs — and which VM packages sales can still promise.
Read-only. New in version 0.26 — the screens show an illustrative example estate, not a customer.
A migration is a promise made twice.
During a move a customer sits in two places at once: the target fills before the source is freed, a rollback reserve stays behind and staging storage waits for the cutover. A plan that counts the customer once breaks in the overlap week — usually on the dimension nobody watched.
Maintenance needs room.
A host can only be patched if its VMs fit elsewhere in the cluster without eating the HA reserve. Rymvard checks every host, one at a time.
Staying has a price.
Licences, support and hardware decide whether a platform change pays. Rymvard compares the options with the costs you enter — never with prices it guesses.
What Rymvard shows
Twenty-six weeks, cluster by cluster.
Each cluster's free vCPU, RAM and storage after the HA reserve, week by week — with the first week a wave breaks and the dimension that binds.
Waves with dates.
Migration, onboarding, refresh and retirement waves with start, cutover and release dates, a rollback reserve and staging storage. Full planned demand decides; weighted demand only informs.
One host at a time.
For every host: can its VMs move elsewhere in the cluster within the HA reserve? Hosts that cannot be emptied are named before the maintenance window.
Licences and platform costs.
The licence position per pool — needed against owned, per core, socket or node — and the yearly cost of each platform option from the costs you enter.
VM packages for sales.
Approved packages — S, M, L or your own shapes — counted per cluster, held for a customer for a few days, and the first week a cluster is full.
Read-only, from the platforms you run.
Rymvard never changes a customer platform. It reads inventories and capacity from what you already operate and keeps them current.
- vCenter, Proxmox VE and Kubernetes inventories through read-only connectors; utilisation from Prometheus exporters.
- Migration waves, licence pools, platform costs and VM packages from CSV templates or the REST API.
- Planning suggestions never change a customer platform — a person approves every hold.
- Detailed records stay in their country; customer names are visible only to the people who need them.
New in 0.26 · Workspaces
Four homes for cloud teams.
Cloud operations, migration, platform and sales each open Rymvard on their own home — their question, their four figures and only the findings that concern them, with AI that explains every number and suggests the next step. See the workspaces
Private Cloud Operations
Can every cluster lose a host — and can every host be patched?
- Clusters short of HA reserve
- Hosts that cannot be evacuated
- Clusters with unknown capacity
- VMs without host mapping
Migration & Onboarding
Which wave lands when — and does the target hold through the overlap?
- Waves that do not fit
- First week a wave breaks
- Changes fitting only without HA
- Dependencies out of order
Platform & Licences
What does staying cost, and what would moving save?
- Licensed units needed vs owned
- Licence pools short
- Cheapest entered option
- Nodes with unknown cores
Private Cloud Sales
Which VM packages can I sell, where — and from when?
- Largest package that fits now
- Packages per profile now
- First week a cluster is full
- Holds expiring in 3 days
Screens from the running product on its example estate. Customer names appear only for planners and admins — findings never name a customer.
Across every solution
Recovery, together.
When a site fails, workloads from every solution land on the same recovery destination. Rymvard checks them together and sets each recovery time against the restore throughput your tests measured. Joint recovery
Plan the next wave before it lands.
One cluster estate, read-only: which wave fits when, which hosts can be patched, which packages you can sell.