What is website migration and how does it work

Website migration is the process of moving a website from one hosting environment, domain, protocol, or platform to another while preserving its content, URLs, and functionality. The goal is to change the underlying environment without breaking links, losing data, or interrupting traffic. Common types include host-to-host migration, domain changes, HTTP-to-HTTPS conversion, and CMS platform migration.

Quick answer#

Every website migration shares the same core challenge: making the change without breaking anything or losing data. Each type involves different steps and different risks, but the underlying discipline is the same – inventory what you have, set up the destination, transfer carefully, test before cutover, and verify after.

Website migration focuses on the site itself – its content, URLs, and configuration. This is different from server migration, which focuses on the infrastructure – moving everything on a server (possibly many websites) from one machine to another. A server migration moves the container. A website migration moves the contents. You can migrate a website without changing servers (domain change, HTTPS migration, platform migration), and you can migrate a server without migrating any websites (the sites just come along for the ride because the whole server moves).

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. If you are migrating away from a legacy budget host, the export step is usually the hardest part – how to backup a WordPress site from IONOS covers it for WordPress sites on IONOS, GoDaddy, Bluehost, and similar shared hosts.

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, Drupal or Joomla to WordPress, or any other combination. This is the most complex type because the data structures are different between platforms. For the open-source CMS comparison specifically, WordPress vs Joomla vs Drupal covers the decision before you migrate.

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.

Common platform migration paths and what to expect:

Shopify to WooCommerce: Products, variants, images, and categories can be exported from Shopify as CSV and imported into WooCommerce. Customer accounts and order history require a dedicated migration plugin (Cart2Cart, LitExtension). Payment gateway settings do not transfer – you reconfigure Stripe, PayPal, or other gateways from scratch on WooCommerce. Subscription products need the WooCommerce Subscriptions extension and manual mapping.

Squarespace to WordPress: Squarespace has a built-in export to WordPress XML format, but it only exports blog posts and pages. Images are hosted on Squarespace’s CDN and need to be downloaded and re-uploaded. Custom CSS, forms, and e-commerce data do not export. Plan for manual recreation of forms, galleries, and any interactive elements. For a closer look at why people migrate this direction in the first place, see WordPress vs Squarespace for blogging; for the end-to-end walkthrough including image migration, redirect maps, and domain transfer, how to migrate from Squarespace to WordPress covers each step.

Wix to WordPress: Wix has no native export. Content must be copied manually or extracted with a migration service. Images need to be downloaded individually. The URL structure changes completely, requiring a full redirect map. The reason teams take on this migration usually comes down to SEO ceiling – see WordPress vs Wix for SEO for the honest comparison.

Weebly to WordPress: Weebly’s export is a ZIP of static HTML, not a WordPress-compatible format. The two viable paths are the Weebly to WP Importer plugin (which scrapes your live site over HTTP) or manual content extraction. Images live on Weebly’s CDN until you rehost them; the URL structure includes .html suffixes on older sites that complicate the redirect map; and Square Online stores need separate migration via CSV export plus WooCommerce import. How to migrate from Weebly to WordPress walks through both paths end to end.

Drupal to WordPress: Drupal does not have a one-click WordPress export, but the FG Drupal to WordPress plugin pulls articles, pages, users, taxonomies, and files across by connecting directly to your Drupal database. The plugin handles standard content types cleanly; everything Drupal-specific (Views, Panels, Webforms, multilingual translations, Drupal Commerce, custom fields) rebuilds in WordPress equivalents. URL aliases from Drupal need an explicit redirect map, user passwords typically need a forced reset on first login, and the field-mapping document you write before migrating is the single biggest predictor of how smoothly the rest goes. How to migrate from Drupal to WordPress walks through the plugin path, the manual SQL alternative, and the rebuild work for Views and custom content types.

Joomla to WordPress: The FG Joomla to WordPress plugin handles core Joomla content (articles, categories, users, tags) across Joomla 1.5 through 5.x. K2 content lives in separate database tables and needs the K2 companion plugin or a dedicated K2-to-WP extension. Modules and the Menu Manager structure rebuild manually because Joomla’s layout model is different from WordPress’s. The SEF URL redirect map comes from either the core redirect table or your sh404SEF/Route 66 alias table, and Joomla 3’s August 2023 EOL is the trigger for many of these migrations. How to migrate from Joomla to WordPress walks through the core plugin path, K2 separately, and the Module rebuild work.

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. Build a redirect map spreadsheet before starting: old URL in column A, new URL in column B, one row per page.

How long does a website migration take?#

The total time depends on the type of migration, the size of the site, and how well you prepared. Here is what to expect across common scenarios.

Small static or brochure site (under 100 pages, no e-commerce): 1-2 hours for the transfer itself. Add 1-2 hours for DNS propagation. If you lowered the TTL in advance, visitors will see the new server within 5-10 minutes of the DNS change.

