Field notes

Getting off CentOS 7 without lying to your auditors

CentOS 7 went end-of-life on June 30, 2024. If you're reading this, there's a decent chance you've got boxes that hit that date and just… kept running. Mine did too. Nothing explodes on July 1st. The kernel still boots, yum still resolves against the mirrors that haven't gone dark yet, and the app keeps serving traffic. That's the trap. End-of-life isn't a crash, it's a slow leak — no more patches, no more CVE fixes, and a compliance clock that's already past due.

So let's talk about actually getting off it. Not the theory. The part where you have forty machines, half of them running something a contractor set up in 2016, and an auditor who wants proof the replacement does the same thing the original did.

First, kill the fantasy of the in-place upgrade

There are converters. leapp with the ELevate project, migrate2rocky, almalinux-deploy. They flip a running CentOS 7 box to Rocky or Alma more or less in place. And for a clean, boring, vendor-default machine, they mostly work.

The problem is you don't have clean boring machines. You have the box with three third-party repos, a hand-compiled Nagios plugin, an /etc/rc.local that does something nobody remembers, and a Perl script in /opt that's load-bearing. An in-place converter walks into that and either chokes or — worse — succeeds, and now you've got a Frankenstein box that boots but drifted in ways you can't see. When something breaks three weeks later you have no idea what changed, because the “upgrade” mutated the machine you were standing on.

For a lab box, sure, convert in place. For anything an auditor will look at, don't. You want the old machine sitting untouched and the new one built fresh, so that if the two disagree you can point at exactly where.

Second, pick your target like an adult

Your realistic options, minus the marketing:

There's honestly less wrong answers here than the internet suggests. The wrong answer is not deciding, because indecision is how you end up still running CentOS 7 in 2027.

Third — and this is the part everyone skips — prove it

Here's where migrations actually go sideways. Not the rebuild. The sign-off.

You stand up the new AlmaLinux 9 box, you run your Ansible, it goes green, everyone's happy. Then someone asks: is it the same? Does it have the packages the old one had, in a form that does the same job? Did the config you cared about actually make it over, or did it land in a slightly different path and get ignored? Did that one sysctl tweak survive?

And the honest answer, most of the time, is “probably.” Which is not a word you want to say to an auditor.

A migration you can't prove is a migration you get to defend in a meeting, from memory, six months later. I've been in that meeting. It's not fun and you always lose it.

Where a tool earns its keep

You can do all of this by hand. People have for years — diff the package lists, eyeball the configs, write a runbook, hope. It works right up until scale or an audit makes “hope” unacceptable.

What I want from a tool is narrow and specific: read the old machine without booting it — a cold disk image, a live SSH pull, whatever — figure out what it actually runs, and emit something I can review before it touches anything. An Ansible role or Terraform, not a black box that mutates a server and tells me to trust it. And then, after I rebuild, check the new box against the promise and hand me a signed report of what matched and what didn't.

That last part is the bit that's easy to do badly by hand. vrtmv, the tool we build, exists mostly because of it: it reads the source read-only, translates the package and config set across the distro gap, generates the rebuild, and then verifies — it diffs the rebuilt machine against what it promised and signs the verdict. Equivalent, partial, or failed. A wrong-distro rebuild comes back failed, not a cheerful green checkmark, which is the honest behavior even when it's the annoying one.

I'll be straight about the boundary, because that's the only way this is useful: it does not copy your file contents around by magic. It plans the migration and proves parity; the actual data still moves through a runbook you run, with checksums, and it refuses to touch a clustered database rather than pretend it can safely dump one. If a vendor tells you their tool “just migrates everything, including your data, automatically, safely,” go count your backups.

A boring plan that works

If you take nothing else from this:

None of this is clever. Clever is what gets you a 2 a.m. rollback. Boring and provable is what gets you a clean audit and a weekend.

CentOS 7 isn't coming back. The window where “we'll deal with it later” was a defensible answer closed on June 30, 2024. The good news is the migration itself is a solved problem — the hard part was never the rebuild, it was proving the rebuild. Solve that part and the rest is just work.

Want to see what your CentOS 7 boxes actually contain? vrtmv reads a cold image or a live host, plans the rebuild on the target you choose, and signs a parity report you can hand an auditor. Your first migrations are free.

Create a free account See supported conversions