Linux migration questions answered

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, and CSV/PDF statement export.

Package identifiers — names like httpd or mariadb-server — which the client sends to our hosted API to look up the target equivalent, and, with each usage report, two one-way hashes: a fingerprint per VM, for metering, and from 2.4.0 a host hint. The host hint is a SHA-256 hash of the machine's hardware id (its DMI product_uuid or, when it has none, the MAC addresses of its physical network interfaces), keyed with the VM's identity, which is not sent. It tells apart machines that report under one fingerprint because they were cloned from one image. It is not a billing key, and the hardware id itself is not sent. There is no host hint for a cold image, for a local run that is not root or that runs in a chroot, for a run that cannot read the product_uuid (it is readable by root only), for verify, or for a machine with neither a usable product_uuid nor a physical network interface with its permanent address. A run inside a container sends the hint of the machine the container runs on. 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, 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 a real CentOS 7 package database end-to-end.

A migration is a source → target pair, so coverage is directional, and not every source reaches every target. The supported page names the distributions and major versions, and one appears there only when real conversions, run end to end and assessed by vrtmv verify, have proven it. Coverage is release-specific — tell us your exact source and target versions and we'll confirm scope for your estate. See the supported distributions.

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.

Not in one step. In-place upgrade tools move a running system one major version at a time. Red Hat's route converts CentOS 7 to RHEL 7 with convert2rhel, then runs leapp twice, to 8 and then to 9. The AlmaLinux ELevate project takes the same Leapp path for the RHEL rebuilds. Each hop is a separate change to a live system, with its own reboot, its own pre-upgrade inhibitors and its own failure window, and the system carries every year of drift into the new release. vrtmv does not upgrade. It reads the CentOS 7 system read-only and rebuilds the workload on a fresh target, for example at major version 9, so there is no chain to walk and the original stays bootable for rollback.

CentOS Linux 7 reached end of life on 30 June 2024, and CentOS Linux has no further releases. CentOS Stream continues the name, but it is the development branch just ahead of RHEL, not a rebuild of it. Most teams move to a RHEL-compatible distribution: Red Hat Enterprise Linux itself, AlmaLinux, Rocky Linux or Oracle Linux, usually at major version 9, so packages, paths and admin habits carry over. Some use the move to leave the rpm family for Debian or Ubuntu LTS. The choice is mostly about support contracts, certifications and how the fleet is managed. Our post Rocky Linux vs AlmaLinux compares the two free rebuilds. vrtmv rebuilds onto the targets on the supported page, and your exact source and target are confirmed in scoping.

For most production systems, yes, for concrete reasons. A rebuild never writes to the source, so backing out means not cutting over: the old system keeps running until the new one is accepted. The new system starts clean, without the years of hand edits, stray packages and leftovers an upgrade carries forward. And the two can be compared, because the old and new systems exist side by side. The cost is real too: you need capacity for the new machine, the application data moves as its own step (vrtmv data), and cutover means changing addresses or DNS. For a simple host that you can restore from backup, an in-place upgrade can be the quicker choice. vrtmv is built for the rebuild, and for the step after it: showing that the rebuilt machine matches.

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 and every gap. When the vrtmv signing service answers, its signature is written beside it in vrtmv-attestation.sig.json.

Usually not. A container image runs one command, with no init, no cron and the kernel of the machine it runs on. A VM that runs one long-lived service, keeps its data on volumes and reads its config from files can become one. Most long-lived VMs run several services, keep a database on local disk or run scheduled jobs, and are better rebuilt as a VM, which is what vrtmv does by default. With --format container, vrtmv checks the source before it writes a Containerfile, and vrtmv assess prints the verdict. It refuses a host whose operator declared a kernel module to load at boot. It names the services the image will not start, the scheduled jobs that will stop and each data directory you must place, and leaves those decisions to you. Some things it does not check, such as logs written to disk and how your program handles a stop signal. Read the full list before you choose.

Not with “it boots”. Change-management controls under SOC 2, ISO 27001 or PCI DSS ask for evidence that a change was planned, approved and checked: the configuration before, the configuration after, and what differs. vrtmv gives you that as a parity report. The plan states what the rebuilt system must carry, and vrtmv verify checks the rebuilt machine against it, deciding only from what it can observe there: its package database and the carried configuration paths. A missing package is reported missing, every caveat and gap is listed, and verify exits non-zero on any parity gap, so cutover can be gated on it. Keep the source inventory, the plan and the report with the change record. After cutover, the same baseline lets you re-check the instance for drift.

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 reproducible — the same image yields the same attestation. Each parity report carries a SHA-256 digest of its facts, which an auditor can recompute. Run vrtmv verify with --sign and, when the vrtmv signing service answers, the report is also Ed25519-signed, with the public key published at customer.vrtmv.com/v1/attest/pubkey; when it cannot sign, verify says so and writes the report unsigned. 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.

Yes. Create a free account, run vrtmv on one Linux workload (the VM image or host you would least like to move), and send us the parity report it writes through the contact form. The report holds package, service and config names with their mappings, not their data, and sharing it is your choice. Within 2 business days of the report we hold a 30-minute review call and send a short written summary: what maps cleanly, the caveats and gaps, the decisions left to your operators, and an estimate of the cost and effort of moving that class of host across your estate. It is free and uses one of your ten free migrations.

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.