How to Prepare a Linux Server for Migration

03 Sep 2026, 10:18:23
Migrating a Linux server to a new physical machine or VPS is not simply a matter of copying files. You need to migrate the data, preserve the configuration, restore services, verify permissions and network settings, and then make sure that applications work correctly on the new server.
Proper preparation helps reduce downtime and avoid a situation where the data has been preserved but the web server, database, or other services do not work because their configuration is missing.

1. Determine What Is Used on the Server

Before migration, make a list of the installed components and services.
Start by checking the operating system information:
cat /etc/os-release
uname -aCheck the CPU and RAM:
lscpu
free -hInformation about disks and file systems can be obtained with:
lsblk
df -hNext, determine which services are currently running:
systemctl --type=service --state=runningYou should also check active network connections and open ports:
ss -tulpnThis will help you determine which services are actually being used and what needs to be installed or configured on the new server.
For example, the server may be running:
  • Nginx or Apache;
  • PHP and PHP-FPM;
  • MySQL or MariaDB;
  • Redis or Memcached;
  • Docker or Podman;
  • a mail server;
  • a VPN;
  • a DNS server;
  • control panels;
  • custom systemd services.
Do not migrate the server blindly. First determine its actual configuration.

2. Separate Data from Configuration

One common migration mistake is assuming that it is enough to copy user files.
A server has at least two different categories of information:
Data:
  • website files;
  • databases;
  • user-uploaded files;
  • documents;
  • media files;
  • application data.
Configuration:
  • web server settings;
  • PHP configuration;
  • database configuration;
  • SSH configuration;
  • firewall rules;
  • cron jobs;
  • systemd configuration;
  • network interfaces;
  • mount points;
  • users and groups;
  • SSL certificates;
  • application settings.
For example, website data may be stored in /var/www/example.com, while the Nginx configuration may be located in /etc/nginx/.
After reinstalling the operating system, website files can be restored from a backup, but without the configuration, the web server may not know which domain it should serve or which directory it should use for the website files.
Therefore, during migration, you need to preserve not only the data but also the configuration.

3. Check Additional Disks

If the server uses multiple disks, first determine where the data is stored.
lsblk -fAdditionally:
df -hTTo view the current mount points:
findmntPay particular attention to:
cat /etc/fstabIf the data is stored on a separate disk, reinstalling the operating system itself should not delete the data on that disk, provided that the disk is not formatted or used to install the new OS.
However, after reinstalling the operating system, you will need to configure access to this disk again: the file system, mount point, file ownership, permissions, and the services that use the data stored on it.
For example, if a website uses  /data/www, after installing the new operating system you need to make sure that the disk is mounted at  /data again.

4. Check Used Disk Space

Before migration, determine how much data needs to be transferred.
df -hTo find directories that use the most disk space:
du -xh --max-depth=1 /var | sort -hFor the home directory:
du -xh --max-depth=1 /home | sort -hThis is especially important when migrating to a server with less disk space.
Do not forget about:
  • logs;
  • backups;
  • Docker images;
  • cache;
  • temporary files;
  • old application versions;
  • database dumps.
Before migration, you can remove unnecessary data so that it does not have to be transferred to the new server.

5. Save the Configuration

Before starting the migration, it is recommended to save the configuration files of the services in use.
For example:
/etc/nginx/
/etc/apache2/
/etc/php/
/etc/mysql/
/etc/ssh/
/etc/systemd/
/etc/fstab
The exact directories depend on the installed software and Linux distribution.
It is also a good idea to save the firewall configuration.
For systems using UFW:
ufw statusFor nftables:
nft list rulesetFor iptables:
iptables-saveDo not migrate configuration files without checking compatibility. For example, an Nginx, PHP, or MariaDB configuration from an older software version may require changes after installing a newer version.

6. Save the List of Installed Packages

After the migration, it is useful to know what software was installed on the old server.
On Debian/Ubuntu, you can use:
dpkg --get-selections > packages.txtYou can also get a list of installed packages with:
apt list --installed > packages.txtOn RPM-based systems:
rpm -qa > packages.txtThis will help determine which additional packages need to be installed on the new server.

