Questions, answered plainly

vrtmv migrates a Linux workload off a dying platform — CentOS at end-of-life, or a VMware estate you're exiting — and rebuilds it as a virtual machine on a modern, supported OS. It reads your existing system, figures out what it actually runs, and emits an Ansible role — or Terraform, with --format terraform — that reconstructs it on the target, plus a signed parity report documenting exactly what changed. The name is short for Virtual Machine Move.

A cold VM disk image (VMDK, qcow2, raw), a live running Linux system, or a bare-metal server. Whatever the source, vrtmv captures its true state and rebuilds it as a VM on the target via Ansible or Terraform.

No. For a disk image it mounts read-only at the block layer — the source is never powered on or written to, which is what makes it safe for forensics and audit. For a live or bare-metal source it reads inventory and config without installing anything or disrupting the workload.

Create a free account, download the engine, and run one command — e.g. vrtmv migrate --image prod-web01.vmdk --target alma9 -o ./out. The client runs in your environment; you'll get an Ansible role (or Terraform, with --format terraform) and a vrtmv-attestation.json in the output directory.

Your customer portal at customer.vrtmv.com — usage and billing, API tokens for the CLI, CSV/PDF statement export, and downloads of your signed attestations. It's also where drift-check results for your migrated instances live.

Only package identifiers — names like httpd or mariadb-server — which the client sends to our hosted API to look up the target equivalent, plus a one-way fingerprint per VM for metering. Your configuration files, inventory, secrets, IP addresses, and the workload itself never leave your network. The analysis all happens locally on the machine where you run the engine. The one exception is the opt-in beta channel, below.

Beta builds report diagnostics on every run, and that is the condition of being on the channel rather than a setting you can turn off. They send: the engine version and channel, which command you ran (never its arguments), whether it succeeded, the source and target OS, timings, counts — packages resolved, services seen — and, on a failure, an error message with file paths, host names, IP addresses and email addresses stripped out. They do not send image contents, configuration, accounts, keys, or your package list. That stripping runs in the binary before anything is transmitted and again on our side before storage; it recognises the shapes that carry identity, and we describe it as best-effort rather than perfect because that is what it is. Reports are kept 180 days. We may email you when something your builds reported is fixed, and an engineer may open a support ticket on your behalf about it — both are in the terms you accept. Once enrolled you can see every report your builds have sent and delete any of it; deletion is permanent and we keep no copy. Stable builds send none of this — the channel is fixed when the binary is compiled, so no flag or environment variable can turn it on; run vrtmv diagnostics on any build and it will tell you which it is. Enrolling is per account and takes two steps, in the customer portal: any user reads the terms and requests access, then an account admin is shown the same terms and approves — the admin's acceptance is what enrols, and it covers everyone on the account. Full detail: the beta channel reference.

So you don't have to build and maintain the cross-distribution mapping knowledge yourself. We curate it — with provenance and confidence grades — and serve it over an authenticated API. You run a light client and get expert mapping intelligence, kept current, without that work landing on your team.

Yes — on the Enterprise plan we ship a self-hosted Index appliance so the mapping lookups happen inside your own network with no external calls at all. Talk to us about it.

Yes. When a mapping depends on host state (say, whether a bonding config is present), the API sends the question and the engine answers it against your local inventory. The host state used to decide never leaves the box; if it can't be known from a cold image, it's reported as unknown rather than assumed.

Source: rpm families (CentOS, RHEL, Oracle, Amazon Linux, SUSE) and dpkg families (Debian, Ubuntu). Targets include AlmaLinux 9, Rocky Linux 9, RHEL, Ubuntu, and more. The Translation Index covers over 100 releases across 16 distribution families, back to the year 2000 — 8,700+ package mappings and 46,000+ cross-distro translations; the live demo runs CentOS 7 → AlmaLinux 9 / Rocky Linux 9 end-to-end.

