Migrating a Website to a New Cloud Server

Before you touch anything

1. Take a full backup of files and database, and copy it somewhere off both servers.
2. Record the current software versions: web server, language runtime, database engine, extensions.
3. List every cron job on the old server.
4. List every certificate and its expiry.
5. Note any IP allow-lists on external services that reference the old address.
6. Note the current DNS TTL and lower it to 300 seconds now, at least 48 hours before cutover.
7. Write down what “working” looks like — the pages and functions you will check afterwards.

The IP allow-list item catches people regularly. Payment gateways, mail relays and partner APIs often restrict by source address, and the new server has a new one.

Build the new server

1. Match the software versions from the old server, or upgrade deliberately as a separate, tested change.
2. Configure the server fully — firewall, users, key-only SSH, automatic security updates.
3. Install and configure the web server and runtime.
4. Create the database and user with the same names, to avoid configuration changes.
5. Set up the reverse proxy and obtain certificates using a temporary hostname or DNS validation.
6. Configure backups on the new server before it holds production data.

Do not combine a version upgrade with a server move. If something breaks you will not know which change caused it.

Move the data

1. Sync files with rsync — an initial pass while the site is live, then a final pass at cutover.
2. Export the database with the engine’s own dump tool, not by copying files.
3. Import and verify: row counts on the main tables, and a few spot checks.
4. Copy configuration files, environment files and secrets separately and securely.
5. Recreate cron jobs, and confirm the paths and users match.
6. Copy any uploads directory in full; it is frequently the largest and most easily missed part.

The two-pass rsync approach means the final sync at cutover moves only recent changes, which takes seconds rather than hours.

Test before DNS

This is the step that makes the difference. Point your own machine at the new server without changing public DNS:

• Add an entry to your local hosts file mapping the domain to the new IP address.
• Load the site and click through the important paths.
• Test forms, logins, uploads, payment flows and email sending.
• Check error logs for anything that appears only under real use.
• Verify certificates, redirects and canonical URLs.
• Test on a mobile device using the same technique, or a temporary subdomain.

Everything must work here before DNS changes. After the switch, problems are visible to users.

Cutover

1. Put the old site into maintenance mode, or accept a short window of divergence.
2. Run the final file sync.
3. Take a final database dump and import it.
4. Update DNS to the new address.
5. Watch traffic arrive at the new server and error logs stay quiet.
6. Keep the old server running, unchanged, for at least a week.

Do not delete the old server quickly. It costs a few days of hosting and it is the only real rollback you have.

Afterwards

• Raise the DNS TTL back to a normal value once traffic has settled.
• Verify backups are running on the new server and restore one to confirm.
• Check certificate auto-renewal actually works, ideally by forcing a renewal.
• Confirm every cron job has run at least once on its normal schedule.
• Check outbound email deliverability — SPF and DKIM records may reference the old server.
• Monitor for a week before decommissioning the old environment.

Email is the most commonly broken thing after a server move, because SPF records naming the old IP address silently start failing.

Common questions

Where to go next

See the first hour on a new cloud server and planning a cloud migration.