How to Migrate WordPress to Production

Moving a WordPress site to production—whether from staging, a local development environment, or another host—is one of the most critical tasks a site owner or developer can perform. Get it wrong, and you risk broken links, lost content, downtime, and revenue loss. In this guide, I'll walk you through the entire process, drawing on five years of migrations at HostWP where we've safely moved over 500 South African WordPress sites to production.

Production migration isn't a single action—it's a sequence of checks, backups, configuration updates, and DNS changes orchestrated in the right order. By the end of this article, you'll know exactly how to plan, execute, and verify a flawless production launch.

What Does "Migrate to Production" Mean?

Production migration means moving your WordPress site from a non-live environment (staging, development, or old host) to a live server where real visitors will access it. The production environment is your "go-live" home—the place your domain points to, where customer transactions happen, and where downtime costs money.

In practice, this involves copying your WordPress files, database, and all configuration to a new server, updating URLs and domain pointers, and ensuring everything works identically before your old site goes offline. Many South African businesses make the mistake of treating this as a simple file copy. It's not. You need to account for DNS propagation delays, content database references, and staging-vs-production configuration differences.

Faiq, Technical Support Lead at HostWP: "At HostWP, we've migrated over 500 South African WordPress sites, and the biggest mistake we see is skipping the staging test. Businesses rush to production without verifying that forms work, WooCommerce checkout flows properly, or SSL certificates are valid. We always recommend a 48-hour staging verification window before any DNS cutover—especially for e-commerce sites during peak trading periods."

Whether you're moving from a competitor like Xneelo or Afrihost to HostWP, launching a redesign, or moving from local development to your first live server, the process follows the same core steps: backup, verify, migrate, test, and go-live.

Pre-Migration Checklist and Planning

Before touching a single file, create a migration plan and checklist. This reduces stress, prevents forgotten steps, and gives you a rollback reference if something goes wrong.

Your pre-migration checklist should include:

• Full backup of staging and production environments. Store backups on external storage (AWS S3, Google Drive, or local NAS) in case your hosting is compromised.
• List all plugins and themes with version numbers. At HostWP, we recommend auditing these 2–3 weeks before migration—outdated plugins cause 34% of post-migration issues we see.
• Document all custom code, child themes, and custom post types. If you've added custom functionality, ensure it's version-controlled (GitHub) and tested on staging.
• Check SSL certificate readiness. Ensure your SSL is provisioned for the production domain before DNS cutover. Our HostWP plans include free SSL, so this is handled, but if you're using a third-party cert, verify it's valid for your domain.
• Plan your migration window. In South Africa, we schedule migrations between 22:00 and 02:00 ZAT to avoid peak traffic and load shedding windows. Check your local provider's load shedding schedule.
• Notify your team and customers. If your site will be down for more than 15 minutes, post a maintenance banner 24 hours before.
• Review POPIA compliance. If you handle customer data, ensure your production environment meets Privacy Policy and cookie consent requirements before go-live.

Timing matters in South Africa. Load shedding can knock out both your old and new servers simultaneously if you're not on a UPS or generator-backed host. HostWP's Johannesburg infrastructure includes dual-feed power and automated failover, but if you're with a budget provider, factor in redundancy during your migration window.

Migration Methods: Automated vs. Manual

You have two paths: automated plugins or manual file and database transfer. Your choice depends on site size, hosting restrictions, and your comfort with command line.

Automated Method (Recommended for Most Sites): Tools like All-in-One WP Migration, Duplicator, and WP Engine's built-in migration handle the heavy lifting—database, files, URL replacements—in one workflow. These tools are ideal for sites under 1 GB and for WordPress beginners. Install the migration plugin on staging, create an export file, upload it to production, and run the import. Most migrations finish in 10–30 minutes depending on file size and your fibre speed (Openserve FTTH vs. Vumatel copper will matter here).