A migration is a source → target pair, so coverage is directional. Enterprise Linux → Enterprise Linux (CentOS, RHEL, and Oracle → Rocky Linux, AlmaLinux, or Oracle Linux 9) and Debian/Ubuntu in-place family upgrades are supported, with a set of flagship pairs attestation-validated — run end to end on real images, parity assessed and signed. Enterprise Linux ⇆ Debian/Ubuntu cross-family conversions and Amazon Linux sources are supported and validated per engagement; SUSE is available on request. Validated examples include CentOS 7 → Rocky Linux 9, CentOS 7 → AlmaLinux 9, CentOS 7 → Debian 12, CentOS 7 → Ubuntu 24.04, and Ubuntu 20.04 → Ubuntu 22.04. Coverage is release-specific — tell us your exact source and target versions and we'll confirm scope for your estate. See the full coverage grid.

Yes — including the Berkeley-DB format used on CentOS/RHEL 7, plus the ndb and sqlite formats on EL8/EL9. EL7 is exactly the population most affected by end-of-life, so it's a first-class path.

They're reported as unresolved — listed in full, not hidden. Most unresolved entries are base-OS and shared-library packages that migrate by identity. On the Pro plan we'll curate mappings for the packages specific to your stack.

Two artifacts: an Ansible role (roles/vrtmv_migration/tasks/main.yml) that rebuilds the workload as a VM on the target — or Terraform (terraform/main.tf plus cloud-init) if you pass --format terraform; Ansible is the default — and a signed parity attestation (vrtmv-attestation.json) listing every translation with its confidence grade, every caveat, every gap, and a signature.

Every mapping carries the provenance of the rule behind it and an honest confidence grade; gaps and unknowns are stated rather than papered over; and the report is signed and reproducible — the same image yields the same attestation. The signature is ed25519 and live on every migration today — verify it against the published key at customer.vrtmv.com/v1/attest/pubkey. It's designed to be the artifact you hand an auditor who asks "what changed, and how do you know it's equivalent?"

No — that's what the annual subscription is for. Any time after cutover you can re-check an instance for drift against its signed parity baseline: packages, services, config, and accounts that have moved since the attestation was written. The parity report stays something you can re-verify rather than a one-day snapshot.

Yes — the live demo runs the real engine against a real CentOS 7 server and shows you the actual role and attestation it produces.

Your first 10 migrations are free, with the full engine and full attestation. Beyond that, the per-instance rate depends on how many you buy at once: On-Demand is $799 per instance a year with no minimum; Pro is $599, bought 10 at a time; Fleet is $399, bought 100 at a time. Each price is billed annually and covers the migration, its signed attestation, and ongoing monitoring. See Pricing.

One source workload reconstructed and attested to a target — typically one VM or host. Re-running the same host (e.g. after a config change) doesn't burn another migration.

No. That chain exists because in-place upgrade tools mutate a running system one major version at a time — CentOS 7 to RHEL 9 by that route is three separate operations (convert2rhel, then leapp twice), each with its own failure window. vrtmv does not upgrade anything. It reads your source read-only and rebuilds the workload on a fresh RHEL 9 target, so there is no sequence to walk. The Index maps CentOS 7 → RHEL 9 directly — 85 canonical packages resolved against RHEL 9's own names, not composed through RHEL 7 or 8 — so no translation error compounds across hops. The trade-off is real and worth stating: this is side-by-side, not in-place, so you need somewhere to build the target, and the application data that no package owns moves as a separate attested step (vrtmv data). What you get for it is a better rollback — your CentOS 7 original is never written to and stays bootable, so a failed cutover means pointing back at it rather than restoring from backup.

It's $799 per instance a year On-Demand, $599 on Pro (10 at a time), and $399 on Fleet (100 at a time). It covers the migration, its signed attestation, and monitoring — after a migration you can re-check the instance against its signed parity baseline any time (before an audit, after a change), and vrtmv flags configuration, package, service, or account drift, so your attestation stays something you can re-verify rather than a one-day snapshot. It also keeps the instance's Index mappings and support current.

Against what you stop paying VMware. A dual-socket host (~64 cores) on VMware Cloud Foundation at $350/core/yr carries ~20–25 VMs, so each VM runs roughly $900–1,100/yr in licensing — a renewal that repeats forever. vrtmv is $399–799 per instance a year, billed annually, covering the migration and keeping its parity re-verifiable. The more instances you buy at once, the lower the rate: buying 100 at a time (Fleet) reaches $399, roughly 40% of what that VM was costing in VMware licensing alone.