What is server migration and how does it work

Server migration is the process of moving websites, databases, email, and configurations from one server to another. It happens more often than most people realize. Hosting providers migrate customers between servers routinely – to rebalance load, decommission aging hardware, upgrade operating systems, or move accounts to faster infrastructure. You might also trigger a migration yourself by switching hosting providers, upgrading your plan, or moving from shared hosting to a VPS.

The term covers several different scenarios, and the complexity varies dramatically between them. Moving a single WordPress site to a new host is a server migration. So is moving 500 accounts from a server being retired. And so is migrating an entire fleet from one operating system to another. The principles are the same at every scale: copy the data, reconfigure the environment, verify everything works, then switch traffic over.

Types of server migration#

Same provider, different server

The most common type. Your hosting provider moves your account from one physical or virtual server to another. This might happen because the current server is reaching capacity, because newer hardware is available, or because the provider is consolidating infrastructure.

From your perspective, this migration should be transparent. The provider handles moving your files, databases, and configurations. Your domain stays the same. The IP address may change (requiring a DNS update), but the provider usually handles this too. If the migration goes well, you do not notice it happened.

Different provider (hosting migration)

You are switching from one hosting company to another. This is the most hands-on type of migration because you (or the new provider) must coordinate the transfer of files, databases, email, DNS, and SSL certificates between two unrelated systems with different configurations.

For a detailed walkthrough of migrating WordPress specifically, see How to migrate WordPress to another hosting provider. That guide covers the file transfer, database export/import, URL replacement, and DNS cutover in step-by-step detail.

Shared hosting to VPS

Moving from a shared hosting account to a VPS (Virtual Private Server) or dedicated server. This is more than just copying files – you are moving from a managed environment where the hosting provider configures the web server, PHP, MySQL, and email to an environment where you manage all of that yourself (unless you choose a managed VPS).

The migration involves not just moving data but also recreating the entire server configuration: installing and configuring Nginx or Apache, PHP-FPM, MySQL, email services, SSL certificates, firewall rules, and cron jobs.

Operating system migration

Moving a server from one operating system to another – CentOS to Rocky Linux, Ubuntu 20.04 to Ubuntu 24.04, or any other OS transition. This type of migration usually involves setting up a fresh server with the new OS, reinstalling all services, then migrating the data. In-place OS upgrades are possible but risky for production servers because a failed upgrade can leave the system in an unrecoverable state.

Cloud migration

Moving from traditional hosting (physical or virtual servers in a data center) to cloud infrastructure (AWS, Google Cloud, Azure). Cloud migration adds complexity because the architecture is fundamentally different – instead of a single server running everything, cloud environments typically distribute services across multiple managed services (load balancers, managed databases, object storage, CDNs).

What gets migrated#

A complete server migration includes everything needed for your sites to function on the new server.

Files

All website files need to transfer to the new server. For a WordPress site, this means the entire WordPress installation including wp-content (themes, plugins, uploads), configuration files, and any custom files outside the WordPress directory.

File transfer methods depend on access:

• rsync over SSH – the best method for server-to-server transfers. Compresses data during transfer, handles interruptions (resume where it left off), and preserves file permissions and timestamps.
• SCP – secure copy over SSH. Works for one-time transfers but does not handle incremental updates or resume after interruptions.
• SFTP – transfers through your local machine. Slowest option because everything passes through your internet connection.
• Direct server-to-server pull – the new server connects to the old server and pulls data directly. Fastest for large transfers because data moves between servers over data center connections.

File permissions and ownership must be set correctly on the new server. Different servers may run PHP under different users, so files that worked on the old server may be unreadable on the new one until ownership is adjusted. See Linux file permissions: chmod and chown explained for how ownership and permissions work.

Databases

MySQL databases need to be exported from the old server and imported on the new one. The standard process is:

# Export on the old server
mysqldump -u root -p --single-transaction --routines --triggers database_name > database.sql

# Transfer the dump file
rsync -avz database.sql user@new-server:/tmp/

# Import on the new server
mysql -u root -p database_name < /tmp/database.sql

For large databases (over 1 GB), compress the dump during transfer:

mysqldump -u root -p database_name | gzip | ssh user@new-server "gunzip > /tmp/database.sql"