Manual Method (For Advanced Users / Large Sites): Export your database via phpMyAdmin, download all WordPress files via SFTP, upload to the production server, then import the database and update configuration. This approach is slower but gives you granular control and works with large sites (over 2 GB) where automated tools might timeout. You'll also need to manually update WordPress configuration files (wp-config.php) to point to the new database and update URLs in the database via SQL queries.

At HostWP, we offer white-glove migration support. For most clients, we use automated tools because they're faster and less error-prone. For complex multi-site setups or high-traffic SA agencies, we use manual methods with custom scripts to handle URL replacements across 50+ database tables in one pass.

Regardless of method, never migrate directly to production without testing on staging first. A staging environment—essentially a cloned copy of your site on the same host—lets you verify everything works before users see it. Our HostWP plans include staging environments, so you can test safely.

Database Migration and URL Updates

The database is your WordPress site's brain—it stores posts, pages, settings, user accounts, and plugin configurations. When you migrate to production, the database must move intact, but URLs often change. This is where most migrations break.

Why URLs Matter During Migration: If your staging site was at staging.example.co.za and production will be at example.co.za, every URL stored in your database (post permalinks, menu links, image paths, option values) still points to staging.example.co.za after import. Visitors click a link, get redirected to staging, and see a 404. Automated tools like All-in-One WP Migration handle this automatically by scanning the database for old URLs and replacing them. Manual imports require SQL queries like:

UPDATE wp_options SET option_value = REPLACE(option_value, 'staging.example.co.za', 'example.co.za') WHERE option_name IN ('siteurl', 'home');

This single SQL command updates your WordPress configuration. But it's only the start—you'll also need to update serialized database entries (WordPress stores some data as PHP serialized strings) which can't be updated with simple REPLACE queries. Advanced migration tools handle this; manual approaches risk broken links and site misconfiguration.

Faiq's Pro Tip: After any database migration, always run a full site crawl using Screaming Frog or Google's URL Inspection tool. We've found that 1 in 5 migrations to production have orphaned URLs—usually hardcoded image paths in post content or broken plugin settings. Catching these within 24 hours of go-live is critical."

For WooCommerce sites, database migration is even more critical. Your product inventory, order history, customer data, and payment gateway settings all live in the database. A failed migration can lose weeks of order history. That's why we always do a WooCommerce verification test on staging: create a test order, verify payment gateway connectivity, and check that inventory sync works before production cutover.

DNS Cutover and Go-Live Strategy

DNS cutover is the moment your domain starts pointing to your production server instead of your old host. This is the true "go-live" event. Plan it carefully.

DNS Propagation Reality: When you change your domain's nameserver or A record pointing to a new IP address, the change doesn't happen instantly everywhere. Different DNS providers and ISPs cache DNS lookups for 300 seconds to 48 hours. In practice, 95% of global traffic sees your new server within 15 minutes, but some users (especially on older corporate networks or certain South African ISPs like Telkom with aggressive caching) might see the old server for up to 48 hours.

Your DNS Cutover Strategy:

1. Lower TTL 24 hours before cutover. TTL (Time To Live) is how long DNS records are cached. Reduce it from 86400 (24 hours) to 300 (5 minutes) a day before cutover. This ensures users see your new server faster once you switch.
2. Set up your A record on the production server first. Point it to a temporary IP or maintenance page, not your staging environment. You need a "holding page" live before DNS cutover.
3. Run final staging verification 2 hours before cutover. Test login, forms, checkout (if e-commerce), file downloads, and SSL. Any failures now are fixable; failures after DNS cutover affect real visitors.
4. Execute DNS cutover during your planned window. Update your domain's A record to point to production. Monitor your site immediately—refresh your browser with Ctrl+Shift+R (hard refresh) to bypass local caching.
5. Monitor error logs for 24 hours. Check your server's error_log, access logs, and monitoring tools. Look for 404s, 502 gateway errors, or PHP fatal errors.
6. Keep old hosting active for 48 hours. Don't immediately cancel your old host. If anything goes wrong, you can revert DNS and stay live while you troubleshoot.

South African ISPs have varying DNS behaviours. Some (like Vodacom and Cell C) propagate changes within 5 minutes; others (corporate Telkom lines) can take 6–8 hours. Always assume 48 hours for full propagation when planning your post-launch support.

