Migrate a WordPress Site Without Downtime or SEO Loss

Before migration: prepare the ground

A successful WordPress migration starts 48h before the switch. Three preparatory actions dramatically reduce risks:

1. Reduce DNS TTL of your domain to 300 seconds (5 min) at least 48h before migration. Standard TTL is 3600-86400s, which can extend propagation up to 24h after the change. With TTL 300s, propagation is typically < 30 min. Editable at your registrar (OVH, Gandi, Cloudflare).
2. Audit plugins and themes before migration. Remove inactive plugins, those marked "not compatible with your PHP version", and unused themes. A 5-year-old WordPress site typically accumulates 30-50% of obsolete or duplicate plugins. Migration is the time to clean up.
3. List critical elements: PHP version used (check wp-admin/site-health.php), database (size, MySQL/MariaDB version), required PHP extensions (imagick, curl, mbstring, gd), cron tasks, SSL certificates, custom .htaccess redirects. These infos serve to reproduce the environment identically.
4. Optional maintenance mode: if you can afford 15 min of downtime, the WP Maintenance Mode plugin displays a waiting page during the switch. For e-commerce or high-traffic sites, prefer progressive migration without maintenance.

Method 1: with plugin (recommended)

1. Full backup before migration: UpdraftPlus, BackWPup or All-in-One WP Migration
2. Install empty WordPress on the new host
3. Restore the backup via the plugin
4. Test the site on the temporary IP/subdomain of the new host
5. Switch DNS from the domain to the new host (with short TTL)
6. Renew SSL on the new host after DNS propagation

Method 2: manual migration (large sites, e-commerce)

For sites > 1 GB or WooCommerce with thousands of orders, the manual method is more reliable. Steps:

1. Export the database via phpMyAdmin or SSH: mysqldump -u user -p my_db > db_backup.sql. For large sites, add --single-transaction --quick to avoid locking the database.
2. Copy WordPress files via FTP/SFTP or rsync: rsync -avz -e ssh ./wp-content/ user@new-server:/var/www/html/wp-content/. Incremental rsync is ideal to reduce transfer time.
3. Create the new database on the new host (cPanel/Plesk → MySQL Databases), then import: mysql -u user -p my_new_db < db_backup.sql.
4. Adapt wp-config.php with the new database credentials (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Keep the same security keys (AUTH_KEY, etc.) so as not to log out users.
5. Update URLs if they change: if you're also migrating your domain, use WP-CLI (wp search-replace 'old-domain.com' 'new-domain.com' --skip-columns=guid) which correctly handles serialized strings (PHP serialize). A simple SQL UPDATE would break serialized widgets and options.
6. Test on temporary subdomain: migration.new-server.com via modification of the local hosts file (without touching public DNS). Validate: homepage, articles, forms, payments (if e-commerce), transactional emails.
7. DNS switch: update A/AAAA records at your registrar. With TTL 300s prepared upstream, propagation happens in a few minutes.

Method 3: free migration by By-Hoster

If you're migrating to By-Hoster, our technical team handles the migration free of charge. You provide your FTP/cPanel credentials from the previous host, and we take care of everything, without downtime, in 24-48h. Included: file + database transfer, wp-config reconfiguration, Let's Encrypt SSL generation, post-migration testing, coordinated DNS switch. You keep access to your old hosting for 14 days for validation.

Post-migration checklist: 12 points to check

A migration isn't finished when the DNS points to the new server. Here are the 12 crucial checks in the 24h after the switch:

• Site accessible in HTTP and HTTPS: test on 3-4 browsers and a mobile. Check main pages (home, contact, cart if e-commerce).
• Let's Encrypt SSL generated and active: curl -I https://yourdomain.com must return 200 OK with a valid certificate. Post-DNS delay: 5-30 min.
• Permalinks working: check 5-10 random articles. If 404 error, go to wp-admin → Settings → Permalinks and click "Save" (regenerates .htaccess).
• Images loaded: Ctrl+F5 on the home. If images missing, check wp-content/uploads permissions (755 folders, 644 files).
• Contact forms: send a test message. Check email reception. If failure, configure SMTP (WP Mail SMTP) with an external service (Mailgun, SendGrid).
• wp-admin login: login + 2FA if enabled. If "Cookies blocked" error, clear browser cache and try in private browsing.
• WooCommerce (if applicable): perform a test purchase (Stripe/PayPal "test" mode). Check confirmation emails, stock updates, PDF invoice generation.
• WordPress cron: check that scheduled tasks run (wp cron event list via WP-CLI). Disable native WP-Cron and configure a system cron: * * * * * curl https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1.
• Performance: PageSpeed Insights test. If score < 80, check cache activation (LiteSpeed Cache, WP Rocket, W3 Total Cache), Brotli/Gzip compression, image lazy-loading.
• Sitemap submitted to Google Search Console: if the IP changed, Google may take 24-72h to recrawl. Force via Search Console → Sitemaps → submit URL.
• Old 301 redirects: if you're also migrating the domain, configure 301s on the old host via .htaccess: RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]. Maintain 12 months minimum to preserve SEO link juice.
• 24h monitoring: a free service like UptimeRobot or Hyperping detects outages and alerts via email/SMS. Also monitor PHP error logs (tail -f /var/log/php/error.log) for the first 48 hours.

Common pitfalls and how to avoid them

• Broken serialized strings: if you migrate with a naive SQL Find & Replace, serialized PHP options (widgets, customizer, page builders) break. ALWAYS use WP-CLI or a Better Search Replace plugin that handles serialization.
• SSL not renewed after migration: Let's Encrypt must be regenerated on the new host as it's tied to IP/domain. Old certificates don't migrate.
• Bad wp-config.php: forgetting to update DB_HOST (sometimes "localhost", sometimes an IP), or leaving old WP_DEBUG=true configs exposing errors in production.
• Native WordPress cron not replaced: on the old host, WP-Cron ran on traffic. If you forget to disable native WP-Cron and configure a real system cron, scheduled tasks (backups, newsletter sending, PMI updates) no longer run correctly.
• Obsolete cache: old CDN cache (Cloudflare, BunnyCDN) still pointing to the old server. Purge cache after migration: Cloudflare → "Purge Everything", BunnyCDN → "Clear Cache".
• Broken XML sitemap: Yoast/Rank Math regenerate automatically, but check accessible at https://yourdomain.com/sitemap_index.xml. Resubmit to Search Console.
• Bad DNS propagation: if the old TTL remained at 24h, some visitors still see the old site for 24h. That's why switching to TTL 300s before migration is crucial.