The problem
The first question in every migration
Before a company moves to the cloud, someone has to go through the estate and decide, server by server, whether it moves as-is, gets rebuilt, gets replaced by a managed service, or gets switched off. That's usually a spreadsheet, a consultant and a few weeks. It's also the cheapest point at which to catch an unsupported OS or a database that can't move without its neighbours.
Aegis already watches cloud estates. This feature works one step earlier, on the estate that isn't in the cloud yet.
What it does
Inventory in, plan out
The input is a list of workloads: a CSV from a template, a JSON file, or the output of a discovery script. For each workload the assessment returns:
- A 6R disposition (rehost, replatform, refactor, repurchase, retire or retain), with every rule that led to it listed as a reason.
- An operating-system lifecycle check against end of standard vendor support. An OS it doesn't recognise is reported as unknown, never as supported.
- An AWS target size and monthly cost at
us-east-1on-demand Linux list price, plus gp3 storage. - A readiness score and risks: things like end-of-life OSs, databases, Windows licensing and regulated data.
Across the estate it groups workloads that depend on each other into move waves, adds compliance notes for anything tagged PCI, HIPAA or PII, and exports the lot as CSV.
Design
Rules it isn't allowed to break
Cost estimates are where tools like this usually mislead, so the module opens with its own rules:
- List price, labelled as list price. Not a negotiated rate, not Savings Plans, no Windows or SQL licensing. A workload it can't size is priced as unknown, never guessed.
- The sizing basis is always stated. Sizing by allocated CPU and RAM overstates cost for most on-prem estates. When real utilisation is supplied, it's used instead, and every result says which basis it used.
- A 6R call is a starting point. It comes from explicit rules, each one shown, for a planning conversation. It isn't a decision.
◆ Why it's built this way
A migration estimate that comes in far too low is worse than no estimate, because someone budgets from it. Every number the tool produces carries the assumption it rests on.
Discovery
A read-only Proxmox discovery script
Writing an inventory by hand is the part people skip, so there's a script for the most common homelab and small-business hypervisor. Run it as root on any Proxmox node and it writes the inventory as JSON:
python3 proxmox-discover.py > inventory.json # then upload it on the Migration page
It only ever calls pvesh get. Nothing is created, changed or restarted, and no credential leaves the host. Per guest it records the allocation, the OS (from the QEMU guest agent when that's running, otherwise the configured OS type), used disk, Proxmox tags, and 95th-percentile CPU and memory over the last week, so the assessment can size by real use rather than allocation.
The script and the CSV template are public downloads, so a prospect can read exactly what they're running before they run it.
First real run
Assessing the host that just left the cloud
The first estate it assessed was the third Proxmox host, which had taken the Aegis production API out of the cloud a few hours earlier (the migration). Six VMs came back as grade A, at about $467 a month at AWS list price.
The droplet it replaced cost about $24 a month, and the AWS estate before that about $99. The tool isn't arguing against the cloud. It puts the cost of a move in front of you before you make it.
Shipping it
Verified, and a way to try it
- 22 new backend tests and the full suite green, plus 83/83 frontend tests.
- A create/delete smoke test against production. The public template and script downloads return
200, and listing assessments without logging in returns401. - A public landing page offers a free migration readiness report: send an inventory, get the assessment back as CSV or PDF.
This is phase 1. It prices AWS only, and it works from the inventory it's given.