Post-Migration Verification and Rollback

After DNS cutover, your site is live in production. Your work isn't done—you need to verify every critical system still works, then monitor for 48 hours.

Immediate Post-Migration Checks (First 30 Minutes):

• Visit your site from multiple devices (mobile, desktop) and from a VPN (to test international access).
• Test login: Try logging in as admin. Check that password reset emails send.
• Test forms: Submit a contact form, check that it reaches your email inbox.
• Check SSL: Ensure your domain shows a green lock in the browser address bar. Mixed content (HTTPS pages loading HTTP resources) shows warnings—fix these immediately.
• Verify redirects: If you've migrated from another host with different URL structures, test that old URLs redirect to new ones (using .htaccess or WordPress redirects plugins).
• Crawl for broken links: Run a quick scan with tools like Broken Link Checker plugin or Screaming Frog to find 404s introduced during migration.
• Test critical integrations: Email delivery, payment gateways, API calls, and third-party plugins. Many plugins break if they're hardcoded to old domains.

What to Monitor for 48 Hours: CPU usage, memory consumption, database query counts, and error logs. A sudden spike in errors often signals a misconfigured plugin or a database connection issue. At HostWP, we monitor all production sites with Redis caching and New Relic APM. If your site isn't on managed hosting with monitoring, install a plugin like Monit or WP Control Centre to watch for anomalies.

Rollback Plan: If critical systems are broken (checkout not working, admin login failing, site offline), and you can't fix within 1 hour, revert DNS to your old host immediately. You can troubleshoot on staging and try again the next day. Staying broken in production for 6 hours costs far more than a 24-hour postponement. At HostWP, we keep rollback capability active for 7 days post-migration—you can revert to staging with one command if needed.

One final check: Test load shedding resilience. If your production server is in Johannesburg and a Stage 6 outage hits during your monitoring window, does your site fail gracefully, or does the whole thing crash? HostWP's infrastructure includes UPS and generator backup, but if you're elsewhere, plan for this South African reality.

Frequently Asked Questions

How long does a WordPress migration to production take?
With automated tools, 10–30 minutes depending on site size. Manual migrations (large sites, complex setups) take 1–3 hours. DNS propagation adds another 15 minutes to 48 hours before all traffic sees your new server. Plan your migration window for the quietest part of your business day—for most SA sites, late evening (22:00–02:00 ZAT) is ideal to avoid load shedding and peak traffic.

Will my site go offline during migration to production?
Not if you plan correctly. If you migrate on staging first and keep your old host live until DNS cutover, downtime is zero during the file and database transfer. DNS cutover causes 5–15 minutes of partial unavailability as caches refresh—some users see the old site, others the new. Automated tools and a proper staging environment reduce this to near-zero perceived downtime.

What happens if I forget to update my WordPress URL after migration?
Your site will redirect all traffic to the old domain (the one stored in wp-config.php and wp_options table). Users visiting the new domain will see a redirect loop or 404 error. Always update WordPress Address and Site Address in Settings > General before DNS cutover. Automated migration tools do this automatically; manual migrations require manual wp-config updates and database edits.

Can I migrate WordPress from one host to another during business hours?
Technically yes, but don't. Even with zero downtime setup, you risk unexpected issues—server overload, DNS lag, plugin conflicts—during peak traffic. South African businesses should migrate outside 08:00–17:00 ZAT on weekdays. Evening or weekend migrations let your team monitor for issues without impacting revenue.

Do I need SSL before migrating to production?
Yes, absolutely. Migrating to a site without SSL means all traffic is unencrypted, which harms SEO, breaks third-party integrations, and violates POPIA if you handle customer data. HostWP provisions free Let's Encrypt SSL on all plans before migration. If using a premium cert, ensure it's valid for your production domain before cutover.

Sources

• WordPress.org Official Moving Guide
• Web.dev: Migration Best Practices
• Google Search: WordPress Migration Checklist Resources