Database users and their privileges also need to be recreated on the new server. The MySQL user accounts are stored in the mysql system database and are not included in a database dump. You need to create the users and grant the same privileges on the new server. See How to create a database in MySQL for the complete user and privilege workflow.

If the WordPress site URL changes during the migration, a serialization-aware search and replace is required after importing the database. See the URL replacement section in How to migrate WordPress to another hosting provider for why this matters and how to do it correctly.

Email

If the server handles email (receiving or sending), email migration adds significant complexity:

• Mailboxes – all email messages need to transfer. Tools like  imapsync  copy messages between IMAP servers.
• Email accounts and passwords – need to be recreated on the new server.
• MX records – need to be updated to point to the new server after migration.
• SPF, DKIM, and DMARC records – need to be updated if the sending IP changes. See What is SPF and how to set up an SPF record and What is DKIM and how to set it up for the DNS configuration.

The gap between updating MX records and DNS propagation completing means some email may be delivered to the old server during the transition. Running both servers simultaneously during propagation prevents lost email.

SSL certificates

SSL certificates may or may not transfer depending on the type:

• Let’s Encrypt certificates – do not transfer. Generate new certificates on the new server. This takes seconds with automated tools like certbot.
• Purchased certificates – can be transferred by copying the certificate file, private key, and chain file to the new server.
• Hosting-provided certificates – usually cannot be transferred and need to be reprovisioned on the new platform.

The site should not serve HTTPS with an invalid certificate at any point during the migration. Either provision certificates before the DNS switch (using DNS validation instead of HTTP validation) or accept a brief moment of HTTP-only access during the transition.

Cron jobs

Scheduled tasks (cron jobs) running on the old server need to be recreated on the new one. List existing cron jobs:

crontab -l

Also check system-level cron directories:

ls /etc/cron.d/
ls /etc/cron.daily/

WordPress sites using WP-CLI cron commands need those commands recreated on the new server with the correct paths. For a complete guide to setting up WordPress cron, see How to run a WP-CLI command with cron.

Server configuration

The web server configuration, PHP settings, and firewall rules need to be recreated or migrated. This includes:

• Nginx or Apache virtual host configurations – server blocks defining each site’s document root, SSL paths, redirects, and custom rules.
• PHP configuration – PHP version, memory limits, execution timeouts, and installed extensions. Different servers may have different PHP versions or extensions available. For finding and checking PHP configuration, see How to check your PHP version and find php.ini.
• Firewall rules – IP-based access rules, rate limiting, and port configurations.
• Custom software – any non-standard packages or services running on the old server.

The migration process#

1. Audit the current server

Before migrating anything, document what exists on the current server:

• How many sites and which domains
• Database sizes and names
• PHP version per site
• Custom configurations (redirects, rewrites, access restrictions)
• Cron jobs
• Email accounts (if applicable)
• SSL certificate type per domain
• Total disk usage

This audit prevents surprises during migration and gives you a checklist to verify against on the new server.

2. Set up the new server

Configure the new server to match the old one’s capabilities. Install the same PHP version (or newer if compatible), the same MySQL version, the same web server, and any custom packages. Test the configuration with a sample site before migrating production data.

3. Reduce DNS TTL

Lower your DNS TTL to 300 seconds (5 minutes) at least 24-48 hours before the migration. This means that when you update DNS to point to the new server, most DNS caches expire within 5 minutes rather than the usual hours. After migration is complete, raise the TTL back to a normal value.

4. Transfer data

Copy files and databases to the new server while the old server is still active and serving traffic. This is the “pre-sync” phase – you are copying the bulk of the data ahead of time so the final cutover is fast.

# Initial file sync
rsync -avz --progress /home/ user@new-server:/home/

# Database exports
mysqldump -u root -p --all-databases > all-databases.sql

5. Final sync and cutover

During a maintenance window (ideally during low-traffic hours):

1. Freeze changes on the old server (enable maintenance mode on WordPress sites)
2. Final rsync to catch any files changed since the initial sync: rsync -avz --delete /home/ user@new-server:/home/
3. Final database export and import to capture any data changes
4. Update DNS to point to the new server’s IP address
5. Provision SSL certificates on the new server if not already done
6. Verify each site loads correctly on the new server