7. Check Users and Groups

When migrating applications, you need to consider not only the files but also their ownership.
Check users:
cat /etc/passwdGroups:
cat /etc/groupPay particular attention to system users under which services run.
For example:
  • www-data;
  • nginx;
  • apache;
  • mysql;
  • redis.
If the UID or GID values are different on the new server, access problems may occur after migration.
You can check the owner of a file with:
ls -la /path/to/file

8. Preserve SSH Access

Before migration, make sure that you will not lose access to the server.
Check the SSH configuration:
sshd -TAnd the configuration file:
cat /etc/ssh/sshd_configCheck authorized keys:
cat ~/.ssh/authorized_keysFor root:
cat /root/.ssh/authorized_keysIf the new server uses a different IP address, prepare the new access method in advance and verify the connection before shutting down the old server.
It is not recommended to perform a migration with only one method of access available.

9. Check Cron Jobs

Automated tasks are often forgotten during migration.
For the current user:
crontab -lFor another user:
crontab -u USERNAME -lAlso check the system directories:
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
ls -la /etc/cron.weekly/If the application uses cron for backups, file cleanup, queue processing, or other tasks, these jobs must be restored on the new server.

10. Check systemd Services

If the server uses custom services, determine which services are enabled to start automatically:
systemctl list-unit-files --state=enabledFor a specific service:
systemctl status SERVICE_NAMEYou can view its configuration with:
systemctl cat SERVICE_NAMEPay particular attention to custom unit files.
For example:
/etc/systemd/system/After migration, it is not enough to copy the application itself. You also need to restore the service, its startup parameters, user, and dependencies.

11. Prepare the Databases

Databases should preferably be migrated using the database management system's standard tools.
For MySQL/MariaDB, you can create a dump:
mysqldump -u root -p --all-databases > all_databases.sqlAfter creating the dump, check the file:
ls -lh all_databases.sqlIf the database is large, a more appropriate migration method may be required, such as a separate dump for each database or physical replication.
Also remember to migrate database users and access privileges.
After restoring the database on the new server, verify:
  • that all databases are present;
  • that all tables are present;
  • users;
  • access privileges;
  • character encodings;
  • application connections.

12. Transfer Files Using rsync

For large amounts of data,  rsync is a convenient tool.
Example:
rsync -aHAX --info=progress2 /source/ user@NEW_SERVER:/destination/Before the final migration, you can perform an initial synchronization.
This is especially useful if the old server continues to operate. Most files can be transferred in advance, and during the final synchronization, only the changes made since the initial transfer need to be copied.
If necessary, you can use additional parameters:
rsync -aHAX --delete --info=progress2 /source/ user@NEW_SERVER:/destination/Be especially careful with the --delete parameter: files that are missing from the source may be deleted from the destination server.

13. Check Network Settings

Before switching the server, save the current network configuration.
Useful commands:
ip addr
ip route
cat /etc/resolv.confDepending on the distribution, network settings may be managed by NetworkManager, Netplan, systemd-networkd, or other system components.
Do not blindly copy network configuration files from the old server to the new one. IP addresses, interface names, gateways, and other parameters may be different.

14. Check DNS

If the server's IP address changes after migration, prepare the DNS configuration in advance.
Check the domain records:
  • A;
  • AAAA;
  • MX;
  • CNAME;
  • TXT;
  • SPF;
  • DKIM;
  • DMARC.
If a mail server is used, separately check the PTR/rDNS record.
Before switching, you can reduce the TTL of DNS records so that changes propagate faster.
However, keep in mind that reducing the TTL does not guarantee an immediate update for all clients: some resolvers and systems may cache records for longer.

15. Prepare SSL Certificates

If certificates are issued automatically, check the certificate issuance mechanism in advance.
For example, with Let's Encrypt, it is important that the new server is accessible through the required domains and can successfully pass the ACME challenge.
After migration, check:
curl -I https://example.comMake sure that the certificate matches the domain and has a valid expiration date.

16. Prepare the New Server

