We often see WordPress migration turning into a headache: absolute paths in the database, serialized data, different PHP versions — and the site breaks. The right sequence of steps and professional tools reduce risk to zero and downtime to minutes. For a seamless WordPress migration, you need a reliable WordPress migration method. Recently we migrated an online store with 5000 products — downtime was only 2 minutes, all data intact. In this article, we share real experience: how to migrate WordPress without loss using WP-CLI, and what to check before and after the move.
How to migrate WordPress without downtime?
Planning starts 48 hours in advance: lower the A record TTL to 300 seconds. This reduces DNS propagation time after the switch. For the actual transfer, choose one of three approaches:
| Method | Complexity | Downtime | Limitations |
|---|---|---|---|
| WP-CLI + rsync | High | Minimal (1-5 min) | Requires SSH access |
| All-in-One WP Migration | Low | Depends on size | Free up to 512 MB |
| Duplicator | Medium | Depends on package | No versioning |
WP-CLI + rsync beats migration plugins: file transfer is 10x faster, full control over the process. WP-CLI + rsync is significantly better than plugin-based migration for large sites — it's 10x faster and more reliable. For VPS this is clearly the preferred option — full control, automatic handling of serialized data, incremental copying possible. On shared hosting, it's easier to use a ready plugin, but for a wet test before DNS switch, use /etc/hosts.
Why are serialized data a problem?
Manual replacement of http://old-site.com to https://new-site.com via SQL is a common mistake. Serialized strings store the length of data, and when you replace, lengths change, breaking the array. wp search-replace handles this for you:
wp search-replace 'http://old-site.com' 'https://new-site.com' --all-tables --report-changed-only # For staging (don't change URL immediately): wp search-replace 'old-site.com' 'new-site.com' --all-tables --skip-columns=guid This tool recalculates lengths, so data remains valid. More about serialized data can be read on Wikipedia. If you use phpMyAdmin or sed — you risk a broken site and wasted time on recovery.
Tools
WP-CLI + rsync — professional approach for VPS. Full control, minimal downtime. All-in-One WP Migration plugin is convenient for shared hosting, free version file size limit of 512 MB. Duplicator creates an installer package, installs like a regular site.
Migration via WP-CLI (recommended)
Follow these steps for a successful migration:
- Prepare by lowering DNS TTL to 300 seconds at least 48 hours before switch.
- Export files from source server using rsync:
rsync -avz --exclude='.git' --exclude='node_modules' /var/www/old-host.com/ user@new-server:/var/www/new-host.com/ - Export the database:
wp db export --add-drop-table - | gzip > /tmp/wordpress-db.sql.gz - Copy the database dump to the new server:
scp /tmp/wordpress-db.sql.gz user@new-server:/tmp/ - On the new server, create the database and user, then import the dump:
mysql -u root -e " CREATE DATABASE wordpress_new CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'new-password'; GRANT ALL PRIVILEGES ON wordpress_new.* TO 'wp_user'@'localhost';" gunzip -c /tmp/wordpress-db.sql.gz | mysql -u root wordpress_new - Update wp-config.php with new database credentials.
- Replace URL in database:
wp search-replace 'http://old-host.com' 'https://new-host.com' --all-tables --report-changed-only
wp search-replace correctly handles serialized data — unlike manual SQL UPDATE.
Test on the new server (before DNS change): add to /etc/hosts on your computer 1.2.3.4 new-host.com www.new-host.com. Check: homepage, products/posts, forms, payment, login, images.
DNS change: after switching, wait for propagation (usually 1–4 hours).
Typical migration mistakes
| Mistake | Consequences | Solution |
|---|---|---|
| URL replacement via SQL UPDATE | Corrupted serialized data | Use wp search-replace |
| Ignoring PHP versions | Plugin compatibility errors | Check compatibility before migration |
| Incorrect paths in wp-config | Site won't load | Verify paths and permissions |
Case: migration of a 5000-product store
Client moved a WooCommerce store from shared hosting to VPS. Original site ran on PHP 7.4, new server on PHP 8.2. Before migration, we checked plugin compatibility: the old caching plugin didn't support PHP 8.2. Replaced it with a modern alternative before the transfer. Migration via WP-CLI took 3 hours, downtime was 2 minutes. After DNS switch, all products, orders, and images were intact.
What's included in the work
Our turnkey package includes everything you need for a smooth transition:
- Full backup of the original site (files + database)
- Transfer to the new server with environment setup (PHP, MySQL, Nginx)
- URL replacement in the database via wp search-replace
- SSL certificate setup (Certbot)
- Testing all critical pages and functionality
- DNS change instructions
- One hour of post-migration support
We guarantee zero data loss with every migration. Our experienced WordPress developers have 5+ years of experience and 50+ successful WordPress migrations. Savings on hosting after optimization can be significant — up to 40% compared to old plans. Get in touch — we'll evaluate your project in one day. Contact us for a free project evaluation.
Different PHP versions
If old hosting uses PHP 7.4 and new uses PHP 8.2: check compatibility of all plugins and themes. Most modern plugins support PHP 8.x, but some old ones don't. Check PHP logs on the new server (e.g., tail -f /var/log/php/error.log). Enable object cache for better performance.
SSL on the new server
After migration, issue a certificate via Certbot. Ensure FORCE_SSL_ADMIN in wp-config.php is set.
Timelines
WordPress site migration up to 5 GB with testing and DNS switch — 3–5 hours. Large site with additional integrations — 6–8 hours. Precise estimate after project review. Get a migration consultation right now — it's free and takes no more than 15 minutes.