A WordPress migration is the careful process of moving a website to a new host, domain or platform without losing data, SEO equity or uptime. I copy everything to a staging environment on the destination host, test every page and form, map 301 redirects for any URLs that change, then switch DNS at a low-traffic window with a TTL pre-reduced to 60 seconds so propagation is near-instant. Post-cutover I verify SSL, check Google Search Console for crawl errors, confirm Analytics tracking, and monitor for 24 hours. Most sites see zero downtime and no measurable rankings drop.
Who it's for
What's included
How the process works
Pre-flight backup
I take a complete WPVivid backup of the source site — files and database — and document the current URL structure using Screaming Frog so we have a full inventory for redirect mapping.
Staging build
I migrate the full site to a staging environment on the destination host and test every page, form, redirect and third-party integration before touching DNS. You get a preview URL to review.
DNS cutover
I pre-reduce DNS TTL to 60 seconds 24 hours before cutover, switch DNS at a low-traffic window, and enable the destination site — so propagation is near-instant and there's no extended limbo period.
Verify & monitor
Post-launch: SSL confirmed, Google Search Console re-verified, Analytics tracking confirmed, Screaming Frog crawl for broken links and redirect chains, 48-hour uptime monitoring with rollback on standby.
Common questions
No. The entire site is built and tested on the destination host before DNS is touched. Visitors continue seeing the live source site throughout staging. The cutover — reducing DNS TTL to 60 seconds, switching A records — happens in a single scheduled window at your lowest-traffic time (typically 2–4am local). With a 60-second TTL, propagation completes in under 5 minutes for most DNS resolvers. There is no extended period where the site is 'in transition'.
No, if the migration is done correctly. I preserve URLs wherever possible by keeping the same permalink structure on the destination site. For any URLs that must change (domain rebrands, restructured URL slugs, platform conversions from Wix or Squarespace where URL patterns are different), I map 301 redirects using Redirection plugin and verify the full redirect chain in Screaming Frog. Google passes PageRank through 301 redirects — so search equity transfers, though a minor short-term fluctuation of 1–4 weeks is normal as Googlebot re-crawls the new destination. After cutover, I re-verify the site in Google Search Console and submit the XML sitemap to trigger re-crawling.
Yes. I migrate content from Wix (via Wix content export and manual reconstruction where Wix's export is incomplete), Squarespace (using Squarespace XML export and WordPress importer), Shopify (products, customers and orders via WP All Import with WooCommerce), and Joomla (via FG Joomla to WordPress plugin plus manual cleanup). The complexity of a platform-to-WordPress migration depends on how much content is templated vs. custom in the source platform. I scope each migration individually after reviewing the source site. Once migrated, you'll also benefit from the flexibility WordPress offers for custom theme development and WooCommerce that closed platforms like Wix or Shopify don't support.
Most host-to-host WordPress migrations (same URL, same content, new host) are completed within 2–3 days including staging build, testing and DNS cutover. Domain-change migrations take a day longer due to SSL provisioning and Search Console re-verification. Platform-to-WordPress migrations (Wix, Squarespace, Joomla to WordPress) take 1–2 weeks depending on the volume and complexity of content. WooCommerce store migrations from Shopify or Magento with 100+ products and order history take 2–3 weeks.
The source site stays live and untouched throughout the migration — I never delete the source until you've confirmed the destination is working correctly and you're happy to decommission it. If something breaks post-cutover, I can roll DNS back within minutes. In practice, breakages after cutover are uncommon because everything is staging-tested first — the most common issue is a third-party service (email SMTP, payment gateway webhook, CDN) that uses the old domain as a whitelisted origin and needs updating, which I check and fix as part of the post-launch verification list. Ongoing monthly maintenance after migration is available if you want continued monitoring.