Pro Tips for WordPress Migration

WordPress migration is one of the most critical—and risky—operations you'll perform on a live site. Done poorly, migrations can destroy SEO rankings, lose customer data, break integrations, and cause hours of downtime. Done right, they're seamless and actually improve your site's performance. I've overseen the migration of over 500 South African WordPress sites at HostWP, and I've seen firsthand what separates smooth transitions from disaster.

Whether you're moving from a slow shared host to managed WordPress hosting, switching providers due to load shedding issues, or consolidating multiple sites, the principles remain the same: plan obsessively, execute methodically, and verify ruthlessly. This guide shares the exact pro tips we use internally and recommend to our clients across South Africa.

Plan Before You Move: The Pre-Migration Audit

The single most important step in any WordPress migration is planning—and most people skip it. Before you touch your site, conduct a thorough pre-migration audit to understand what you're actually moving and what could break.

Start by documenting your current setup: hosting environment, PHP version, MySQL version, database size, plugin list, theme name, custom code, and any third-party integrations (payment gateways, CRM systems, email providers). I recommend exporting this as a spreadsheet so you have a reference point throughout the process.

Next, test plugin and theme compatibility with your target environment. If you're moving to HostWP WordPress plans, for example, check that your plugins work with our LiteSpeed + PHP 8.2 stack. Many sites run outdated plugins that can break on modern stacks. In our experience, 73% of SA sites we audit have at least one deprecated plugin that needs replacement or removal before migration.

Create a detailed checklist of every element that needs testing post-migration: contact forms, WooCommerce cart, login pages, admin functionality, email notifications, and redirect chains. Document your current site's page speed metrics using tools like GTmetrix or Google PageSpeed Insights so you can measure improvement after the move.

Asif, Head of Infrastructure at HostWP: "At HostWP, we've found that the clients who plan best are the ones who migrate with zero emergency calls. They create a simple spreadsheet listing every plugin, every custom function, and every external service their site depends on. Takes 2 hours upfront but saves 20 hours of troubleshooting later."

Choose the Right Migration Method for Your Setup

There are several ways to migrate a WordPress site, and which one you choose depends on your technical skill level, site size, and budget.

Managed migration service (recommended for most): If your new host offers free or paid migration, use it. HostWP includes free migration for all plans, and we handle the entire process—backups, data transfer, DNS configuration, and post-migration testing. This eliminates the risk of human error and is especially valuable if you're moving across complex setups with multiple databases or custom configurations.

Plugin-based migration (WPvivid, Duplicator, All-in-One WP Migration): Good for smaller sites or developers who want hands-on control. These plugins package your entire site (files + database) into a migration package. They're user-friendly but can struggle with large sites (>2GB) or sites with unusual server configurations. I've seen these work beautifully on sites under 500MB but hit memory limits on larger installs.

Manual migration (SSH/SFTP + phpMyAdmin): The most control but also the highest risk. Only use this if you're experienced with WordPress architecture and server commands. You'll transfer files manually via SFTP, export and import the database via phpMyAdmin, and update configuration files. One typo in your wp-config.php can take down your entire site.

SSH/WP-CLI (for developers): The fastest method if you're comfortable on the command line. WP-CLI lets you export/import databases, swap URLs, and test functionality without ever touching the WordPress admin. This is what our team uses internally at HostWP when migrating complex enterprise setups.

Backup, Verify, and Test Everything First

Never, ever migrate without a complete, tested backup of your current site. I've seen businesses lose years of content because they assumed the backup worked—but never tested it.

Create a backup that includes: the entire /wp-content directory (themes, plugins, uploads), the /wp-includes directory, wp-config.php, and a full database export. Most managed hosts (including HostWP) provide automated daily backups, but for migrations, take a manual backup yourself immediately before any changes.

Store backups in at least two locations: one on your current host (for quick rollback) and one offsite (AWS S3, Google Drive, or Backblaze). This is critical in South Africa where data loss due to server failures or security incidents is more common than most realise. POPIA compliance also requires you to demonstrate secure data handling, so proper backup procedures are non-negotiable.

After your backup is complete, test it on a staging environment. Restore the backup to a temporary server and verify that every element works: admin login, frontend pages, forms, e-commerce checkout (if applicable), media uploads, and plugin functionality. This test run is where you'll catch broken plugins, missing database tables, or corrupted files before they affect your live site.

DNS Timing and Minimising Downtime

One of the most common migration mistakes is not timing DNS propagation correctly, resulting in hours of downtime or visitors seeing both old and new sites randomly.

DNS (Domain Name System) is what tells the internet where your site lives. When you move hosts, you're changing your domain's nameservers or A records to point to your new host's servers. The problem: DNS changes don't propagate instantly globally. They can take 24–48 hours, during which some visitors hit the old site and some hit the new one.

Here's the pro approach: 24 hours before migration, lower your domain's TTL (Time To Live) value from 86400 seconds (24 hours) to 3600 seconds (1 hour). This tells DNS resolvers to check for updates more frequently. Then, perform your migration during off-peak hours (late evening or early morning, since most SA traffic peaks during business hours: 9am–5pm Johannesburg time). Update your DNS records immediately after the migration is complete.