Standard WordPress site (blog, small business, 100-500 pages): 2-4 hours for the transfer. The database copy is the longest step – a 500MB database can take 20-60 minutes to export and import, depending on the connection speed. DNS propagation adds another 1-2 hours. Budget half a day end-to-end including testing.

WordPress with WooCommerce or membership (e-commerce, user accounts): 4-8 hours. The database is larger (orders, customers, sessions, carts) and e-commerce requires more thorough testing – test checkout, payment gateways, subscription renewals, and shipping calculations before cutting DNS. Schedule the migration during a low-traffic window so any in-progress checkouts are minimized.

Enterprise sites (10,000+ pages, heavy traffic, custom integrations): Days to weeks. The file transfer may need to be split across multiple sessions, the database transfer may require rsync for incremental sync, and testing the full feature set takes significant time. Integrations with CRMs, ERPs, payment processors, and analytics all need reconfiguration and validation.

Platform migration (WordPress to Shopify, Wix to WordPress, etc.): 1-4 weeks. Data mapping between platforms is the bottleneck. Content structure differs, URL structure changes (requiring a full redirect map), and many features need manual recreation. Expect iterative testing and content cleanup.

Where the time actually goes#

Most migrations are not bottlenecked by the file transfer. The time-consuming steps are:

• Pre-migration inventory (30-60 minutes): documenting DNS records, PHP version, cron jobs, third-party integrations
• Destination setup (30-60 minutes): creating accounts, databases, SSL, configuring the new environment
• Transfer (15 minutes to several hours): files and database, depends on size and method
• URL replacement (15-30 minutes): serialization-aware search-and-replace across the database
• Testing (60-120 minutes): every key page, every form, every flow
• DNS cutover (5 minutes, plus 10 minutes to 1 hour for propagation)
• Post-migration verification (30-60 minutes): Search Console submission, 301 checks, error log monitoring

Skipping the testing step is what turns a half-day migration into a multi-day recovery. Budget the time to test properly – it is always faster than fixing a broken production site.

Website migration checklist#

Use this as a pre-migration checklist. Each item catches a specific failure mode we have seen repeatedly. Skip none.

Before you start (24-48 hours ahead)#

• [ ] Lower the DNS TTL on the A record to 300 seconds. Without this, visitors may hit the old server for hours after you change DNS.
• [ ] Take a full backup of the source site: files, database, email data. Store it off-site, not on the origin server.
• [ ] Document your current PHP version, memory limits, and any custom server settings. The destination must match or exceed these.
• [ ] Export a list of active plugins and themes (for WordPress: wp plugin list and wp theme list via WP-CLI).
• [ ] Record DNS records: A, AAAA, CNAME, MX, TXT (SPF/DKIM/DMARC), any custom records.
• [ ] Note SSL certificate provider and expiration. Plan for a new cert on the destination.
• [ ] Identify third-party integrations: payment gateways, email providers, CDNs, analytics, webhooks. These may need reconfiguration.
• [ ] Schedule the migration during a low-traffic window. Check analytics for your quiet hours.

Setting up the destination#

• [ ] Create the hosting account and configure the domain. Do not delete the old hosting yet.
• [ ] Match or exceed the source PHP version. A lower PHP version on the destination will break plugins and themes.
• [ ] Create the database with the same character set and collation as the source (usually utf8mb4 and utf8mb4_unicode_ci for WordPress).
• [ ] Provision an SSL certificate on the destination so HTTPS works before DNS cutover.
• [ ] Configure cron jobs and any scheduled tasks the site depends on.

Transferring the site#

• [ ] Put the source site in maintenance mode if the database will take more than a few minutes to copy. This prevents data divergence (new orders, comments) between the copy and the source.
• [ ] Transfer files using the fastest safe method available: server-to-server rsync if you have SSH on both, a migration plugin otherwise.
• [ ] Transfer the database. For WordPress, use a serialization-aware tool – never raw sed replace.
• [ ] Run a serialization-aware search-and-replace if the domain or protocol changed.
• [ ] Verify file count and database row count match between source and destination.

Testing with a hosts file edit (before DNS cutover)#

• [ ] Edit your local hosts file to point the domain to the new server’s IP.
• [ ] Load the homepage and 10-20 representative internal pages.
• [ ] Submit every kind of form on the site (contact, search, comment, checkout).
• [ ] Log in as an admin and verify backend functionality.
• [ ] Test the checkout flow end-to-end if the site sells anything. Run a real test transaction if possible.
• [ ] Check the SSL certificate is valid with no mixed content warnings.
• [ ] Verify images, videos, and downloadable files load from the correct URL.

DNS cutover#