After analyzing the old server, you can prepare the new system.
You need to install:
  • the operating system;
  • required packages;
  • a web server;
  • PHP;
  • a database management system;
  • additional services;
  • a firewall;
  • applications;
  • required systemd services.
It is better to install software versions that are supported rather than trying to completely copy the old system.
For example, when moving from one Ubuntu version to another, the configuration of some components may change. Therefore, migration is a good opportunity to check compatibility and remove outdated components.

17. Configure Disks on the New Server

If additional disks are used, check them first:
lsblk
lsblk -fCreate the required mount points:
mkdir -p /dataAfter configuring  /etc/fstab, check the configuration:
mount -aThen:
df -hBefore rebooting the server, it is especially important to make sure that  /etc/fstab does not contain any errors. An incorrect entry can cause problems during system boot.

18. Test the New Server Before Changing DNS

You do not have to immediately point the domain to the new IP address.
For preliminary website testing, you can temporarily add an entry to the  /etc/hosts file on your computer:
NEW_SERVER_IP example.com
After that, requests to example.com from your computer will be directed to the new server.
Check:
  • website availability;
  • HTTPS;
  • authentication;
  • file uploads;
  • database operation;
  • API;
  • cron jobs;
  • background tasks;
  • email delivery;
  • operation of all required services.
This allows you to identify problems before the new server becomes available to users.

19. Perform the Final Synchronization

If the old server continued operating while the new server was being prepared, the latest changes must be transferred before switching.
Typical sequence:
  1. stop the applications or put them into maintenance mode;
  2. stop services that modify data;
  3. perform a final database dump;
  4. transfer changed files;
  5. restore or update the database on the new server;
  6. check file permissions;
  7. start the services;
  8. perform testing;
  9. change DNS.
The main goal is to minimize the period during which data can be changed simultaneously on both servers.

20. Check the Server After the Switch

After changing DNS, make sure that the new server is actually handling requests.
Check HTTP:
curl -I https://example.comCheck DNS:
dig example.comCheck services:
systemctl --type=service --state=runningCheck available disk space:
df -hCheck the system load:
uptimeYou should also check the system logs:
journalctl -p warning -bAnd the logs of individual services.
During the first few hours after migration, it is recommended to monitor CPU, RAM, disk, and network usage more closely.

21. Do Not Remove the Old Server Immediately

After a successful switch, do not immediately delete the old system.
It is better to keep it available for some time, depending on the importance of the project, and make sure that:
  • all data has been migrated;
  • websites are working;
  • databases are up to date;
  • cron jobs are running;
  • email is working;
  • backups are configured;
  • users are not encountering errors.
Once the successful migration has been confirmed, the old server can be shut down or removed.

What to Check Before Migration

Before starting the migration, the following checklist can be useful:
  • The OS version has been identified.
  • CPU, RAM, and disks have been checked.
  • A list of used services has been created.
  • Directories containing data have been identified.
  • Additional disks have been checked.
  • Service configurations have been saved.
  • Users and SSH keys have been saved.
  • Cron jobs have been checked.
  • systemd services have been checked.
  • Backups have been created.
  • Database dumps have been created.
  • The new server has been prepared.
  • Disks and mount points have been configured.
  • Required software has been installed.
  • DNS has been prepared.
  • SSL certificates have been checked.
  • The new server has been tested.
  • Final synchronization has been completed.
  • Services and logs have been checked after the switch.

Conclusion

Preparing a Linux server for migration consists of several stages: inventory, backup, configuration preservation, preparation of new hardware or a VPS, data transfer, and final testing.
The key point is not to treat migration as simply copying files. Data, configuration, and the operating system are different components of a server. If data is stored on a separate disk, it can survive an OS reinstallation, but after installing the new system, you will still need to restore mount points, users, permissions, and service configurations.
The best approach is to prepare the new server and transfer most of the data first, then perform a final synchronization and switch DNS only after everything has been tested. This can significantly reduce downtime and lower the risk of data loss or service failures.

SSD Storage VPS

Browse Configurations

Windows SSD Storage VPS

Browse Configurations

Premium Dedicated Servers

Browse Configurations