Moving a Drupal Site to a New Server Without Losses

Moving Drupal to a new server means moving three parts: the core and theme files, the sites/default/files directory with uploaded content, and the MySQL database. Skip even one part and the site will load with errors or missing images.

When you need to move Drupal to a new server

Typical reasons: the old host does not support PHP 8.3, which Drupal 10 and 11 require, you need to move from shared hosting to a VDS because of growing load, or the lease on the current server is ending. Before the move, check the Drupal version with drush status and record the PHP version, MySQL version and the list of enabled modules.

What to prepare before the move

The new server must have PHP 8.3 with the gd, pdo_mysql, mbstring, xml and opcache extensions, plus MySQL 8 or MariaDB 10.6 and Composer 2. Check the minimum requirements table:

Create an empty database on the new server and a user with full rights on it — you will need this at the dump import step.

How to move the site files

Move files with rsync — it preserves permissions and transfers only changes on a repeat run, which is handy for the final sync before the DNS switch. A detailed comparison of rsync, SCP and FTP is in the article moving site files.

rsync -avz --progress -e "ssh -p 22" /var/www/drupal/ user@newserver:/var/www/drupal/

After copying, check permissions: the sites/default/files directory must belong to the web server user and have 755 permissions on directories and 644 on files. Temporarily make sites/default/settings.php writable with chmod 644 sites/default/settings.php so you can edit the database connection settings.

How to export and import the database

Export with drush — it handles Drupal's cache tables correctly and does not carry over temporary clutter:

drush sql-dump --result-file=../drupal_backup.sql --gzip

On the new server, create the database and import the dump:

mysql -u drupal_user -p drupal_db < drupal_backup.sql

If the dump is compressed, unpack it first with gunzip drupal_backup.sql.gz. General principles of moving MySQL, including large databases and replication, are covered in the article moving a MySQL database.

Configuring settings.php after the move

In sites/default/settings.php, update the $databases array: database name, user, password and host. Also check the $settings['trusted_host_patterns'] parameter — if it is still limited to the old domain, Drupal returns a 500 error the first time the site opens on the new server.

$databases['default']['default'] = [
  'database' => 'drupal_db',
  'username' => 'drupal_user',
  'password' => 'new_password',
  'host' => 'localhost',
  'driver' => 'mysql',
];

After editing, restore the permissions with chmod 444 sites/default/settings.php. Then clear the cache and import the synced configuration:

drush cr
drush config:import -y

How to test the site and switch DNS without downtime

Before switching the domain, open the site on the new server by IP address, overriding the host in the local machine's /etc/hosts file — this lets you test without any risk to the live site. Make sure the homepage loads, the admin login at /user/login works, and images from sites/default/files are served correctly.

Once the test passes, lower the domain's A record TTL to 300 seconds in advance, and after switching check propagation with dig +short example.com from several DNS servers. A detailed scheme for a safe switch without downtime is in the article switching hosting without downtime.

Drupal migration checklist

• PHP, MySQL and module versions match Drupal's requirements.
• The sites/default/files directory is copied in full, permissions 755/644.
• The database dump imported without errors, tables are in place.
• The $databases array and trusted_host_patterns in settings.php are updated.
• The drush cr and config:import commands ran without warnings.
• The site was tested by IP before the DNS switch.

Run the final check after the domain switch using the general checklist in the article post-migration site checklist.