How to Migrate a Website to a New Server

Moving a website to a new server, whether for better performance, lower cost, or to leave a host you are unhappy with, is routine work, but it has plenty of places to trip. Missed files, a database exported mid-order, email that silently stops arriving, a certificate that fails on day one. This guide walks through a website migration for a typical PHP and MySQL site (WordPress, Laravel, Magento and similar) on Linux, in an order designed to keep downtime close to zero.

Step 1: Take stock of the old server

Before touching anything, write down what the site actually depends on:

Software versions: PHP version and extensions (php -v, php -m), database engine and version, web server and any special modules.
Files: the document root, plus anything outside it such as upload folders, private storage or .env files.
Databases: names, users and their permissions.
Scheduled jobs: crontab -l for the site user and root.
Web server configuration: virtual host files, rewrites, redirects, .htaccess rules, custom headers.
Email: is mail hosted on this server, or only sent from it? Where do the MX records point?
DNS: which provider hosts the zone, and a full copy of current records. Our DNS lookup tool can list them.
SSL certificates: how they are issued and renewed.
Integrations: payment gateways, APIs or partners that allow-list your server's IP address.

Step 2: Lower the DNS TTL

At least a day before the move, reduce the TTL (time to live) on the A, AAAA and any relevant CNAME records to 300 seconds. When you switch later, resolvers worldwide will pick up the new address within minutes instead of hours.

Step 3: Prepare the new server

Install the same major versions of PHP, the database and required extensions, or deliberately newer ones you have tested with. Then apply your baseline security: updates, a firewall allowing only SSH, HTTP and HTTPS, and key-only SSH login. Create the site's system user, directories, database and database user:

CREATE DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'shop'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON shop.* TO 'shop'@'localhost';

Copy the web server configuration and adapt paths. Do not request the Let's Encrypt certificate yet if it uses HTTP validation; that needs DNS to point at the new server. Either copy the existing certificate files across temporarily or use DNS-based validation.

Step 4: Copy the files

rsync over SSH is the most reliable tool. It preserves permissions and timestamps and, crucially, can be re-run to copy only what has changed. Run it from the new server:

rsync -aHAX --info=progress2 \
  olduser@old.example.net:/var/www/shop/ /var/www/shop/

The trailing slashes matter: they copy the contents of the folder into the destination. Run this initial copy well before the cutover; large upload folders can take hours.

Step 5: Copy the database

Dump on the old server and import on the new one:

# on the old server
mysqldump --single-transaction --routines --triggers shop | gzip > shop.sql.gz

# on the new server, after copying the file across
gunzip < shop.sql.gz | mysql shop

For PostgreSQL, use pg_dump -Fc and pg_restore. Update the application's configuration file with the new database credentials if they differ.

Step 6: Test before anyone else sees it

Point only your own computer at the new server by editing your hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows):

198.51.100.40   example.com www.example.com

Now browse the real domain and test thoroughly: home page, internal pages, images, login, admin area, contact forms, search, checkout with a test payment, and file uploads. Check the web server and PHP error logs on the new server as you go. Remove the hosts entry when finished.

Step 7: Cut over

Freeze changes. Put the old site in maintenance mode or pause orders and comments, so no new data is written there.
Final sync. Re-run the rsync command (fast, as only changes move) and take a fresh database dump and import.
Switch DNS. Update the A (and AAAA) records to the new server's IP address.
Issue certificates once DNS resolves to the new server, and confirm them with our SSL checker.
Re-enable the site on the new server and check it through public DNS.
Monitor propagation with a DNS propagation checker. Leave the old server in maintenance mode rather than switching it off, so stragglers see a message, not an error.

Step 8: After the move

Recreate cron jobs and confirm they run.
Test outgoing email: contact forms, order confirmations, password resets. If the server sends mail directly, update SPF records with the new IP and set reverse DNS.
Update IP allow-lists with payment gateways and partners.
Set up backups and monitoring on the new server, and verify the first backup.
Watch error logs and performance for a few days.
Raise the DNS TTL back to a normal value, such as one hour.
Decommission the old server only after a final backup and a week or two of stable running.

Common website migration gotchas

Hard-coded URLs or IPs in configuration or the database. For WordPress domain changes, use a serialisation-aware tool such as wp search-replace, not a plain SQL replace.
File ownership: files owned by the wrong user cause upload and cache errors. Fix with chown -R for the site user.
Missing PHP extensions such as intl, gd or imagick, causing blank pages or errors.
Email MX records changed by accident when copying DNS between providers.

If you would rather hand the move to someone who does it routinely, migrations are part of our server management work.

Key takeaways

Inventory everything the site depends on, including cron, email and IP allow-lists.
Lower DNS TTLs a day ahead, and copy files with rsync early.
Test on the new server with a hosts-file override before changing public DNS.
Freeze, final sync, switch DNS, issue certificates, then verify and monitor.

Servers & Hosting articles