6. Monitor and verify

After DNS propagation, monitor the new server for:

• All sites loading correctly
• SSL certificates valid
• Email delivery working (if applicable)
• Cron jobs executing on schedule
• Error logs clean (no unexpected PHP errors or missing files)
• Database connections stable

Keep the old server running for at least a week after migration. If anything goes wrong, you can quickly revert DNS back to the old server.

Common migration problems#

DNS propagation delays

DNS changes do not take effect instantly worldwide. During propagation, some visitors reach the old server and some reach the new one. This is why lowering TTL before migration is important, and why both servers should be operational during the transition.

File permission mismatches

The new server may run PHP under a different user than the old one. Files owned by the old user are unreadable by the new server’s PHP process. After transferring files, set the correct ownership:

chown -R newuser:newuser /path/to/website/

Database character set issues

If the old server uses a different MySQL version or default character set than the new one, the import may produce character encoding errors. Always specify the character set explicitly during export:

mysqldump --default-character-set=utf8mb4 database_name > dump.sql

And during import:

mysql --default-character-set=utf8mb4 database_name < dump.sql

Missing PHP extensions

A plugin that worked on the old server may fail on the new one because a required PHP extension is not installed. Common missing extensions: imagick (image processing), intl (internationalization), sodium (encryption), zip (archive handling). Check the PHP error log after migration for missing extension errors.

Hardcoded paths

Plugins or themes that store absolute file paths in the database or configuration files will break if the directory structure on the new server differs. A search-replace on the database fixes database-stored paths:

wp search-replace '/old/server/path' '/new/server/path' --all-tables

Zero-downtime migration#

True zero-downtime migration requires both servers serving traffic simultaneously during the transition. The approach:

1. Sync data continuously using rsync in a cron job on the new server
2. Set up the new server as a working copy of the old one
3. Switch DNS to the new server
4. Run a final sync after DNS propagation completes to catch any data written to the old server during propagation
5. Shut down the old server once all traffic has moved

For WordPress sites, the final sync needs to handle database changes carefully. If a visitor posted a comment or placed an order on the old server during DNS propagation, that data must be captured in the final sync. This is the hardest part of zero-downtime migration and is one reason managed migration tools exist.

How Hostney handles server migration#

When Hostney needs to move accounts between servers (for hardware upgrades, capacity rebalancing, or OS upgrades), the migration is handled at the platform level.

Container portability. Each hosting account runs in its own isolated container. Migrating an account means moving the container – files, configurations, and all – to the new server. The container’s internal environment is identical on both servers, so there are no permission mismatches, path differences, or configuration incompatibilities to resolve.

Database migration. MySQL databases are exported and imported with character set preservation. Database users and privileges are recreated on the new server automatically. The site’s wp-config.php does not need changes because the database connection uses localhost on both servers.

SSL reprovisioning. SSL certificates are automatically provisioned on the new server before the DNS switch. Visitors never see a certificate error during migration.

DNS management. If DNS is managed through the Hostney control panel, the IP address update is handled as part of the migration. If DNS is managed externally, you receive the new IP address to update your records.

Migration plugin for incoming sites. If you are migrating to Hostney from another provider, the Hostney Migration plugin handles the transfer. Install the plugin on your source site, connect it with a migration token from the control panel, and the system pulls your files and database server-to-server. URL replacement, wp-config.php generation, and file permissions are handled automatically. For the full process, see How to migrate WordPress to another hosting provider.

Summary#

Server migration moves websites, databases, email, and configurations from one server to another. Whether you are switching hosting providers, upgrading infrastructure, or your provider is rebalancing servers, the process follows the same pattern: audit the current state, prepare the new server, transfer data, update DNS, and verify everything works.

The most common problems are DNS propagation delays (lower TTL before migrating), file permission mismatches (set correct ownership on the new server), character set issues during database import (specify utf8mb4 explicitly), and missing PHP extensions. Keep the old server running for at least a week after migration as a fallback. For WordPress-specific migration details including the serialization-aware URL replacement that most migrations get wrong, see How to migrate WordPress to another hosting provider.