Remaking a Distro Decision With a Migration Plan in Mind

Choosing a distribution is easy when every machine is greenfield and the team knows one tool. Real distro decisions happen against a background of servers already running, workloads with opinions, and a migration path nobody wants to discover after the bet. The professional version of the choice treats the exit as part of the entry: pick the distribution you would be able to leave. This post is that exercise — inventorying honestly, scoring the realistic paths, and designing the migration before the switch, so the decision becomes a plan rather than a gamble.

Start With Your Exit

Every distribution ends its support window, and cadences differ by an order of magnitude: five years of standard maintenance on Ubuntu LTS, around five on Debian counting its LTS stages, ten years on the EL rebuilds, about thirteen months per Fedora release, and rolling releases that never declare end of life but demand permanent attention. What matters more than the number is the exit you can staff. A box rebuilt from automation migrates in hours; a pet with years of hand edits costs weekends. Decide which kind of machine each server is before you decide which distribution it runs.

Inventory the Workload, Not the Hype

Most failed migrations die on workload assumptions: vendor binaries built for glibc, a control panel tied to one package ecosystem, an old runtime compiled against a specific toolchain. Write down what each box actually runs before you dream about the replacement, because the workload inventory, not the distribution's reputation, decides the migration.

# A ten-minute inventory that decides most of the migration
cat /etc/os-release
uname -r
free -m | head -2
df -h /
systemctl --failed
systemctl list-unit-files --state=enabled | head -20

If a box runs vendor agents or panel software, read those vendors' supported-OS lists instead of picking from preference, because their support matrix is a hard constraint you cannot negotiate away.

Score the Paths, Not the Polls

A scoring grid removes the argument from the room. Weight each criterion, such as support length, ecosystem fit, team familiarity, migration tooling, and the cost of staying put, then fill in the candidates. Staying put must be on the grid, because an unpatched box is a viable answer only if the workload retires with it. The grid tends to produce a boring, defensible winner, which is exactly what a distro decision should feel like.

Rebuild or Convert

Two mechanics exist. Rebuild: stand up the new distribution, replay the provisioning, migrate the data, smoke-test, cut over. Convert: run the project tool, such as ELevate for EL-family jumps or migrate2rocky and almalinux-deploy for moving between EL rebuilds, and patch the box in place. Rebuild is almost always cleaner for boxes that have automation; conversion wins only for the few machines too entangled to reproduce faithfully. The rule of thumb: if you cannot rebuild it inside a day, the upgrade was already overdue, and the honest fix is automating the rebuild, not hand-nursing the box.

# Rebuild path, staged:
# 1. fresh VPS on the candidate distro plus a provisioning playbook, green smoke tests
# 2. rsync data, verify, then switch DNS
# 3. keep the old instance for one full retention window, then delete
echo "rebuild first; convert only when the box genuinely cannot be rebuilt"

Whatever the mechanic, the plan is identical: snapshot first, verify data before any step that changes state, and keep the old machine reachable until the new one has survived a full retention window.

Takeaway

Choose a distribution the way you plan to leave it: inventory what each box actually runs, score the realistic paths including doing nothing, and design the migration so the eventual cutover is boring. The day a distro decision stops being a bet is the day your exit plan becomes part of it.

Test the rebuild path cheaply: stand up the candidate distro on a Netbay VPS in under 60 seconds, replay your playbook, and discover the real obstacles before the deadline finds them — netbayhosts.in.