WordPress Post-Migration Checklist: Guide to SSL, DNS, and Email Issues

Key Takeaways

• SSL & Mixed Content: Use database search-and-replace for a permanent fix rather than relying on temporary plugins.
• DNS Strategy: Lower TTL before migration, monitor propagation tools, and test via your hosts file before going live.
• Email Reliability: Verify MX records after DNS updates. Use SMTP instead of PHP mail() and add SPF/DKIM records.
• Pushing Code: Files-only pushes are safer. Database pushes risk overwriting live data—always backup and have a rollback plan.

Your WordPress migration succeeded… or did it?

The files transferred. The database imported. Your site loads on the temporary URL. But now visitors are getting security warnings. Your contact forms aren’t sending emails. And you’re staring at DNS settings wondering if you’ve configured everything correctly.

Does this sound familiar?

Most migration guides don’t tell you that the actual file transfer is just the first step.  After the migration, things get really hard. You have to set up SSL certificates correctly, manage DNS propagation without causing downtime, and fix email that mysteriously stopped working.

Over the years customers have shared their post-migration configuration woes with us. These three areas (SSL, DNS, and email) cause the most confusion and support requests. Don’t sweat it though, we’re helping you understand how to get back on track.

This guide focuses exclusively on the 24-72 hours after your migration completes. We’ll walk through SSL configuration and troubleshooting, DNS propagation management, email restoration strategies, and safe staging-to-production workflows. Think of this as your technical companion for those critical first days when you’re making your migrated site production-ready.

Let’s start with the issue that affects almost every migration: SSL configuration.

Why Does My SSL Certificate Not Work After Migration?

Migrations don’t transfer SSL certificates. You’re beginning over on your new WordPress host even if your former site had a functional HTTPS configuration because they’re server-specific.

People are caught off guard. “But my site had SSL!” is a common complaint. Indeed, it did. That certificate was installed and confirmed on your previous server.

You’re moving your website files and database, but SSL certificates aren’t automatically transferred. You need to install a new certificate on your new host, whether it’s a managed service or a VPS. Much like a physical door lock, your new server has to be configured to use your SSL certificate’s private key.

You’ll face different challenges depending on your scenario:

• HTTP to HTTPS migration: First-time SSL requires upgrading all internal URLs.
• Existing HTTPS site: Reinstall SSL and fix mixed content issues.
• Domain change: A new domain requires a new certificate and URL transfer.

Ready to Move All Your WordPress Sites to Better Hosting?

Run unlimited migrations with the Cloudways Migrator plugin and enjoy fast, secure, and scalable WordPress hosting.

TRY NOW

Installing SSL Certificates on Your Cloudways Host

