What is server migration and how does it work

Short answer: Server migration is the process of moving websites, databases, email, and configurations from one server to another. It follows six steps – audit the current server, set up the new server, lower DNS TTL, transfer data, switch DNS, then verify. A typical single-site migration takes 2-6 hours of working time spread across a 24-72 hour window. A multi-site or fleet migration takes days to weeks.

Server migration 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. For the related but distinct case of moving an entire site (not just the server it lives on), see What is website migration and how does it work.

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).

How long does a server migration take#

Migration time is the most-asked question and the most-misanswered one. The answer depends on what is actually moving, not just how big the data is.

The total elapsed time is almost always longer than the working time. DNS propagation alone takes hours to days. SSL certificate provisioning, post-migration monitoring, and the recommended week of running both servers in parallel all add to the calendar time even when the active work is short.

The single biggest factor in migration speed is how prepared the new server is before you start. A new server that already has the correct PHP version, MySQL configuration, and SSL certificates ready takes a fraction of the time of a from-scratch server build.

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/

1. Final database export and import to capture any data changes
2. Update DNS to point to the new server’s IP address
3. Provision SSL certificates on the new server if not already done
4. 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.

Server migration checklist#

A complete server migration breaks into six phases. Skipping or shortcutting any phase is the most common cause of failed migrations.

Phase 1: Pre-migration audit (1-3 days before)#

• [ ] Inventory every site, domain, and subdomain on the current server
• [ ] Document database names, sizes, and which sites use which database
• [ ] Note PHP version per site (different sites may need different versions)
• [ ] List all custom Nginx or Apache configurations (redirects, rewrites, IP restrictions)
• [ ] Export current cron jobs ( crontab -l > cron-backup.txt )
• [ ] Document email accounts and forwarders if applicable
• [ ] Note SSL certificate type and expiry per domain
• [ ] Record total disk usage and inode count
• [ ] Identify any custom packages, daemons, or services running outside standard hosting
• [ ] Take a full backup before touching anything (see best WordPress backup plugins if you want plugin-based options for the WordPress side)

Phase 2: New server preparation (2-7 days before)#

• [ ] Provision the new server with matching or higher specs
• [ ] Install matching PHP version and all required extensions
• [ ] Install matching MySQL or MariaDB version
• [ ] Configure web server (Nginx or Apache) with empty server blocks for each domain
• [ ] Set up firewall rules and IP allowlists
• [ ] Configure email services if applicable (Postfix, Dovecot)
• [ ] Test by deploying a single non-production site first
• [ ] Verify SSH access and document credentials securely

Phase 3: DNS preparation (24-48 hours before)#

• [ ] Lower DNS TTL to 300 seconds for every record being migrated
• [ ] Wait for the existing TTL to expire (so the lowered TTL takes effect everywhere)
• [ ] Document current DNS records as a rollback reference
• [ ] Identify any DNS records managed by third parties (Cloudflare, Route 53)

Phase 4: Data transfer (the actual migration)#

• [ ] Initial rsync of all files ( rsync -avz --progress )
• [ ] Initial database export and import
• [ ] Verify file counts and database row counts match
• [ ] Set correct file ownership on the new server
• [ ] Provision SSL certificates on the new server
• [ ] Test each site by editing the local hosts file to point to the new IP
• [ ] Fix any configuration issues before going live

Phase 5: Cutover (the maintenance window)#

• [ ] Announce the maintenance window if applicable
• [ ] Enable maintenance mode on the old server (WordPress sites)
• [ ] Run final rsync to capture any last-minute changes
• [ ] Run final database export and import
• [ ] Update DNS to point to the new server’s IP
• [ ] Disable maintenance mode on the new server
• [ ] Verify each site loads correctly via the new IP

Phase 6: Post-migration verification (1-7 days after)#

• [ ] Monitor error logs for the first 24 hours
• [ ] Verify cron jobs are executing on schedule
• [ ] Check email sending and receiving if applicable
• [ ] Test contact forms, login flows, and any third-party integrations
• [ ] Verify SSL certificates are valid and auto-renewing
• [ ] Keep the old server running for at least 7 days as rollback insurance
• [ ] Raise DNS TTL back to a normal value (3600 or higher)
• [ ] Decommission the old server only after a full week of clean error logs

Signs you need a server migration#

You may not have planned a migration, but the server itself can tell you it is time. The most common signals:

• Persistent slow page loads that are not caused by the application. If the database, code, and CDN are all healthy but pages still take 4+ seconds to render, the underlying server may be oversubscribed or running on aging hardware.
• Frequent 500 or 503 errors during normal traffic. These often indicate the server is hitting CPU, memory, or process limits. See HTTP 500 internal server error – what it means and how to fix it for diagnosis steps.
• Disk space alerts that you cannot resolve by cleaning up. If the server’s disk is genuinely too small for current usage, it is time to move to a larger one.
• Unsupported PHP or MySQL versions. If your hosting provider cannot offer the PHP version you need, migration is the only path forward. See End of life PHP – the risks of running an unsupported version for why this matters for security.
• Hardware failures or pending decommission notices from your provider. If the host has notified you the server is being retired, the migration is mandatory and the timing is theirs.
• Operating system reaching end of life. CentOS 7 reached end of life in June 2024. Servers running EOL operating systems no longer receive security patches.
• Outgrowing shared hosting. Hitting CPU or memory limits on a shared plan means the application needs more resources than the plan provides. Moving to a VPS is the standard upgrade path.
• Compliance or geographic requirements. Data residency laws (GDPR, HIPAA hosting requirements) may force a move to servers in specific countries.

If two or more of these signals appear at once, migration is overdue. If only one appears, the underlying problem may be fixable on the current server.

How much does server migration cost#

The cost depends on whether you do it yourself, use a managed provider, or hire a migration specialist.

Many hosting providers offer free migration for new customers as part of onboarding. Before paying for a migration service, check whether the destination host includes one. The catch with free migrations is they often cover the basics (files + database) but not the long tail (custom cron jobs, email, third-party integrations) – so they save you the file-copy time but you still verify and fix the rest.

For more on hosting cost in general, see How much does a server cost.

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

PHP and MySQL version mismatches#

Moving from an older server to a newer one often means jumping PHP and MySQL versions. Common breakages:

PHP 7.4 to 8.x: Numerous deprecated functions were removed in PHP 8.0. Plugins that use create_function() , each() , or pass null to string functions break immediately. After migration, check the PHP error log:

tail -100 /var/log/php-fpm/error.log | grep -i "fatal\|deprecated"

Update or replace plugins that throw fatal errors. The most common fix is updating the plugin to its latest version, which usually has PHP 8 compatibility.

MySQL 5.7 to 8.0: The utf8 alias changed behavior. In MySQL 5.7, utf8 means utf8mb3 (3-byte, incomplete Unicode). In MySQL 8.0, the default collation for utf8mb4 changed from utf8mb4_general_ci to utf8mb4_0900_ai_ci . If you import a 5.7 dump into 8.0 and see collation errors, specify the collation explicitly:

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

Or add --set-charset to your mysqldump command to include explicit character set declarations in the dump.

Rollback plan#

Every migration should have a rollback plan before it starts. The simplest rollback for a server migration is reverting DNS back to the old server’s IP. This works only if:

• The old server is still running and serving the site
• No data was written to the new server that is not on the old one (comments, orders, uploads)
• SSL certificates on the old server are still valid

Keep the old server running for at least a week after migration. If you disabled the old server and need to rollback, you have to restore from backup, which is slower and riskier.

Zero-downtime migration#

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

The process#

1. Sync data continuously using rsync in a cron job on the new server:

   # Run every 5 minutes on the new server to keep files in sync
   */5 * * * * rsync -az --delete user@old-server:/var/www/html/ /var/www/html/ >> /var/log/migration-sync.log 2>&1

1. Set up the new server as a fully working copy with SSL, cron jobs, and correct PHP configuration
2. Test the new server by editing your local hosts file to point the domain to the new IP
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. Monitor for a week before decommissioning the old server

Handling database changes during propagation#

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. Options:

• Read-only mode on the old server: Put WordPress into maintenance mode before the DNS switch. Visitors on the old server see a maintenance page, but no data is lost. This is the simplest approach but not truly zero-downtime.
• Database sync after propagation: After DNS has fully propagated (check with dig from multiple locations), do a final mysqldump from the old server and import any new rows. This requires careful merging and is error-prone for complex data like WooCommerce orders.
• Use a migration tool: Migration plugins that handle bidirectional sync during propagation remove the manual complexity. This is the most reliable approach for sites with active user-generated content.

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.