• [ ] Change the A record to the new server IP.
• [ ] Remove the hosts file entry you added for testing.
• [ ] Monitor traffic on both servers – during propagation, both should be receiving requests.
• [ ] Verify from multiple networks (mobile data, office Wi-Fi, home) that you hit the new server.

After cutover (first 48 hours)#

• [ ] Submit the updated sitemap in Google Search Console.
• [ ] Spot-check 10-20 old URLs to confirm 301 redirects fire correctly.
• [ ] Monitor the new server’s error log continuously for the first few hours.
• [ ] Verify email sending works (most sites send transactional email; test it).
• [ ] Keep the old hosting active for at least 7 days as a fallback.

If any checkbox is unchecked when you cut DNS, stop and complete it. Every item on this list exists because skipping it caused a broken site for someone.

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

Post-migration checklist#

After DNS has propagated and traffic is flowing to the new environment, verify everything systematically. Missing a broken feature that visitors discover before you do erodes trust.

Content and functionality:

• Homepage, key landing pages, and a sample of blog posts load correctly
• Images and media files display (check for broken image icons and missing thumbnails)
• Internal links work and do not point to the old domain or old URL structure
• Contact forms, search, and login forms submit successfully
• E-commerce checkout works end-to-end with a test transaction
• Payment gateway callbacks confirm correctly (check with a real test purchase, not just the checkout page)

Technical:

• SSL certificate is valid with no mixed content warnings
• 301 redirects from old URLs to new URLs are working (test at least 10 representative URLs)
• Sitemap is accessible and contains the correct URLs
• robots.txt is present and not blocking crawlers
• Cron jobs are executing on schedule
• Error logs are clean – check for 500 errors, missing files, or database connection failures

SEO and external:

• Submit the updated sitemap in Google Search Console
• Verify the new property in Search Console if the domain changed
• Check Search Console for crawl errors over the following week
• Update Google Business Profile, social media profiles, and directory listings if the URL changed
• Notify any external services (CDN, email provider, monitoring) of the new server IP

Keep the old server or hosting account active for at least a week as a fallback. Monitor daily for the first week, then weekly for the first month.

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.

How much does a website migration cost?#

Cost depends almost entirely on who does the work and how complex the site is. The technical work itself is usually free – the cost is either your time or someone else’s.

DIY migration: free (plus your time)#

If you do it yourself, the tools are free. WP-CLI, rsync, mysqldump, and migration plugins like the Hostney Migration plugin cost nothing. The real cost is your time. For a standard WordPress site, budget 4-8 hours of focused work. For anything more complex, double it.

DIY makes sense when:

• You have some technical comfort (SFTP, WordPress admin, DNS basics)
• The site is not business-critical during the migration window
• You can afford 2-4 hours of downtime if something goes wrong

Managed migration service: $50-500#

Many hosts offer a managed migration as part of signing up. Some include it free for new customers; others charge $50-200 per site. Dedicated migration services (third-party consultants, WordPress maintenance agencies) charge $150-500 per standard site.

What a managed migration typically includes:

• File and database transfer
• URL replacement
• Basic post-migration testing
• Reasonable hand-holding if something breaks

What a managed migration typically does NOT include:

• Custom development or code fixes
• Plugin or theme upgrades
• Content cleanup or redesign
• SEO optimization beyond 301 redirects

Hostney includes free migration support with every hosting plan, handled by our team. The Hostney Migration plugin automates most of the technical work, and our team assists with edge cases (custom configurations, large databases, multisite).

Complex enterprise migration: $2,000-20,000+#

Enterprise migrations involve factors that multiply cost:

• Multiple environments to migrate (production, staging, dev, backup)
• Custom integrations that need reconfiguration (CRM, ERP, single sign-on, custom APIs)
• Compliance requirements (PCI DSS, HIPAA, GDPR) that require documented procedures and audit trails
• Zero-downtime requirements with active load balancing during the transition
• Platform migration (Magento to Shopify, for example) involving data structure mapping

These migrations are usually scoped as projects, billed at consultant rates ($100-300/hour), and can run from $2,000 for a mid-size migration to $20,000+ for a large enterprise move with custom integrations.

Hidden costs to budget for#

Even a free DIY migration has hidden costs:

• SSL certificate (if the destination does not include one): $0 for Let’s Encrypt, $50-200/year for commercial certs
• Domain privacy and renewal if moving registrars: $10-20/year
• CDN reconfiguration if one is in use: usually free, but requires time
• Email hosting if moving from host-bundled email to a dedicated provider (Google Workspace, Microsoft 365): $6-25/user/month
• Downtime cost if the migration goes wrong – this is often the biggest hidden cost for revenue-generating sites

The cheapest migration is the one that works the first time. Paying $200 for a managed migration is usually cheaper than the revenue lost during an extended outage from a DIY attempt gone wrong.

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.