WordPress Migration: Zero-Downtime Move to New Hosting

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:

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:

1. Prepare by lowering DNS TTL to 300 seconds at least 48 hours before switch.
2. 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/
3. Export the database: wp db export --add-drop-table - | gzip > /tmp/wordpress-db.sql.gz
4. Copy the database dump to the new server: scp /tmp/wordpress-db.sql.gz user@new-server:/tmp/
5. 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

6. Update wp-config.php with new database credentials.
7. 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

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.

Website Redesign and Migration: CMS Change, SEO Preservation

A client came to us 6 weeks after a self-attempted redesign: 'We moved from WordPress to Tilda, traffic dropped by 70%.' I opened Google Search Console — 847 pages returned 404, the URL structure had completely changed, not a single 301 redirect was in place. Yandex hadn't reindexed the new site yet, positions collapsed. Recovery took 4 months and resulted in significant revenue loss for the quarter. Our experience — over 7 years and 80+ successful migrations, we guarantee position retention with the right approach.

Why Do Migrations Break SEO?

Search engines have indexed specific URLs. If /catalog/shoes/nike-air-max-270 turned into /products/nike-air-max-270 without a 301 redirect — all the link equity, traffic, and rankings go nowhere. Google says 301 passes ~99% of PageRank, but in practice positions recover over 2–8 weeks, not instantly.

Commonly, SEO gets broken not out of malice, but because a developer doesn't view the URL structure as a public API. Here are typical breakages:

How to Recover Traffic After a Failed Migration?

If traffic dropped, act immediately:

1. Crawl the new site for 404s and compare with the pre-migration URL list.
2. Create redirects for all lost pages with traffic >0.
3. Check structured data and meta tags on a test sample.
4. Daily monitor Coverage in Search Console and positions for top 50 queries.
5. If after 2 weeks traffic does not recover — deep audit of redirects (transitivity, chains, loops).

In our practice, a large e-commerce site lost 50% of traffic when moving from Bitrix to React + Strapi. We restored 95% of redirects in three days, and within 3 weeks traffic returned to 90% of original.

What Does a Pre-Migration Audit Include?

Before starting development on the new site:

1. Full crawl of current site via Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
2. Export all pages with organic traffic >0 over the last 6 months — these are priority for redirects.
3. Record all external backlinks to specific pages — Ahrefs, Semrush.
4. Snapshot current positions for key queries — baseline for post-migration comparison.
5. Save Core Web Vitals from Search Console for the previous 90 days.

Table for recording:

Contact us for a detailed pre-migration audit — we will help identify all risks and create an action plan.

URL Mapping and Redirects

For projects with 200+ pages, we create a mapping table: old URL → new URL → status (301, merged with another page, deleted). Each row is verified: does the content actually migrate here?

In Laravel, redirects are handled via configuration file and middleware, not .htaccess — faster and more manageable. For WordPress → Next.js: redirects are set in next.config.js (static) and at the Nginx/CDN level for dynamic ones. Old .htaccess on shared hosting with 500+ lines of redirects is a special hell. Each redirect is checked sequentially, performance suffers. We move to Nginx map directive or Redis cache for dynamic lookup. More at Wikipedia: HTTP 301.

How to Migrate Content from Different CMSs?

WordPress → Headless CMS (Contentful, Strapi, Sanity): WordPress REST API or WP All Export to export posts, meta fields, media files. Migration script in Node.js: parse export, transform structure, upload via CMS API. Media files are reuploaded to new storage, links updated in content. Typical problem — shortcodes in WordPress content ([gallery id="123"]): need parser and transformation to new format.

1C-Bitrix → modern stack: Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transformation is the longest part due to specific Bitrix data structure.

Heavy WYSIWYG → structured content: Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transformation to Markdown or Portable Text (Sanity) with manual check of problematic pages.

How to Preserve Technical SEO Elements During Migration?

Structured data (Schema.org) — if the old site had Product, Article, BreadcrumbList markup, they must be on the new site too. Google Search Console → Enhancement reports will show loss of rich snippets.

Sitemap XML: generated automatically, submitted to GSC a day after launch. Old sitemap remains until full reindexing.

hreflang for multilingual sites: if tags are lost during migration, conflicts between language versions in search results will start within weeks.

Open Graph and Twitter Card meta tags — often forgotten when changing template, pages stop displaying correctly when shared on social networks.

Launch and First Weeks Monitoring

DNS propagation: DNS switching takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.

After launch, monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, year-over-year comparison, crawl site for 404 errors.

First 2 weeks are critical. If traffic drops more than 30% — immediate audit of redirects and comparison with pre-migration crawl.

What the Service Includes

Results you receive:

1. Migration plan with URL mapping and redirects in Excel/Google Sheets format.
2. Configured 301 redirects at server level (Nginx/Cloudflare/Vercel).
3. Migrated content with integrity check: images, meta fields, links.
4. Structured data (Schema.org) on the new site, identical to old or improved.
5. SEO report: position trend at 1, 3, and 6 weeks after launch.
6. Coverage monitoring in Search Console with error notifications.
7. Guaranteed position retention: if traffic drops more than 15% within the first month — free audit and correction.

Timelines and Estimates

• Redesign with migration for a small site (up to 100 pages): 4–8 weeks.
• E-commerce migration with 500+ product pages: 8–16 weeks.
• Only technical migration part (redirects, metadata) without redesign: 1–3 weeks.

Cost is calculated individually based on scope.

Get a consultation for your project — we will respond within a day. Order a pre-migration audit of your site and receive a detailed proposal with a redirect plan. Contact us to discuss details.