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 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.

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 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. 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.

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 confirmed 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, 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 $999/instance ($400 one-time + $599/year monitoring) with no minimum; Pro is $799/instance ($300 + $499/year), bought 10 at a time; Fleet is $599/instance ($200 + $399/year), bought 100 at a time. Migrations to RHEL waive the one-time fee on every tier (terms apply). 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.

It's $599/year On-Demand, $499/year on Pro (10 at a time), and $399/year on Fleet (100 at a time). It buys drift 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 $200–400 once to get the VM off it, then $399–599/year to keep it monitored — a fraction of the VMware annual you stop paying. The more instances you buy at once, the lower both numbers go: buying 100 at a time (Fleet) reaches the lowest $200 + $399/year rate.