What is website migration and how does it work

Website migration is the process of moving a website from one environment to another. That could mean moving from one hosting provider to another, changing your domain name, switching from HTTP to HTTPS, or moving from one CMS platform to a different one. Each type involves different steps and different risks, but they all share the same core challenge: making the change without breaking anything or losing data.

Most website downtime during a migration is avoidable. The migrations that go wrong are the ones where someone skipped a step, did not test before switching, or did not understand what would happen to the database, the URLs, or the DNS when the change went live. This guide covers what actually happens during each type of migration, the steps involved, the mistakes that cause problems, and how to test before committing.

Types of website migration#

Host-to-host migration

The most common type. You are moving your website from one hosting provider to another. The domain name stays the same. The content stays the same. Only the server changes.

What moves:

• All website files (PHP, HTML, CSS, JavaScript, images, uploads)
• The database (MySQL or MariaDB, containing all your content, settings, and user data)
• Email accounts and data (if your email is hosted with your web hosting)
• SSL certificates (or new ones are issued at the destination)
• Server configuration (PHP version, cron jobs, redirects, custom settings)

What changes:

• The server IP address
• DNS records (A record updated to point to the new server)
• Possibly the server software stack (if the new host uses different web server, PHP version, or database version)

The critical moment in a host-to-host migration is the DNS cutover. Until you change your domain’s DNS records, all traffic still goes to the old server. After you change them, traffic gradually shifts to the new server as DNS caches expire around the world. During this propagation window, some visitors hit the old server and some hit the new one.

For a complete step-by-step guide to WordPress host migrations specifically, see How to migrate WordPress to another hosting provider.

Domain change migration

You are changing your website’s domain name. The server may or may not change. The content stays the same, but every URL on the site changes.

This is more complex than a host migration because:

• Every internal link in your content references the old domain
• Search engines have indexed the old URLs
• Backlinks from other sites point to the old domain
• Email addresses may be tied to the old domain
• Bookmarks, social media links, and directory listings all reference the old domain

The migration requires updating all URLs in the database, setting up 301 redirects from every old URL to the corresponding new URL, and resubmitting the sitemap to search engines. Missing any of these steps means broken links, lost SEO authority, or visitors landing on error pages.

For WordPress sites, URL replacement in the database is not a simple find-and-replace because WordPress stores URLs in serialized data (plugin settings, widget configurations, theme options). A naive find-and-replace breaks the serialization. You need a serialization-aware tool like WP-CLI’s search-replace command or a migration plugin that handles this correctly.

HTTP to HTTPS migration

You are adding SSL encryption to your site. The server and domain stay the same, but every URL changes from http:// to https:// .

This should be straightforward, but it causes problems when:

• Internal links and embedded resources still reference  http://  URLs, creating mixed content errors
• The HTTP-to-HTTPS redirect is configured as a 302 (temporary) instead of a 301 (permanent), confusing search engines
• Hardcoded  http://  URLs exist in the database, theme files, or plugin settings
• The SSL certificate does not cover all domains and subdomains the site uses

On properly configured hosting, HTTPS migration is a one-step process: enable Force HTTPS in the control panel. The server handles the redirect, the certificate is provisioned automatically, and the URLs update. On self-managed servers, you need to install the SSL certificate, configure the redirect in Nginx or Apache, and update the database URLs.

Platform migration

You are moving from one CMS to another: WordPress to Shopify, Squarespace to WordPress, Wix to WordPress, or any other combination. This is the most complex type because the data structures are different between platforms.

A WordPress post stored in wp_posts with metadata in wp_postmeta does not have a direct equivalent in Shopify’s data model. Product data, categories, URLs, images, and custom fields all need to be mapped from the source platform’s structure to the destination platform’s structure. Automated tools exist for common migration paths (Shopify to WooCommerce, Squarespace to WordPress), but they rarely handle everything perfectly. Manual cleanup is almost always required.

Platform migrations also mean that every URL changes structure. Squarespace uses /blog/post-title . WordPress uses /post-title/ or /category/post-title/ depending on permalink settings. Every old URL needs a 301 redirect to the corresponding new URL to preserve SEO authority and prevent broken links.

What happens during a migration#

Regardless of the type, every migration follows the same general sequence.

1. Inventory and planning

Before moving anything, document what you have:

• Total size of files and database
• Number of email accounts (if email is hosted with web hosting)
• Custom server configurations (PHP version, memory limits, cron jobs)
• Third-party integrations (payment gateways, email services, CDNs, analytics)
• DNS records (A, CNAME, MX, TXT records for SPF/DKIM/DMARC)
• SSL certificate details

This inventory prevents surprises. Discovering mid-migration that your site depends on a specific PHP extension or a custom Nginx rule that the new host does not support is the kind of problem that turns a 30-minute migration into a multi-day project.

2. Set up the destination

Configure the new server or hosting account before transferring anything. This includes:

• Creating the hosting account and domain configuration
• Setting the correct PHP version
• Creating the database
• Configuring any custom server settings needed
• Provisioning an SSL certificate

3. Transfer files and database

Copy all website files and the database from the source to the destination. The transfer method depends on the hosting environment:

Manual transfer: Download files via SFTP, export the database with mysqldump, upload files to the new server via SFTP, import the database. This works but is slow for large sites and error-prone.

Server-to-server transfer: Use rsync or SCP to transfer files directly between servers over SSH. Faster than downloading and re-uploading because the data does not pass through your local machine. Requires SSH access on both servers.