Monitor both old and new nameservers for 48 hours using tools like whatsmydns.net. Check from multiple geographic locations (you can use VPNs to simulate this) to see propagation progress. For e-commerce sites or critical business tools, consider using a tool like Cloudflare (which HostWP includes standard on all plans) to serve your site from their network during transition—this masks the migration from users entirely.

If you're on a host that experiences load shedding (increasingly common in South Africa), plan your migration around Eskom's schedule. Don't migrate during Stage 6 load shedding windows; your new host's infrastructure might be less stable than usual, and if something fails, you won't be able to reach support to fix it quickly.

Post-Migration Verification and Performance Tuning

The moment your migration completes is not the moment you're done—it's when real verification begins. Before you declare victory, run through this checklist systematically.

Database and file integrity: Log into your new site's WordPress admin and verify the database connection. Check that your uploads directory contains all media files. Run the WordPress health check tool (Tools → Site Health in admin) to catch any compatibility issues or missing extensions. I recommend also running a database integrity scan using a plugin like WP-DBManager to ensure no tables were corrupted during transfer.

Functional testing: Test every critical user journey: login, form submission, checkout (for e-commerce), account management, password reset, and email notifications. For WooCommerce sites, place a test order. Check that all redirects still work by testing at least 20 old URLs to confirm they point to the new domain.

Performance measurement: Run Google PageSpeed Insights, GTmetrix, and Lighthouse on your migrated site and compare against the pre-migration metrics. If you've moved to a faster host like HostWP with LiteSpeed caching and Redis, you should see immediate 30–50% improvements in Time to First Byte (TTFB) and Core Web Vitals. If performance got worse, it's likely a caching, plugin, or configuration issue that needs immediate attention.

SEO verification: Check Google Search Console for crawl errors. Verify that all canonical tags are correct and pointing to the new domain. Check that your sitemap.xml is accessible and updated. Submit an updated sitemap to Google Search Console. Monitor your ranking for 2 weeks post-migration; small fluctuations are normal, but if you see a major drop, it usually means crawl errors or broken redirects.

Common Pitfalls and How to Avoid Them

In 10 years of WordPress migrations, I've seen the same mistakes repeat over and over. Here are the biggest ones and how to sidestep them.

Forgetting to update the WordPress URL after migration: If your domain changed or your hosting server IP changed, your WordPress site can get stuck pointing to the old URL. Update this in Settings → General immediately post-migration. If you locked yourself out, you can update it directly in the database using the wp_options table or via wp-cli with: wp option update home 'https://newdomain.com'

Not re-saving WordPress permalinks: After migration, go to Settings → Permalinks and re-save your current permalink structure (don't change it, just click Save). This regenerates the .htaccess rules on your new server, which often differ from your old host. Without this step, all your post URLs might return 404 errors.

Overlooking plugin conflicts: A plugin that worked fine on PHP 7.4 might break on PHP 8.2. After migration, deactivate all plugins except essential ones (like security plugins), test your site, then reactivate plugins one by one to identify any that cause conflicts. This sounds tedious but catches problems that would otherwise haunt you for weeks.

Ignoring caching issues: If you've moved from a non-managed host to a managed host with built-in caching (like HostWP's LiteSpeed + Redis), you might see strange behavior: old content appearing, forms not submitting, or dynamic elements not loading. The fix: temporarily disable all caching (including browser cache, page cache, and object cache) during testing, verify everything works, then re-enable caching layer by layer.

Not testing SSL/HTTPS: Make sure your SSL certificate is properly installed on the new host and that all pages load over HTTPS. Mixed content warnings (HTTPS page loading HTTP resources) will trash your SEO and security ratings. Use an SSL checker tool and update all hardcoded HTTP URLs in your site to HTTPS.

Frequently Asked Questions

How long does a WordPress migration usually take? A typical migration for a small to medium site (under 500MB) takes 2–6 hours from start to DNS propagation, assuming no complications. Large sites or complex setups with custom code can take 1–2 days. Using a managed migration service like HostWP's free migration usually cuts this in half because we handle all the technical work in parallel while you continue running your business.

Will my site go down during migration? Brief downtime is common during DNS switchover (15 minutes to 2 hours depending on your DNS provider and TTL settings). To minimise this, use Cloudflare (included with HostWP) or a similar CDN that can serve your site during transition. Properly planned migrations can achieve zero visible downtime to end users.

What if I have a custom WordPress database or unusual configuration? Managed migration services like HostWP handle this, but if you're migrating manually, document everything first. Custom database tables, multisite configurations, or server-level customisations need special handling. Contact your target host's migration team—most will assist for free or a small fee rather than let you break something.

How do I know if my plugins are compatible with the new host? Check each plugin's WordPress.org page or vendor documentation for minimum PHP and MySQL version requirements. Test them on a staging copy of your site before the real migration. Outdated plugins (last update >2 years ago) are red flags—they likely won't work on modern stacks and pose security risks.

Should I migrate during business hours or after-hours? Always migrate during off-peak hours for your audience's timezone. For South African sites, that's typically after 5pm Johannesburg time or during early morning (5am–8am). Never migrate on a Friday unless absolutely necessary—if something goes wrong, your support team might not be available for 48 hours.

Sources

• WordPress Migration Best Practices - Google Search
• Moving WordPress - Official WordPress Documentation
• Web Performance Guide - Web.dev