Linux VM Migration Guide

NOTE: Migrating VMs between different platforms can be challenging due to the complexities, application dependencies, and differences in underlying platform. It is generally advised to do this only if you understand the VM you're migrating and its function(s).

Purpose

This guide is meant to offer high-level generalized methods for migrating data and application state from one Linux VM to another without copying system-level files blindly. It is intended for scenarios where:

• IP addresses will change
• Hostnames may change
• OS versions may differ
• VMs are rebuilt rather than cloned

Guiding Principles

• Avoid copying kernel, bootloader, and hardware-specific files
• Prefer reinstalling packages over copying binaries
• Migrate data and configuration intentionally
• Treat /etc as selective, not wholesale

Migration Strategies Overview

Recommended Migration Workflow

1. Prepare the Source VM

Capture Installed Packages

By capturing the packages installed on the source VM you can ensure that you install the same packages and versions on your destination VM.

Debian / Ubuntu

dpkg --get-selections > packages.txt

RHEL / CentOS / Rocky / Alma

dnf repoquery --installed --qf "%{name}" > packages.txt

Store packages.txt somewhere safe so you can use it again later.

2. Provision the Destination VM

• Install a fresh OS

• Patch to latest updates

• Configure as needed:

  • Networking
  • Hostname
  • SSH access
  • Timezone / NTP

3. Reinstall Packages on Destination VM

Debian / Ubuntu

dpkg --set-selections < packages.txt
apt-get dselect-upgrade

RHEL-based

dnf install $(cat packages.txt)

⚠️

IMPORTANT: Package names may differ between OS versions. Review failures carefully.

Data Migration

4. Migrate User Data (Safe)

rsync -aAXv /home/ target:/home/

Optional shared paths:

rsync -aAXv /data/ target:/data/
rsync -aAXv /srv/ target:/srv/

5. Migrate Application Data (Selective)

Common application data locations:

Example:

rsync -aAXv /etc/myapp /var/lib/myapp target:/etc/

⚠️ Do NOT copy all of /etc blindly

Post-Migration Checklist

• Verify users and permissions
• Confirm services start correctly
• Review /etc/fstab
• Review /etc/hosts
• Validate cron jobs
• Test application functionality
• Update firewall rules if needed

Paths That Likely Should Never Be Migrated

These directories are not real data in the traditional sense. They are either virtual filesystems, runtime state, or host-specific artifacts that are recreated automatically at boot. Copying them to another system (especially a different VM or OS version) can cause boot failures, device conflicts, or subtle instability.

Summary

• Copy data, not operating systems
• Reinstall packages, don’t migrate binaries
• Treat configuration as curated
• Prefer reproducibility over speed

Following this approach results in a clean, supportable, and upgrade-safe Linux VM migration.