Migration plugin: A plugin installed on the source site that packages files and database, then transfers them to the destination automatically. This is the most reliable method for WordPress because the plugin handles serialization-aware URL replacement, chunked transfers for large databases, and file integrity verification.

4. Update URLs and configuration

If the domain, protocol, or URL structure changed, update all references in the database and configuration files. For WordPress, this means:

• Updating  siteurl  and  home  in  wp_options
• Running a serialization-aware search-and-replace across the entire database
• Updating  wp-config.php  with the new database credentials
• Verifying permalink settings

5. Test before cutting DNS

This is the step most people skip, and it is the step that prevents disasters.

Edit your local hosts file to point the domain to the new server’s IP address. This lets you browse the site on the new server using the real domain name, while everyone else still sees the old server.

On Windows, edit C:\Windows\System32\drivers\etc\hosts :

203.0.113.50  example.com
203.0.113.50  www.example.com

On macOS/Linux, edit /etc/hosts with the same format.

With the hosts file pointing to the new server, test everything:

• Homepage loads correctly
• Internal pages and blog posts work
• Images and media files display
• Forms submit successfully
• E-commerce checkout works (use test transactions)
• Login and admin access works
• SSL certificate is valid (no browser warnings)
• Email sending works (if applicable)

Only after all tests pass should you proceed to the DNS cutover.

6. Cut DNS

Update the domain’s DNS A record to point to the new server’s IP address. If you prepared by lowering the TTL to 300 seconds a day or two before the migration, most visitors will see the new server within 5 to 10 minutes. With a default TTL of 3600 (one hour), the transition takes up to an hour for most visitors.

During propagation, some visitors hit the old server and some hit the new one. Both should serve the same content. If you did not update the old server during the migration (because it is read-only now), visitors hitting the old server see slightly stale content but nothing is broken.

For DNS management details, see How to flush DNS cache to verify the change on your local machine.

7. Post-migration verification

After DNS has fully propagated:

• Remove the hosts file entry you added for testing
• Verify the site loads correctly from multiple networks (mobile data, different Wi-Fi)
• Check Google Search Console for crawl errors
• Submit the updated sitemap
• Monitor error logs on the new server for 404s, 500s, or other issues
• Verify email delivery if MX records changed
• Keep the old server running for at least a week as a fallback

Common migration mistakes#

Not testing before cutting DNS. The most common and most avoidable mistake. If you discover a problem after DNS has propagated, every visitor sees the broken site while you scramble to fix it. Testing with a hosts file edit takes 10 minutes and catches 90% of issues.

Forgetting about the database. Copying files without the database gives you a site that looks right but has no content. The database contains every post, page, product, setting, user, and configuration value. It is the most important part of the migration.

Breaking serialized data with naive search-and-replace. Running sed or a SQL UPDATE to replace the old domain with the new domain in a WordPress database corrupts serialized strings. WordPress stores data like s:23:"http://old-domain.com/"; where s:23 means the string is 23 characters long. If you change the domain and the character count changes, the serialized data becomes unreadable. Use WP-CLI search-replace or a migration tool that handles serialization.

Not updating DNS TTL before the migration. If your DNS records have a TTL of 86400 (24 hours), some visitors will hit the old server for up to 24 hours after you change the record. Lower the TTL to 300 seconds at least 24 hours before the migration.

Forgetting email. If your email is hosted with your web hosting and you are changing hosts, your MX records need to be updated. If email is on a separate provider (Google Workspace, Microsoft 365), verify the MX records are correct after the migration. Lost email during a migration is a common and preventable problem.

Not keeping the old server as a fallback. Do not cancel the old hosting immediately after the migration. Keep it running for at least a week. If something goes wrong, you can revert the DNS records and be back on the old server within minutes. Canceling the old server on migration day removes your safety net.

Zero-downtime migration#

True zero-downtime migration means no visitor sees an error page at any point during the process. This requires:

1. The new server is fully configured and tested before DNS changes
2. Both servers serve the same content during the propagation window
3. The DNS TTL was lowered in advance so propagation is fast
4. SSL certificates are valid on both servers during the transition

For WordPress sites, the most reliable way to achieve this is with a migration plugin that transfers the site to the new server, keeps both copies in sync during the transition, and lets you cut DNS when you are ready. The Hostney Migration plugin handles this by pulling your site data from the source server to Hostney’s infrastructure, running the transfer server-to-server without browser dependency, and performing serialization-aware URL replacement automatically.

What "one-click migration" actually means#

The term “one-click migration” is marketing shorthand. No migration is literally one click. What it usually means is that a migration tool automates the manual steps (file transfer, database export/import, URL replacement) so that you do not have to do them individually.

The quality of one-click migration tools varies enormously. Some handle edge cases well (large databases, serialized data, multisite). Others break on anything beyond a basic WordPress installation. The best migration tools:

• Transfer files in chunks so large sites do not time out
• Handle database transfer with row-level pagination instead of a single dump
• Perform serialization-aware URL replacement
• Verify file integrity after transfer
• Support resume if the connection drops mid-transfer
• Work server-to-server without depending on the browser staying open

The Hostney Migration plugin was built to handle these edge cases because we saw how many migrations fail on them. It is free on WordPress.org, works with any source host, and transfers your site to Hostney without requiring technical expertise. Install the plugin on your existing site, generate a migration token in the Hostney control panel, paste it in the plugin, and the system handles the rest.

If you want to test the migration before committing, Hostney offers a free trial. Migrate your site, test it on our infrastructure, and only switch DNS when you are satisfied everything works.