SSL certificates (https://) are pretty much a non-negotiable feature of a website for security and brand credibility. On Cloudways, this process is expedited and usually free.

Cloudways offers a free 1-click Let’s Encrypt SSL and a Custom SSL you’ve purchased elsewhere.

What Do You Do After You’ve Installed an SSL Certificate?

There are two important to-do’s left in the SSL certificate section of the post-migration checklist:

1. Enable Auto-Renewal (for Let’s Encrypt):
   • You will now see the information of your certificate on the same SSL Certificate screen.
   • Make sure the Auto Renewal switch is ON. Every 90 days, Let’s Encrypt certificates expire. With this service, Cloudways can automatically renew them for you so that your site never goes down.
2. Force HTTPS Redirection:
   • You need to make sure that everyone who visits your site is sent to the secure https:// version of it.
   • Go to Application Settings in the Application Management menu.
   • Click the toggle under the HTTPS REDIRECTION section to turn it on.

Are you facing Git SSL error after WordPress Migration?

Read our guide to fixing it.

Check Now

How Do I Fix “Mixed Content Warnings” in WordPress After Installing SSL?

So you’ve just installed SSL, flipped the switch to HTTPS, and now you’re staring at an annoying warning icon instead of that green padlock you were expecting. Your browser console? It’s throwing mixed content errors left and right.

Trust me, this drives everyone crazy when they first set up SSL. The culprit is usually those old HTTP links buried deep in your WordPress database: they’re still pointing to the non-secure versions of your images, scripts, and stylesheets. When your shiny new HTTPS page tries to load these HTTP resources, browsers basically freak out and flag it as a security risk.

Detecting mixed content:

Fire up Chrome or Firefox and visit your problematic page. Right-click somewhere (anywhere works) and hit “Inspect” or “Inspect Element.” Click over to the Console tab and you’ll see warnings that look something like:

 

  ❗ Mixed Content: The page at ‘https://yourdomain.com’ was loaded over HTTPS, but requested an insecure image ‘http://yourdomain.com/image.jpg’

 

That’s your smoking gun. It shows you exactly which files are causing trouble.

Getting rid of mixed content for good:

I’ve tried pretty much every method out there, and here are the three approaches that actually work:

1. Database search and replace (Recommended)

This one tackles the problem at its source by converting all those HTTP URLs to HTTPS right in the database itself.

Grab the “Better Search Replace” plugin. Here’s the drill:

• Head to Tools → Better Search Replace
• In the search field: http://yourdomain.com
• In the replace field: https://yourdomain.com
• Pick all tables (at minimum, grab wp_posts, wp_postmeta, and wp_options)
• Always, ALWAYS tick “Run as dry run” first: this lets you preview what’ll change
• If everything looks good, untick dry run and pull the trigger

Word of warning: Back up your database before touching anything. Seriously. I learned this the hard way. You want that safety net if things go sideways.

2. Plugin solution (Quick fix)

“Really Simple SSL” can automatically swap HTTP for HTTPS as your pages load. It gets the job done, though I’ll be honest, it’s papering over the cracks. The plugin doesn’t actually fix those URLs in your database; it just intercepts and rewrites them on the fly, which means your server’s doing extra work every time someone visits your site.

I usually recommend this when users need HTTPS working yesterday and we’ll circle back for a proper database cleanup later.

3. Manual wp-config.php constants

Drop these two lines into your wp-config.php file (stick them above that “stop editing” line):

define('FORCE_SSL_ADMIN', true);

define('FORCE_SSL_LOGIN', true);

Fair warning though, this only secures your admin and login areas. Your front-end mixed content issues will still be there, but at least your admin dashboard stays locked down.

How Can I Troubleshoot Common SSL Errors?

Problem: “Certificate not trusted” or “Invalid certificate”

What’s happening: Nine times out of ten, it’s either a config problem or you’re running a self-signed certificate

The fix: Get yourself a valid CA-signed certificate. Let’s Encrypt and Sectigo are solid choices. Browsers hate self-signed certs and will always complain about them. With Let’s Encrypt, sometimes just reinstalling the certificate does the trick.

Problem: “NET::ERR_CERT_COMMON_NAME_INVALID”

What’s happening: Your certificate and domain don’t match up

The fix: This usually means you’ve got SSL on “example.com” but people are hitting “www.example.com” (or vice versa). Most certificate installers handle both versions automatically, but double-check yours covers all your domain variations. Cloudflare users should check that their SSL mode is “Full” or “Full (Strict).” The “Flexible” setting causes all sorts of headaches.

Problem: Redirect loops

What’s happening: You’ve got HTTPS redirects fighting each other in different places

The fix: Pop open your .htaccess file and count how many redirect rules you see. Server-level redirects and HTTPS-forcing plugins often step on each other’s toes. Try disabling your SSL plugin temporarily. If the loop disappears, you’ve found your culprit. And don’t forget to check if Cloudflare’s “Always Use HTTPS” setting is enabled, it loves to clash with server redirects.

Problem: Admin area stays HTTP even with HTTPS enabled

What’s happening: Your WordPress URL settings are wrong

The fix: Navigate to Settings → General and make sure both “WordPress Address (URL)” and “Site Address (URL)” start with https://. If you’re locked out of admin, add these lines to wp-config.php as a workaround:

define('WP_HOME', 'https://yourdomain.com');

define('WP_SITEURL', 'https://yourdomain.com');

Post-Migration DNS Checklist

Everyone tells you “DNS propagation takes 24-48 hours,” right?

Sure, that’s not wrong. But that blanket statement has confused more people than it’s helped. It makes you picture some slow wave crawling across the internet, updating servers one by one. What’s actually happening is way more interesting. Once you get it, you can work with it instead of just waiting around helplessly.

What is DNS Propagation and How Long Does It Really Take?

Here’s the thing: DNS propagation doesn’t happen all at once everywhere. There are thousands of DNS servers all around the world, and each one decides when to get new information about your domain. And they’re all following the rules defined by your domain’s TTL (Time To Live) settings.

Picture this: A DNS server in Tokyo has your previous IP address. It will keep giving you that old address until its TTL period runs out. Is your TTL set to 86400 seconds? That server won’t even think about looking for updates for a whole day. But what if you’ve turned it down to 300 seconds? Now we’re getting somewhere; it will refresh every five minutes.

The real timeline:

– Running a high TTL (like 86400 seconds): You’re looking at that full 24-48 hour window before everyone’s on the same page

– Running a low TTL (say, 300 seconds): Most folks will see your new site within 30-60 minutes

– Geographic variation: Users in different regions see different versions because they query different DNS servers

This is why some people see your new site immediately while others still see the old one. They’re asking different DNS servers, which update on different schedules.

Pre-Migration DNS Optimization (What You Should Have Done)

In a perfect world, here’s what you’d do: About 48 to 72 hours before pulling the migration trigger, you’d drop your domain’s TTL down to 300 seconds. Basically, you’re telling DNS servers everywhere to start checking in more often.

Now, why the advance warning? Because—and this is the kicker—the TTL change itself has to propagate first. If you lower your TTL five minutes before migrating, most DNS servers are still running on that old, lazy refresh schedule. They won’t even know you’ve changed the rules for another day or two.

Didn’t do this prep work? Join the club! Most people miss this step. It’s not the end of the world. Your DNS changes will just take their sweet time. Unfortunately, there’s no magic button to speed things up after the fact, but there are ways to manage around it.

What’s the Difference Between Updating an A Record vs. Changing Nameservers?

When you redirect your DNS to your new hosting provider, you’re essentially updating the internet’s GPS coordinates for your site. You’ve got two ways to handle this:

Approach 1: A Record Update

This is the surgical approach. You’re only changing where your website traffic goes, leaving everything else (email records, verification codes, the works) exactly where it is.

First, track down your new host’s IP address. Then jump into your DNS settings and update accordingly:

– Record Type: A

– Host/Name: @ (represents your root domain)

– Value/Points to: Your new server’s IP address

– TTL: 300 (5 minutes) initially

Add a second A record for www:

– Record Type: A

– Host/Name: www

– Value/Points to: Same IP address

– TTL: 300

Approach 2: Nameserver Change

This basically hands over the DNS keys to your new hosting provider. You’ll hop into your domain registrar’s settings and swap out the nameservers for whatever your new host gives you.

Go this route if you want your hosting company handling all the DNS heavy lifting, or if they straight-up require it for their setup to work. The catch is that this wipes your DNS slate clean. Every single custom record goes poof.

So you’ll be stuck manually rebuilding all those MX records for email, SPF records for authentication, and whatever other custom DNS magic you had going on. Not fun, but sometimes necessary.

If Cloudflare’s handling your DNS and CDN duties, here’s the playbook:

1. Jump into Cloudflare’s DNS management panel and swap that A record to your new host’s IP address
2. See that little cloud icon? Keep it gray (that’s DNS-only mode) while you’re testing things out
3. After you’ve kicked the tires and confirmed everything’s working smoothly, flip that cloud orange to activate proxy mode

Here’s why this matters: If you go straight to orange cloud mode, Cloudflare’s cache might stubbornly keep serving your old site even after your DNS updates have gone through. I’ve seen people bang their heads against the wall wondering why nothing’s changing when it’s just Cloudflare doing its caching thing.

Test with the gray cloud first. Make sure your actual new server is responding correctly, then let Cloudflare work its proxy magic once you know everything’s solid.

Testing Before DNS Propagation (The Hosts File Method)

Here’s a pro tip that saves a lot of anxiety: you can preview your site on the new host before updating DNS by temporarily overriding DNS on your computer.

This uses your computer’s “hosts” file, which acts as a local DNS override:

On Windows:

1. Open Notepad as Administrator (right-click → Run as administrator)
2. Open: C:\Windows\System32\drivers\etc\hosts
3. Add at the bottom:

123.45.67.89 yourdomain.com

123.45.67.89 www.yourdomain.com

4. Save the file

On Mac/Linux:

1. Open Terminal
2. Type: `sudo nano /etc/hosts`
3. Add the same lines at the bottom
4. Press Ctrl+X, then Y, then Enter to save

Replace 123.45.67.89 with your new host’s IP address.

Your computer will utilize this override instead of DNS when you go to yourdomain.com in your browser. You can see exactly what will happen when DNS propagates, which lets you test everything before you make the move public.

ⓘ Important: Remove these lines from your hosts file after testing, or you’ll always see the new server even if DNS points elsewhere.

What Are the Best Tools for Monitoring DNS Propagation in Real-Time?

Once you’ve updated DNS, you want to know when it’s propagated. These tools show you the current state:

WhatsMyDNS.net

Shows DNS resolution from dozens of locations worldwide with a visual map. Enter your domain and record type (A), and you’ll see which regions are seeing your new IP versus your old one.

DNS Checker

Similar to WhatsMyDNS but with more detailed server information. Useful for diagnosing regional propagation issues.

What to Consider “Complete”:

You don’t need 100% global propagation to go live. When you see 75-80% of tested locations returning your new IP, most users will see your new site. The remaining servers will catch up within hours.

How Do I Clear My Local DNS Cache?

Your computer caches DNS too. Even if DNS has propagated globally, you might still see the old site because your computer hasn’t refreshed. Clear your local DNS cache:

– Windows: Open Command Prompt and run `ipconfig /flushdns`

– Mac: Open Terminal and run `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`

– Linux: Varies by distribution; usually `sudo systemd-resolve –flush-caches`

After clearing cache, test in an incognito/private browser window to avoid browser cache issues.

 

DNS Troubleshooting After WordPress Migration

Issue: “Still seeing old site after 48 hours”

First, verify your DNS records are actually updated:

1. Go to WhatsMyDNS.net
2. Enter your domain
3. Check if ANY locations show your new IP

If no locations show your new IP, your DNS hasn’t updated at the source. Log into your domain registrar or DNS provider and verify the changes saved correctly. Sometimes changes get stuck in “pending” status.

If some locations show new IP but not all, this is normal propagation. Wait a bit longer.

Solution: If all locations show new IP but you still see the old site, the issue is local caching (browser cache, local DNS cache, or ISP caching). Clear all caches and test from a different network (like mobile data instead of WiFi).

 

Issue: “Some users see new site, others see old”

This is completely normal during propagation. Different users query different DNS servers with different refresh schedules. There’s nothing you can do to force faster propagation—you just have to wait for ISPs worldwide to refresh their caches.

Solution: Consider putting a temporary maintenance notice on your old site that says “We’re in the process of migrating. If you’re seeing this message, please clear your cache and check back shortly.”

 

Issue: “Updated A record but MX records are missing—email broken”

This happens when you change nameservers instead of just updating A records. Nameserver changes wipe all DNS records, including MX records for email.

Solution: Log into your DNS manager and manually re-add all MX records, SPF records, and any other DNS entries that were lost. (We’ll cover email-specific DNS in the next section.)

 

Issue: “Cloudflare shows old IP even after updating”

If you’re using Cloudflare, check two things:

1. Did you update the A record in Cloudflare’s DNS management (not just at your registrar)?
2. Is Cloudflare’s cache serving the old site?

Solution: Update the A record in Cloudflare’s dashboard, then purge Cloudflare’s cache (Caching → Configuration → Purge Everything). Also temporarily disable the proxy (gray cloud the DNS record) to test if Cloudflare is the issue.

Post-Migration Checklist: Emails Stopped Working

Email breaking after WordPress migration catches people by surprise. “But I didn’t touch my email settings!” they tell us. And that’s true, but migration affects email in ways that aren’t immediately obvious.

Why Are WordPress Emails Not Working When I Only Migrated My Website?

Here’s what’s going on: DNS records, especially MX records, inform other mail servers where to send email for your domain.  When you move your website and alter DNS, the way you make the modifications can change how email is routed.

Three common email scenarios after migration:

Scenario 1: Email hosted with old web host

It’s possible that your old hosting company controlled your email accounts. If this is the case, those email servers are not connected to your website. You just told the internet that yourdomain.com has a new IP address when you changed the DNS to point it to the new host. You didn’t tell it where to send the email, though.

Result: The email either doesn’t get delivered or gets sent in the wrong direction.

Scenario 2: Third-party email (Google Workspace, Microsoft 365)

It’s good that your email is stored separately by Google or Microsoft. Email should still work even if the host of your website changes. Nameservers, not just A records, may have been lost when you moved nameservers. These records point to Google and Microsoft’s mail servers.

Result: Other servers can’t handle incoming email because they don’t know where to send it.

Scenario 3: WordPress transactional emails (contact forms, password resets)

Sending emails in WordPress is done by default with PHP’s mail() method. Many sites either don’t allow this function at all for security reasons or put a lot of limits on it to stop spam. It’s possible that your old host let you do it, but your new host might not.

Result: Your website can’t send emails. Resetting passwords, getting notifications from contact forms, and WooCommerce sale confirmations all fail without any noise.

How Can I Diagnose What Part of My Email is Broken?

Before you can fix email, you need to understand what’s broken. Run these tests:

Test 1: Resetting your WordPress password

On the login page for your site (wp-login.php), click “Lost your password?” Type in your email address and ask for a reset. Give it a few minutes. Did you get the email? Also, look in your spam folder.

Test 2: Send in a contact form

Send a test message using the contact form on your site. Did it get there? If you have WooCommerce or another eCommerce plugin, do a test order and look for emails confirming the order.

Test 3: Test an email from outside the company

Send an email from an outside account (like Gmail or Outlook) to your domain email ([email protected]). Did it get there? This checks incoming email, which depends on the MX record.

How to read the results:

– Nothing works: It looks like the DNS or MX records are missing or wrong.

– Emails that come in work, but WordPress emails don’t: Problem with WordPress email setup (SMTP needed)

– All of it goes to spam: There are no authentication records (SPF/DKIM)

Now let’s fix each issue.

How Do I Fix My Email by Checking or Adding MX Records?

MX (Mail Exchanger) records inform other email servers where to send email for your domain. If these are wrong or absent, email won’t come through.

Finding your correct MX records:

The MX records you need depend on where your email is hosted:

For Google Workspace:

Priority 1: ASPMX.L.GOOGLE.COM

Priority 5: ALT1.ASPMX.L.GOOGLE.COM

Priority 5: ALT2.ASPMX.L.GOOGLE.COM

Priority 10: ALT3.ASPMX.L.GOOGLE.COM

Priority 10: ALT4.ASPMX.L.GOOGLE.COM

For Microsoft 365:

Priority 0: yourdomain-com.mail.protection.outlook.com

(Replace “yourdomain-com” with your domain, using hyphens instead of dots)

For your old host’s email:

Log into your old host’s control panel BEFORE canceling the account. Find the email or DNS section and copy down all MX records exactly as shown. You’ll need to recreate these at your new DNS provider.

Adding MX records:

Where you add these depends on your DNS setup:

– If you simply changed A records: Add MX records wherever you manage DNS, which is usually your domain registrar (such Namecheap, GoDaddy, etc.).

– If you switched nameservers to your new host: Add MX records to your new host’s DNS settings.

– If you use Cloudflare: Add MX records to Cloudflare’s DNS settings.

The format usually looks like:

– Record Type: MX

– Name/Host: @ (or leave blank—represents your domain)

– Priority: 1, 5, or 10 (lower numbers = higher priority)

– Value/Points to: The mail server address

Verification:

After adding MX records, wait 10-30 minutes, then check with MXToolbox:

1. Go to mxtoolbox.com/SuperTool.aspx
2. Enter your domain
3. Select “MX Lookup” from the dropdown
4. Check that all expected MX records appear

Once verified, test incoming email by sending a message from Gmail or another external service.

WordPress SMTP Configuration: The Reliable Solution

WordPress still requires a means to SEND email, even when the MX records are set up correctly to handle inbound email. The PHP mail() function isn’t very dependable because receiving mail servers typically block it, disable it, or mark it as spam.

SMTP (Simple Mail Transfer Protocol) is the answer. WordPress sends messages directly to a mail server instead of using the server’s mail function. This is verified, trustworthy, and makes delivery much easier.

Setting up SMTP with WP Mail SMTP plugin:

1. Get the “WP Mail SMTP” plugin and turn it on (the free version works perfectly).
2. Click on Settings in WP Mail SMTP
3. Type in your “From Email,” which may be [email protected].
4. Type in the name of your site or business in the “From Name” field.

Now you need to choose a mail service. You have several options:

Option 1: Use your existing email provider

If you have Google Workspace or Microsoft 365, you can use their SMTP servers:

Google Workspace settings:

– SMTP Host: smtp.gmail.com

– Encryption: TLS

– SMTP Port: 587

– Authentication: ON

– Username: [email protected]

– Password: Your app-specific password (NOT your regular Google password—you must generate this in Google security settings)

Microsoft 365 settings:

– SMTP Host: smtp.office365.com

– Encryption: STARTTLS

– SMTP Port: 587

– Authentication: ON

– Username: [email protected]

– Password: Your Microsoft password

Option 2: Use a transactional email service

For higher volume or better deliverability, consider dedicated transactional email services:

– SendGrid: Free tier includes 100 emails/day

– Mailgun: Free tier includes 5,000 emails/month

– SendLayer: Specializes in WordPress transactional email

– Amazon SES: Very affordable for high volume ($0.10 per 1,000 emails)

These services provide SMTP credentials in their dashboards. Enter those credentials in WP Mail SMTP’s “Other SMTP” option.

Testing:

After configuration, WP Mail SMTP has a built-in test feature:

1. Go to WP Mail SMTP → Email Test
2. Enter your email address
3. Click “Send Email”
4. Check if it arrived (including spam folder)

If the test succeeds, your WordPress emails are now working. If it fails, check the error message. It usually indicates whether it’s an authentication problem, port blocking, or configuration error.

Common SMTP issues:

“Unable to authenticate“: Double-check that username and password. Also, Google’s gotten pickier. You’ll need an app-specific password these days, not your regular login.

“Connection timed out on port 587“: Your host might be playing traffic cop with outgoing SMTP. Switch from port 587 with TLS to port 465 with SSL and see if that helps. Still stuck? Time to bug your hosting support. Some hosts deliberately block SMTP to keep spammers at bay.

“Certificate verification failed“: Your host’s SSL settings are probably outdated. You could disable SSL verification in WP Mail SMTP settings as a workaround, though that’s definitely the riskier option.

SPF and DKIM Records: Avoiding the Spam Folder

If your email’s working fine, but everything keeps landing in spam, it’s super frustrating. You’re likely missing the authentication records to keep your messages credible.

SPF (Sender Policy Framework) works like a return address on a postal envelope. It tells receiving mail servers which IP addresses have permission to send mail from your domain. Without this verification, servers treat your messages like unmarked packages showing up at someone’s door. Undoubtedly suspicious.

DKIM (DomainKeys Identified Mail) takes things further. Think of it as a wax seal on an old letter. It adds a digital signature to your outgoing emails, proving the contents haven’t been tampered with during transit. Just like a castle scribe would notice a broken seal on an envelope, servers can detect if someone’s altered your message along the way.

Both significantly improve deliverability. Let’s set them up.

Setting up SPF records:

SPF is added as a TXT record in your DNS. The format depends on who sends email for your domain:

If using Google Workspace:

v=spf1 include:_spf.google.com ~all

If using Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

If using your web host’s mail server:

v=spf1 mx ~all

(This says “servers listed in MX records can send email”)

If using multiple email services:

You can chain multiple includes:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Add this as a TXT record in your DNS:

• Record Type: TXT
• Name/Host: @ (or leave blank)
• Value: Your SPF record string

Only have ONE SPF record. If you already have one, edit it to add additional includes rather than creating a second SPF record (multiple SPF records cause validation failures).

Setting up DKIM:

DKIM is more complex because it involves generating a key pair. The process varies by provider:

Google Workspace:

1. Admin console → Apps → Google Workspace → Gmail → Authenticate email
2. Click “Generate new record”
3. Copy the TXT record values

Microsoft 365:

1. Admin center → Settings → Domains
2. Select your domain → DNS records
3. Find DKIM records and enable

SendGrid/Mailgun: These services generate DKIM records in their dashboards under authentication or DNS settings.

Add the DKIM record to your DNS as a TXT record with the specific name provided (usually something like default._domainkey.yourdomain.com).

Verification:

Use these tools to verify your email authentication:

• MXToolbox: Check SPF records with their SPF Record Lookup tool
• Mail-tester.com: Send an email to the address they provide, then view your score (aim for 8/10 or higher)
• DKIM Validator: Search for “DKIM validator” and use any of the free tools

Once SPF and DKIM are properly configured, your email deliverability should improve dramatically.

Post-Migration Checklist: Safely Move a WordPress Site from Staging to Production

For Cloudways users, this entire process is managed within a dedicated, 1-click staging environment, which is designed to prevent the exact data-loss problems described here.

The Cloudways 1-Click Staging Environment

Instead of manual file pushes or complex database merges, the workflow is:

1. Create Staging: From your Application Management panel, you click “Create Staging.” Cloudways clones your entire live site (files and database) into a separate, password-protected staging application.
2. Test & Develop: You can safely make any changes (update plugins, modify themes, test new code) on this staging site without affecting your live production site.

1. Push or Pull Data: When you’re ready to deploy, the Staging Management tab gives you two simple options:
   • Push: This moves your changes (you can choose files, database, or both) from Staging to Production (Live).
   • Pull: This refreshes your Staging site with the latest data from Production (useful if your live site has new orders or comments you need to test against).

Critically, the push feature automatically handles database URL search-and-replace and gives you granular control, allowing you to move files while leaving your live database (with its new orders or comments) untouched.

Want to see how simple WordPress migration can be on Cloudways? Watch the video below for a quick walkthrough.

Why Staging-to-Production Needs Its Own Strategy

Using a staging environment to test before going live? You’re dealing with a whole different beast than a basic migration. This isn’t about moving a site that’s sitting still. You’re trying to sync changes between two environments that are both alive and kicking, and chances are, people are actively using your production site while you’re at it.

The main risk: overwriting production data. If you’ve been testing in staging for a week while customers are placing orders or users are commenting on your production site, a careless “push to production” could wipe out all that new data.

This section is about selective synchronization—moving only what you intended to change while preserving production data that was created or modified while you worked in staging.

Understanding What Should (and Shouldn’t) Be Pushed

Before you push anything from staging to production, stop and think: Has anything changed on the live site since you cloned it to staging?

If nothing’s changed (maybe it’s a brand new site, or you locked it down with maintenance mode), go ahead and push everything. You’re in the clear.

But if stuff has been happening on production while you were working? Now you need to pick and choose carefully.

Safe to push from staging:

• Theme files (wp-content/themes/yourtheme/)
• Plugin files (wp-content/plugins/)
• New media uploads you added in staging
• Database content you created (new posts, pages)
• Plugin/theme settings (if you reconfigured settings)

Dangerous to overwrite on production:

• User accounts and profiles (wp_users, wp_usermeta tables)
• Comments on production content (wp_comments table)
• WooCommerce orders placed on production (multiple woocommerce_* tables)
• Contact form submissions received on production
• Any content created by visitors/customers during your staging work

The critical decision matrix:

Site Type	Can Push Safely	Must Be Selective
Blog (no eCommerce)	Full database if no new posts were published on production	Exclude new production content
WooCommerce store	Theme/plugin files only	NEVER push database (would erase orders)
Membership site	Theme/plugin files	Exclude user accounts and membership data

Staging-to-Production Methods

Method 1: Files-Only Push

This is the safest approach for active sites. You push theme and plugin files but leave the production database untouched.

Using FTP/SFTP:

1. Connect to both staging and production via FTP
2. Download updated theme folder from staging
3. Upload to production, overwriting existing theme files
4. Repeat for any updated plugin folders
5. Test production site

This works great for:

• Theme updates
• Plugin updates
• Adding new media files

This doesn’t work for:

• New posts/pages created in staging
• Plugin settings changes
• Menu updates
• Widget placement changes

Why? Because that data lives in the database, not in files.

Method 2: Selective Database Push (Advanced)

If you need to push database changes without overwriting production data, you’ll need to export specific tables.

Tools for this:

• WP Migrate DB Pro (plugin) – Lets you select specific tables to push
• phpMyAdmin – Manual export/import of specific tables
• WP-CLI – Command line database operations

Example workflow:

1. Identify which database tables contain your changes (usually wp_posts for content, wp_options for settings)
2. Export those specific tables from staging
3. Back up production database (full backup!)
4. Import the specific tables to production
5. Run search-replace if URLs differ between staging/production

Important: This requires understanding WordPress database structure. The wp_posts table contains posts/pages but also navigation menus. The wp_options table has settings but also active plugins. Importing the wrong tables can break your site.

Method 3: Plugin-Assisted Push

Some managed hosting providers and migration plugins offer staging-to-production push functionality with built-in safeguards:

• WP Staging Pro – Offers selective push with table filtering
• BlogVault – Includes staging management with merge options
• Managed host features – Cloudways, WP Engine, Kinsta, Flywheel include staging push

These tools provide GUIs for selecting what to push, reducing the risk of mistakes.

Post-Push Verification Checklist

After pushing changes from staging to production, immediately test these functions:

Critical function tests:

• Can you log into the admin area?
• Do frontend pages load without errors?
• Do forms submit correctly?
• Does search work?
• For eCommerce: Can users add to cart and reach checkout?
• For memberships: Can users log in?

Technical checks:

• Clear all caches (server cache, plugin cache, browser cache)
• Check for PHP errors (enable WP_DEBUG temporarily if needed)
• Verify SSL still works
• Test on mobile devices
• Check page load times (shouldn’t be dramatically slower)

Content verification:

• Recent posts/pages still appear
• Navigation menus work correctly
• Widgets appear in correct locations
• Images load properly

Common post-push issues:

404 errors on all pages except homepage:

Your permalink structure needs to be refreshed. Go to Settings → Permalinks and click “Save Changes” without changing anything. This regenerates the .htaccess file (or nginx configuration) with proper rewrite rules.

White screen of death:

Usually a plugin conflict or fatal PHP error. Access your site via FTP and rename the wp-content/plugins/ folder to wp-content/plugins-disabled/. This deactivates all plugins. If the site loads, you know it’s a plugin issue. Rename the folder back, then isolate the problematic plugin by deactivating one at a time.

Database connection error:

If you accidentally overwrote wp-config.php during the push, you may have broken database credentials. Re-enter the correct database name, username, and password in wp-config.php.

Images broken or missing:

Check the wp-content/uploads/ folder. If you pushed staging uploads to production, you may have overwritten production images. Restore from backup.

What Is a Safe Rollback Plan if My Staging Push Fails?

Always have a rollback strategy before pushing staging to production.

Before pushing:

1. Take a complete backup of production (files and database)
2. Document exactly what you’re changing
3. Note the current time so you know what backup to restore if needed
4. Verify you can access production via FTP/SSH in case the admin area becomes inaccessible

If something breaks:

Don’t panic. Here’s your recovery process:

1. For minor issues: Fix in place if you know the exact problem
2. For major issues: Restore from pre-push backup immediately
3. Can’t access admin: Use FTP to rename the recently updated plugin/theme folder to deactivate it
4. White screen everywhere: Replace all files from backup via FTP
5. Database issues: Import your pre-push database backup via phpMyAdmin

The key is having that pre-push backup. Without it, recovery from a bad push is extremely difficult.

The Complete 72-Hour Post-Migration Checklist

Let’s put everything together into a timeline-based action plan. This accounts for DNS propagation reality and prioritizes tasks that prevent downtime or data loss.

Want to Migrate Your WordPress Site in Just a Few Clicks?

Use the free Cloudways WordPress Migrator plugin for unlimited, hassle-free migrations backed by 24/7 expert support.

Migrate for Free

What Are the Most Critical Mistakes to Avoid After Migrating WordPress?

These mistakes can cause major problems:

❌ Don’t cancel old hosting immediately – Wait at least 7-30 days to ensure everything is stable

❌ Don’t skip the pre-push backup – You need a restore point if staging push goes wrong

❌ Don’t ignore SSL warnings – “I’ll fix it later” often means never, and users won’t trust your site

❌ Don’t forget to clear ALL caches – Server cache, plugin cache, CDN cache, and browser cache

❌ Don’t push database changes during DNS propagation – Wait until propagation completes for major database operations

Conclusion

Completing a post-migration checklist isn’t sexy work, but it’s what separates a working site from one that actually performs.

SSL, DNS, and email—these three will give you the most headaches after any migration. Good news though: once you understand what’s happening under the hood, they all follow predictable patterns you can tackle.

Those first 72 hours after migration? That’s when everything breaks. DNS is propagating, SSL throws errors, emails bounce, and you discover what you forgot. Stick to the hour-by-hour checklist and resist the urge to rush.

Access our step-by-step website migration resources

• How Much Does It Cost to Migrate a Website in 2026?
• How to Migrate Your WordPress Site Without Downtime?
• Checkout the Best WordPress Migration Plugins for 2026

What to do now:

Currently migrating? Start simple. Confirm your site loads, get SSL running, then check DNS. One thing at a time.

Planning ahead? Bookmark this guide and drop your DNS TTL now. That single move will save you hours of propagation time later.

Dealing with a crisis? Skip straight to what’s broken. SSL troubleshooting, DNS issues, or email fixes. Each section gets you from problem to solution fast.

Look, migrations are stressful enough without the post-migration mess. At least now you know what’s coming.