Moving a site between hosts #

This page is for system administrators who move an Exponential 6 site from one machine to another, between hosts or inside one host, at the same version. It answers: what you copy, what you fetch again, which settings name the old machine, and in which order the commands run.

When the version also changes, read From older Exponential versions first; the process for the customer side is on Migrating customers to your hosting.

Contents #

1. What moves and what does not
2. Before the move
3. The move, step by step
4. Settings that name the old machine
5. Checks afterwards

What moves and what does not #

Source of the list: 10.9 Backups and restore.

Before the move #

• The target meets the requirements, with the same PHP major version or a newer supported one (Requirements at a glance).
• The same database engine is installed, or you plan an engine change (Changing the database engine).
• The PHP extensions the site uses are installed on the target.
• The DNS time-to-live of the site's domains is lowered.
• A restore of the latest backup on the target has been tested once.

The move, step by step #

1. Maintenance on, on the old machine, so no write happens between the database and the file backup:

   php bin/php/maintenance.php on --message="Moving to a new server" --until=1h --allow-root-user

2. Back up the database with the engine's tool and the files:

   tar czf files-$(date +%F).tar.gz var/storage settings/override settings/siteaccess

3. Put the code in place on the target: the same tag of the kernel (git checkout v6.0.<n>) and composer install, plus custom extensions from Git.

4. Restore the database and unpack the files; set the owner and mode the target's web server or engine needs (Writable directories and permissions).

5. Adjust the settings listed below.

6. Regenerate autoloads and clear caches:

   php bin/php/ezpgenerateautoloads.php -e
   php bin/php/ezcache.php --clear-all --allow-root-user

7. Start the engine (or reload PHP-FPM), clear Velocity's response cache if it serves the site (php bin/php/console exp:velocity cache clear --apply --allow-root-user).

8. Test through a hosts-file entry, then switch DNS.

9. Leave the old machine in maintenance mode until the DNS change has reached everyone. Maintenance mode lives in var/maintenance.json on the old machine, which the file backup above does not include, so the target is not in maintenance mode unless you switch it on there. If you did (to test in peace), end it with php bin/php/maintenance.php off --allow-root-user (10.9).

Settings that name the old machine #

Checks afterwards #

• Front page and administration load on the target.
• Sign in, publish a test object, upload an image, search.
• Compare row counts of ezcontentobject, ezcontentobject_tree and ezcontentobject_attribute with the old database (Database support).
• The cron jobs run on the target, and no longer on the old machine (Cron jobs).
• Mail arrives.
• The log viewer shows no new errors (Log viewer and rotation).

Related pages #

• Restore from backup (runbook)
• What to back up
• Go-live checklist for a customer site
• Migrations versus migrating a site
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.