Both are accurate. The probe hits the homepage every minute from a datacenter, gets a 200 back, and moves on. It never logs in, never adds anything to a cart, and never runs the third-party payment script that is throwing a JavaScript error on one browser version. The check was answering a question nobody was asking.

That gap is what the synthetic vs real user monitoring argument is actually about. It isn’t a tooling preference or a budget line. It’s about which failures each approach is structurally incapable of seeing, and what happens when you only run one of them.

This post covers what each method really measures, the blind spot in each that bites hardest, how to choose when you can only afford one, and how to wire both together so they explain each other instead of arguing.

The blind spot that bites hardest: silence is not health

Start with the one that catches people out, because it is invisible until the worst possible moment.

Real user monitoring is passive. A script in the page collects timings and errors from actual visitors and beacons them back. No visitors, no data. So when your site is genuinely, completely down, the browser never loads, the RUM script never executes, and your error rate goes to zero.

Zero errors. A flat, quiet, beautiful dashboard. During an outage.

I’ve seen teams build alert rules on RUM error counts and then wonder why nothing fired. A threshold alert on “errors above X” cannot fire on a metric that has stopped reporting. If you alert on RUM at all, you need a companion rule on the absence of data, and that rule needs a sensible window, because low-traffic sites go quiet at 3am for entirely normal reasons.

The mirror-image problem on the synthetic side is quieter but just as expensive. A scheduled probe only ever tests what you told it to test. Every path you didn’t script is unmonitored, and it looks exactly the same on the dashboard as a path you did script and that’s working. Coverage gaps and healthy systems are visually identical.

So: synthetic monitoring is blind to what you forgot to check. RUM is blind when nobody is looking. Neither of those is a small caveat.

Synthetic monitoring: what a probe actually measures

A synthetic check is an active request on a schedule, from infrastructure you don’t own, against an endpoint you do. It ranges from a plain HTTP GET up to a full scripted browser session that logs in and walks a purchase flow.

The simplest useful version is something you can run by hand right now. This asks curl to throw away the body and print only the timing breakdown, which tells you where the time went rather than just how much of it there was:

curl -o /dev/null -s -w 
  'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}n' 
  https://example.com/

Each value is cumulative from the start of the request, so you subtract to get the phase. A slow time_namelookup is DNS. A gap between time_connect and time_appconnect is the TLS handshake. A gap between time_appconnect and time_starttransfer is your application thinking. That last one is the number that actually correlates with user-visible slowness on a server-rendered page.

If you’re already running Prometheus, the self-hosted version of this is the blackbox exporter. It probes endpoints from outside and exposes the result as metrics. The config below is the whole trick: Prometheus doesn’t scrape the target, it scrapes the exporter and passes the target as a URL parameter.

scrape_configs:
  - job_name: blackbox-http
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com/
          - https://example.com/checkout
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Those three relabel rules have to run in that order: copy the target into the query parameter, keep the original URL as the instance label so your graphs are readable, then overwrite the scrape address with the exporter. Get the order wrong and Prometheus scrapes the exporter’s own metrics endpoint, you get no probe_* series at all, and everything looks fine because there’s nothing red to see.

The metrics you’ll actually alert on:

groups:
  - name: blackbox
    rules:
      - alert: EndpointDown
        expr: probe_success == 0
        for: 3m
        labels:
          severity: critical
      - alert: CertExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 21
        for: 1h
        labels:
          severity: warning

The certificate one is worth setting up even if you do nothing else. It’s the single highest-value synthetic check most small teams are missing, and it catches a failure mode that takes an entire site offline with no warning and no gradual degradation to notice first.

Where synthetic monitoring wins

• It works with zero traffic. A B2B app with forty users, a staging environment, a newly launched site: synthetic is the only thing that will tell you anything at all.
• It’s a controlled baseline. Same location, same schedule, same request. When the number moves, something on your side moved. RUM numbers shift because a marketing campaign brought in traffic on older phones.
• It tests paths users haven’t taken yet. A new region, a failover route, a payment provider you just switched to. RUM only ever sees sessions that already happened.
• It runs before deploy. The same scripted journey can gate a release in CI and then run on a schedule against production.
• It’s what an SLA is measured against. Availability commitments need a defined, repeatable observer. Real users are not that.

Where synthetic monitoring falls down

• The probe is on a better connection than your users. Datacenter fibre, a modern browser engine, no browser extensions, no battery throttling. It is a best case, permanently.
• Coverage equals imagination. Whatever you didn’t think to script is a silent gap, and it will be the thing that breaks.
• Scripted journeys rot. Every selector change, every A/B test, every consent banner redesign can break the check. Flaky synthetics that cry wolf get muted, and muted checks are worse than no checks.
• Cost scales multiplicatively. Frequency times locations times journeys. A one-minute browser check from eight regions is a very different bill from one HTTP check every five minutes.

Real user monitoring: what the browser actually reports

RUM is a small JavaScript agent that reads the browser’s own performance APIs and ships the results somewhere. Google’s web-vitals library is the reference implementation for the metrics that matter, and it’s deliberately tiny:

import { onCLS, onINP, onLCP } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name:   metric.name,
    value:  metric.value,
    rating: metric.rating,
    id:     metric.id,
    path:   location.pathname
  }));
}

onCLS(send);
onINP(send);
onLCP(send);

Three things are worth understanding about that snippet. The callbacks fire when the metric is final, not on a timer, which is why Interaction to Next Paint can only be reported near the end of a session. sendBeacon is used instead of fetch because it survives the page being closed. And metric.rating gives you the good / needs-improvement / poor bucket without you hardcoding thresholds that Google may revise.

If you’d rather not build the collection side, the managed options split roughly into full-stack platforms (Datadog RUM, New Relic, Dynatrace), error-tracking tools that grew into RUM (Sentry), and open-source agents you can point at your own backend. Grafana Faro is the notable one in that last group: a browser SDK that ships web vitals, errors and traces to a collector you run yourself or to Grafana Cloud, which means your frontend signals land next to your Prometheus metrics and Loki logs instead of in a separate tab.

Where RUM wins

• It’s the only source of truth for Core Web Vitals. Google assesses LCP, INP and CLS from field data at the 75th percentile, via the Chrome User Experience Report. A perfect Lighthouse score is a lab result and carries no weight in that assessment.
• It surfaces the long tail. Mid-range Android on a congested mobile network is a cohort no synthetic probe represents, and it’s frequently the cohort that fails.
• It segments the way the business thinks. By country, by ISP, by device class, by page template, by traffic source. That’s how you find out the paid social landing page is the slow one.
• It catches client-side-only failures. A third-party tag that starts blocking render, a JS exception on one browser version, a consent script that stalls. The HTML came back 200. The page is still broken.

Where RUM falls down

• No traffic, no signal — the silence problem above, plus useless percentiles on any low-volume page.
• It’s reactive by construction. Every data point is a user who already had the bad experience. RUM cannot warn you about anything.
• You are sampled, ad-blocked and consent-gated. A meaningful slice of visitors never report, and they’re not a random slice. Privacy-conscious, extension-heavy users skew toward desktop and toward certain regions.
• The agent costs what it measures. You’re adding JavaScript to a page in order to find out how much JavaScript is slowing it down. Keep the agent small and load it late.
• Field data lags. CrUX aggregates over a trailing window, so a fix you shipped this week won’t show up in the assessment for weeks. Ship it, then wait, and resist re-litigating.

Synthetic vs real user monitoring: the honest split

Strip away the vendor framing and the division is clean. Synthetic answers “is the thing I defined still working?” RUM answers “what are people actually experiencing right now?”

Which means they belong to different jobs. Synthetic owns availability, contractual uptime, certificate and DNS health, and regression gates in CI. RUM owns experience, Core Web Vitals, conversion-adjacent performance work, and prioritisation. If you find yourself arguing about which is “better”, you’re comparing a smoke detector to a customer satisfaction survey.

Synthetic tells you something broke. RUM tells you whether it mattered, and to whom.

How I’d decide what to run first

Most teams can’t stand up both properly in the same quarter. Here’s the order I’d work in.

1. Get an external uptime check up today. Any of them. UptimeRobot, Better Stack, Pingdom, or blackbox exporter if you already run Prometheus. It must live outside your own infrastructure, or it dies with the thing it’s watching. Do check the current terms on free tiers before you build a client’s alerting on one, since several now restrict commercial use.
2. Add TLS expiry and DNS resolution checks. Cheap, and they catch total outages that have no warning phase.
3. Decide whether you have traffic. If a typical page gets meaningful daily sessions, RUM will produce usable percentiles and should come next. If it doesn’t, skip RUM entirely for now and spend the effort on scripted journeys instead.
4. Script your two or three money paths. Login, search, checkout. Not twelve. Each one is code you now have to maintain. Checkly is built around exactly this if you want the checks living in your repo as Playwright specs; Grafana Cloud Synthetic Monitoring covers the same ground with k6 scripts if your dashboards already live in Grafana.
5. Add probe locations only where you have users. Frequency times locations is your bill. Two well-chosen regions beat eight decorative ones.
6. Layer RUM last, and start read-only. Look at it for a month before you attach a single alert to it. You need to know what normal looks like per page template.

One thing worth checking before you buy anything: what your hosting already gives you. Managed WordPress plans and VPS providers like InterServer often include basic availability alerting and a status page, and Cloudflare exposes edge-side request and error data for anything behind it. That may be enough of the availability layer that you can spend the budget on the experience layer instead.

Mistakes that look like monitoring

• Running the check from inside the network it monitors. If your probe and your app share a VPC, a datacenter, or a DNS resolver, a shared failure takes out both and you learn nothing.
• Probing a health endpoint that always returns 200. A route that returns a hardcoded OK without touching the database is testing your web server’s ability to serve a string. Make the check exercise a real dependency, or add a content assertion on a page that only renders correctly when the database answers.
• Alerting on averages. A mean page load time hides every user who had a terrible one. Use p75 for experience work, because that’s what Google assesses, and p95 or p99 when you’re hunting outliers.
• Alerting on a single failed probe. One-off network blips are constant. Require consecutive failures, or failures from more than one location, before you wake anyone.
• Treating a Lighthouse score as a monitoring signal. It’s a diagnostic on a simulated device. Useful for finding the cause, worthless as an assessment of what users get.
• Letting synthetic traffic pollute analytics. Scripted browser checks look like sessions. Filter them out by user agent or a header, or your conversion rate quietly develops a dent.
• No alert on missing data. Applies to both sides. A probe that stopped running and a RUM stream that stopped reporting both look like calm.

Making the two views agree

The payoff for running both isn’t two dashboards. It’s that each one narrows the search when the other fires.

• Use consistent labels across both. Same page-template names, same region names, same environment tags. Otherwise correlating them is manual archaeology every time.
• Define availability from synthetic, experience from RUM, and write it down. avg_over_time(probe_success[30d]) is your uptime figure. p75 INP is your experience figure. Don’t let the two SLOs drift into using each other’s data.
• Let RUM tell you what to script next. When RUM shows a page template failing for one device class, that’s a synthetic check waiting to be written, throttled to match.
• Let synthetic explain RUM regressions. RUM says LCP got worse on Tuesday. Synthetic’s stored waterfall from Tuesday tells you which resource started arriving late.
• Alert on synthetic, investigate with RUM. Pages should come from the deterministic signal. The noisy, high-cardinality one is where you go to figure out the blast radius.
• Keep the scripted journeys in version control alongside the app they test, so a selector change and its check update land in the same pull request.

Frequently asked questions

Is uptime monitoring the same thing as synthetic monitoring?

Uptime monitoring is the simplest form of synthetic monitoring: a scheduled request checking for a successful response. Full synthetic monitoring extends that to multi-step browser journeys, API sequences, DNS, TCP and traceroute checks. Same category, different depth.

Can real user monitoring replace uptime checks?

No, and this is the most expensive misunderstanding in the whole synthetic vs real user monitoring discussion. RUM depends on pages loading. When the site is down, the RUM stream goes quiet rather than red, so an outage looks identical to a slow night unless you have explicitly alerted on the absence of data.

How often should synthetic checks run?

Work backwards from how fast you need to detect a problem, then account for the consecutive failures you require before alerting. A one-minute interval with a three-failure threshold means roughly three minutes to detection. Cheap HTTP checks can run frequently; browser journeys usually run every five to fifteen minutes because they cost far more per execution.

Does RUM slow down the site it’s measuring?

Slightly, and it’s a real trade-off rather than a rounding error. A minimal web vitals collector adds very little; a full session-replay agent is a much heavier thing to load. Load the agent asynchronously, sample sessions rather than capturing every one, and measure the agent’s own cost before you decide it’s free.

Why does my synthetic check pass while PageSpeed Insights fails?

They’re measuring different things from different places. A synthetic HTTP probe checks that a response came back; PageSpeed Insights reports both a throttled lab simulation and field data from real Chrome users. Neither is wrong. If the field section fails, real users on slower devices are having a worse time than your probe is.

Do I need both if I run a small brochure site?

Usually not. A low-traffic site gets almost nothing out of RUM because there aren’t enough sessions to make a percentile meaningful. Run solid external uptime and certificate checks, look at Search Console’s Core Web Vitals report for whatever field data exists, and add RUM when traffic justifies it.

Can I self-host all of this?

Yes. Blackbox exporter plus Prometheus and Alertmanager covers synthetic; Grafana Faro with a collector you run covers RUM. The catch is that self-hosted probes lose the one property that makes external monitoring valuable, which is independence. Run at least one check from a network you don’t control, even if everything else is yours.

The one thing worth remembering

Synthetic vs real user monitoring isn’t a choice between two products that do the same job. It’s a choice about which blind spot you’re willing to live with, and the answer to that changes as your traffic changes.

If you take one thing away: a quiet dashboard is not evidence of health. Synthetic monitoring goes quiet when you never wrote the check. RUM goes quiet when the site is down. Both silences look exactly like everything being fine, and both need an explicit alert on missing data before you can trust the green.

Need help getting your monitoring to match reality?

This is a good chunk of what I do. If your uptime page says one thing and your users say another, I can help with:

• Setting up external synthetic checks with sensible thresholds, so alerts fire on real failures and stop firing on network noise
• Blackbox exporter, Prometheus and Alertmanager configuration, including TLS expiry and DNS resolution alerting
• Scripting the two or three user journeys that actually earn money, and keeping them in version control next to the app
• Adding real user monitoring with Grafana Faro or a hosted RUM platform, sized so the agent doesn’t become the performance problem
• Building Grafana dashboards that put availability and Core Web Vitals side by side with consistent labels, so you can correlate them during an incident
• Auditing existing monitoring for coverage gaps, missing-data alerts, and checks that pass for the wrong reasons

Send me a screenshot of your current alert rules, a scrape config, or just the endpoint that keeps going green while people complain, and I’ll tell you what it’s missing.

The post Synthetic vs Real User Monitoring: What Your Green Dashboard Isn’t Telling You appeared first on John Nessime.

A successful WordPress migration is not just a matter of copying files from one server to another. It is a controlled infrastructure change involving the website files, database, domain records, SSL certificate, email configuration, caching layers, scheduled tasks, security settings, and third-party integrations.

When the process is planned correctly, visitors may never notice that the website has moved. When it is rushed, the result can include broken pages, missing images, database errors, lost form submissions, email disruption, redirect loops, certificate warnings, or several hours of downtime.

This guide explains how to migrate a WordPress website safely, how to reduce downtime, what can go wrong, and what should be verified before the old hosting environment is finally switched off.

What Is a WordPress Migration?

A WordPress migration is the process of moving a WordPress website from one environment to another. The destination might be a new hosting provider, a cloud server, a virtual private server, a staging environment, a new domain, or a different server configuration.

The website may look like a single application from the visitor’s perspective, but several separate components normally need to be transferred:

• WordPress core files
• Theme files
• Plugin files
• Uploaded media
• The MySQL or MariaDB database
• Configuration files
• Custom code and server rules
• DNS records
• SSL certificates
• Email-related DNS records
• Cron jobs and scheduled tasks
• CDN and caching configuration
• Analytics and tracking scripts
• External API integrations

A complete migration must preserve both the visible website and the underlying functionality. Copying the homepage successfully is not enough if contact forms stop sending, checkout sessions fail, redirects break, or administrators can no longer log in.

Common Reasons for Migrating a WordPress Website

Website owners migrate WordPress installations for many different reasons. In most cases, the decision is connected to performance, reliability, cost, control, or security.

Slow Hosting Performance

A website may outgrow its original shared hosting plan. Pages become slow, the WordPress dashboard takes longer to load, and traffic spikes begin causing resource-limit errors. Moving to a better-managed host, VPS, or cloud server can provide more CPU, memory, storage performance, and configuration flexibility.

Frequent Downtime

Unreliable infrastructure can damage customer trust and search visibility. If the current host experiences repeated outages or provides weak technical support, migration may be the most practical long-term solution.

Security Concerns

Outdated server software, poor account isolation, weak backup systems, or limited firewall controls can expose a WordPress website to unnecessary risk. A migration can be used as an opportunity to rebuild the site on a cleaner and more secure environment.

Hosting Cost Optimization

Some hosting plans become expensive as traffic grows, especially when backups, staging, CDN access, email, malware scanning, or additional storage are charged separately. Migrating to a more suitable platform can reduce costs without sacrificing performance.

Business Growth

A small brochure website may eventually become a membership platform, online store, booking portal, or content-heavy publication. The original environment may no longer support the website’s operational requirements.

Domain or Branding Changes

Some migrations involve changing the domain name as well as the server. This requires additional planning because internal URLs, redirects, analytics properties, search-engine records, cookies, and third-party callbacks may all depend on the original domain.

The Difference Between a Simple Migration and a Production Migration

A small personal blog with few updates can often be moved using a migration plugin. A production website requires more care.

Production websites may receive new orders, registrations, comments, bookings, support requests, or form submissions while the migration is taking place. If the database is copied too early and DNS is updated hours later, any data created during that gap may remain only on the old server.

That is why a production migration should be treated as a controlled cutover rather than a one-click file transfer. The objective is to minimize the period during which the old and new environments contain different information.

What Can Go Wrong During a WordPress Migration?

Most migration problems fall into a predictable set of categories. Knowing them in advance makes the process easier to plan and troubleshoot.

Database Connection Errors

The WordPress configuration file may contain the wrong database name, username, password, or database host. The user may also lack the necessary permissions on the destination database.

Broken Internal URLs

WordPress stores URLs in the database. If the domain, protocol, folder path, or staging address changes, old references can remain inside posts, menus, widgets, page-builder content, serialized options, and plugin settings.

Missing Images or Media Files

The uploads directory may be incomplete, excluded from the transfer, or copied with incorrect ownership and permissions. A site may appear functional while older images silently return 404 errors.

PHP Compatibility Problems

The destination server may use a newer PHP version than the original host. An outdated theme or plugin can then generate warnings, fatal errors, blank pages, or broken administrative screens.

Redirect Loops

Conflicting HTTPS, proxy, CDN, and WordPress redirect rules can cause the browser to repeatedly redirect between two versions of the same URL.

Email Delivery Failure

A migration may affect outgoing form emails, SMTP authentication, domain verification, or mailbox routing. DNS changes can also unintentionally overwrite MX, SPF, DKIM, or DMARC records.

SSL Certificate Warnings

The destination server may not yet have a valid certificate, or the certificate may not cover every hostname used by the website. Mixed-content warnings can also appear when pages load images, scripts, or stylesheets through HTTP.

Lost Transactions or Form Submissions

This is one of the most serious risks. If visitors continue using the old website after the final database backup, their activity may not exist on the new server.

Phase One: Audit the Existing Website

Before copying anything, document the current environment. A migration is much safer when the source system is fully understood.

The audit should include:

• Current WordPress version
• PHP version and PHP extensions
• Database engine and version
• Active theme and child theme
• Active and inactive plugins
• Disk usage
• Database size
• Upload directory size
• Web server type
• Caching configuration
• Scheduled cron tasks
• CDN or reverse proxy usage
• External SMTP provider
• Payment and booking integrations
• DNS provider
• SSL configuration
• Backup availability

This audit often reveals problems that already existed before the migration. For example, a plugin may be abandoned, the database may contain excessive transient records, or the site may still rely on an unsupported PHP version.

A migration should not automatically copy every old problem into the new environment. It is often the right time to clean up unused plugins, remove abandoned themes, review administrator accounts, and confirm that all essential components remain supported.

Phase Two: Prepare the Destination Server

The destination environment should be ready before the website is transferred. This reduces last-minute troubleshooting during the cutover.

The server preparation usually includes:

• Creating the hosting account or virtual host
• Installing the correct PHP version
• Enabling required PHP extensions
• Creating the database and database user
• Configuring file permissions
• Setting PHP memory and upload limits
• Configuring the web server
• Preparing SSL issuance
• Configuring backups
• Installing monitoring or logging tools
• Preparing caching and performance settings

The destination should ideally match the source environment closely during the first transfer. Major software upgrades can be performed later, after the website is stable. Combining a hosting migration, PHP upgrade, plugin cleanup, theme redesign, and domain change into one maintenance window increases the number of possible failure points.

Phase Three: Create Verified Backups

A migration should never begin without a complete backup. More importantly, the backup should be verified rather than merely assumed to be usable.

At minimum, create separate copies of:

• The entire WordPress file system
• The website database
• The WordPress configuration file
• Web server rules
• DNS records
• SSL-related information
• Custom cron jobs
• Email routing records

A backup is only valuable if it can be restored. Confirm that the archive opens correctly, the database export is not empty or truncated, and the files include the full uploads directory.

For business-critical websites, keeping more than one backup copy is sensible. One copy may remain on the source server, while another is stored externally.

Phase Four: Copy the WordPress Files

The files can be transferred using several methods, including a migration plugin, hosting control panel, SFTP, SCP, rsync, or a compressed archive.

For small websites, a plugin may be sufficient. Larger websites often benefit from server-level transfer tools because they handle large file sets more efficiently and provide better visibility into transfer errors.

During the transfer, confirm that hidden files are included. Files such as .htaccess may contain essential rewrite, security, redirect, or caching rules.

After copying, verify ownership and permissions. Incorrect permissions can prevent uploads, plugin updates, cache creation, or WordPress core operations.

Phase Five: Export and Import the Database

The database contains the website’s posts, pages, users, settings, menus, plugin data, WooCommerce orders, form entries, and most application-level configuration.

It can be exported using tools such as phpMyAdmin, WP-CLI, a migration plugin, or the database command line. Large databases are generally more reliable to move through command-line tools because browser-based imports may fail due to upload or execution limits.

Once imported, update the destination wp-config.php file with the correct database details:

define('DB_NAME', 'destination_database');
define('DB_USER', 'destination_user');
define('DB_PASSWORD', 'strong_password');
define('DB_HOST', 'localhost');

The exact database host depends on the hosting environment. Some providers use a remote database hostname instead of localhost.

Phase Six: Handle URL Changes Correctly

If the website keeps the same domain, fewer URL changes may be required. However, staging URLs, temporary hostnames, HTTP-to-HTTPS changes, subdirectory changes, or domain changes require a controlled search-and-replace operation.

A plain text replacement inside a database export can damage serialized WordPress data. WordPress plugins and page builders often store structured values where string lengths matter.

Use a WordPress-aware tool such as WP-CLI:

wp search-replace 'https://old-domain.example' 'https://new-domain.example' --all-tables --precise --dry-run

The dry run displays the expected replacements without modifying the database. Once reviewed, the operation can be repeated without the --dry-run flag.

After the replacement, check:

• Page and post links
• Navigation menus
• Image URLs
• Page-builder templates
• Widgets
• Logo and favicon paths
• Canonical tags
• Open Graph images
• Plugin callback URLs
• Webhook endpoints

Phase Seven: Test the Website Before Changing DNS

The destination website should be tested before public traffic is sent to it. This is one of the most important steps in a low-downtime migration.

A local hosts-file override can map the production domain to the new server only on your own computer. This allows the website to be tested under its real domain while the rest of the internet continues reaching the old server.

Testing should cover more than the homepage.

Front-End Testing

• Homepage
• Posts and pages
• Category and archive pages
• Search functionality
• Navigation menus
• Images and downloads
• Responsive layout
• 404 page
• Redirects

Administrative Testing

• WordPress login
• Post editing
• Media uploads
• Plugin settings
• Theme customization
• User management
• Scheduled tasks

Business Function Testing

• Contact forms
• Newsletter subscriptions
• Account registration
• Password reset emails
• Checkout and payment flow
• Booking forms
• Customer dashboards
• API integrations
• Webhook delivery

Check the browser console, server logs, WordPress debug logs, and network requests. A page can appear normal while scripts, API calls, or background processes are failing silently.

How to Reduce WordPress Migration Downtime

Zero downtime is difficult to guarantee for every website, but downtime can often be reduced to a very small window.

Lower the DNS TTL in Advance

DNS Time to Live determines how long resolvers may cache a record. Lowering the TTL before migration can help changes propagate more quickly.

This should be done before the migration window, not at the exact moment of cutover. Existing cached records will continue using the previous TTL until they expire.

Perform an Initial Copy Before Cutover

Copy the website files and database to the destination in advance. This gives enough time to test the environment and resolve compatibility problems before the final switch.

Freeze Content Changes Briefly

For dynamic websites, a short maintenance or content-freeze window may be necessary. During this period, editors should stop publishing and customers may need to be temporarily prevented from submitting transactions.

Perform a Final Database Synchronization

After the initial copy and testing, export the latest database immediately before the DNS or proxy cutover. This minimizes the chance of losing recent activity.

Keep the Old Server Available

Do not cancel the original hosting account as soon as DNS is changed. Some visitors may still reach the old server due to DNS caching. The source environment should remain available until propagation is complete and the new website has been monitored.

DNS Migration: More Than Changing One Record

DNS errors are responsible for many migration failures. A domain may have records for the website, email, verification services, subdomains, APIs, and third-party platforms.

Before making changes, export or document the complete DNS zone. Important records may include:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF records
• DKIM records
• DMARC records
• Domain verification records
• Service-specific subdomains

If only the web server is changing, there may be no reason to modify email records. Accidentally replacing the entire DNS zone with a simplified version can interrupt business email even when the website itself works correctly.

SSL and HTTPS After Migration

The destination server must have a valid SSL certificate for the production domain. The certificate should cover all required hostnames, such as the root domain and the www version.

After enabling HTTPS, verify that:

• The certificate is valid and not expired
• The certificate matches the domain
• HTTP redirects to HTTPS correctly
• The root and www versions behave consistently
• No redirect loop exists
• Images and scripts load through HTTPS
• CDN resources use secure URLs

Mixed-content errors should be corrected rather than hidden. They usually indicate that some database values, theme settings, CSS files, or external resources still reference HTTP URLs.

Email and Contact Form Verification

A website migration is not complete until email functionality is tested.

WordPress may rely on the local server mail function, SMTP authentication, a transactional email provider, or an external mailbox service. Each method has different requirements.

Test at least the following:

• Contact form delivery
• Administrator notifications
• Password reset emails
• WooCommerce order emails
• Registration emails
• Newsletter confirmation messages
• SMTP authentication

Also confirm that SPF, DKIM, and DMARC records remain valid. Successful message submission does not always mean successful inbox delivery.

Migrating a WooCommerce Website

WooCommerce migrations require additional care because the database may change continuously. Orders, inventory, customer records, carts, subscriptions, refunds, and payment events can be created during the migration window.

A WooCommerce migration plan should include:

• A clearly defined cutover time
• A short checkout freeze if required
• A final database synchronization
• Payment gateway testing
• Webhook testing
• Order email verification
• Inventory validation
• Subscription and scheduled-payment checks
• Customer login testing
• Transaction log review

For high-traffic stores, a simple export-and-import workflow may not be sufficient. More advanced database synchronization or application-level migration techniques may be needed.

Migrating WordPress to a New Domain

Changing the domain adds an SEO and application layer to the migration.

In addition to moving the website, the process should include:

• Updating WordPress URLs
• Replacing old domain references
• Creating page-to-page 301 redirects
• Updating canonical URLs
• Updating XML sitemaps
• Updating analytics properties
• Updating Search Console records
• Updating social profiles
• Updating payment callbacks
• Updating API allowlists
• Updating email addresses where required

A blanket redirect from every old URL to the new homepage is not a good migration strategy. Each important old URL should redirect to its closest equivalent on the new domain.

Protecting SEO During WordPress Migration

A hosting migration that keeps the same domain should normally have limited SEO impact when implemented correctly. A domain change or large structural change requires more planning.

Important SEO checks include:

• Preserving existing URL structures
• Maintaining page titles and metadata
• Keeping canonical tags correct
• Preserving structured data
• Checking robots.txt
• Checking XML sitemaps
• Verifying redirects
• Removing accidental noindex directives
• Checking HTTP status codes
• Monitoring crawl errors
• Monitoring organic traffic after launch

Staging environments are often configured with noindex rules to prevent search engines from indexing them. That setting must not be carried into production accidentally.

It is also important to remove temporary password protection, development redirects, and staging-specific canonical URLs before launch.

Performance Optimization After Migration

A migration provides a good opportunity to improve performance, but optimization should be performed methodically.

Start by confirming that the website is stable. Then review:

• Page caching
• Object caching
• PHP OPcache
• Database performance
• Image compression
• WebP or AVIF delivery
• CDN integration
• Browser caching
• Gzip or Brotli compression
• Slow plugins
• Unused scripts and styles
• External API delays

Do not enable several caching systems at the same time without understanding how they interact. Duplicate caching layers can create stale pages, login problems, checkout issues, and difficult-to-diagnose behavior.

Security Checks After Migration

The new environment should be reviewed before the migration is considered complete.

Post-migration security checks should include:

• Removing temporary migration files
• Removing exported database archives
• Deleting unused administrator accounts
• Changing temporary credentials
• Confirming file ownership and permissions
• Disabling directory listing
• Reviewing firewall rules
• Enabling brute-force protection
• Updating WordPress, themes, and plugins
• Reviewing backup access
• Protecting configuration files
• Confirming malware scanning

Database exports and full-site archives often contain sensitive information. They should not remain publicly accessible inside the website directory after migration.

WordPress Migration Plugins vs Manual Migration

Both methods are valid. The right choice depends on the website.

Migration Plugins

Migration plugins are convenient for small and medium-sized websites. They can package files and databases, update URLs, and simplify restoration.

However, they may encounter:

• File size limits
• PHP execution time limits
• Memory limits
• Hosting restrictions
• Archive extraction failures
• Large database timeouts
• Limited visibility into errors

Manual or Server-Level Migration

Manual migration provides more control and is often more reliable for large, customized, or business-critical websites.

It also allows the migration specialist to inspect logs, control database operations, preserve permissions, perform incremental transfers, and troubleshoot individual layers separately.

The tradeoff is that server-level migration requires stronger knowledge of Linux, databases, DNS, web servers, PHP, SSL, and WordPress internals.

A Practical WordPress Migration Checklist

Before Migration

• Audit the current website
• Record PHP and database versions
• List active integrations
• Export DNS records
• Lower DNS TTL if needed
• Create and verify backups
• Prepare the destination server
• Install required PHP extensions
• Create the destination database
• Plan the maintenance window

During Migration

• Copy WordPress files
• Export and import the database
• Update wp-config.php
• Perform safe URL replacement
• Verify permissions
• Test using a hosts-file override
• Check logs and browser errors
• Test forms, logins, and transactions
• Perform the final database sync
• Update DNS

After Migration

• Verify SSL
• Test email delivery
• Check redirects
• Check sitemap and robots.txt
• Clear all cache layers
• Review application logs
• Monitor uptime
• Monitor search and analytics data
• Keep the old server available temporarily
• Remove migration archives
• Confirm backup schedules

When Should You Hire a WordPress Migration Specialist?

A simple personal website may be moved successfully with a migration plugin. Professional assistance becomes more valuable when the website has operational or commercial importance.

Consider hiring a specialist when:

• The website generates sales or leads
• Downtime has a direct business cost
• The database changes frequently
• The site uses WooCommerce or memberships
• The migration includes a domain change
• Email services share the same DNS zone
• The site contains custom plugins or code
• The destination server requires manual configuration
• The site has a large media library or database
• You need SSL, DNS, redirects, and testing handled together

A professional migration should provide more than a copied website. It should include preparation, backups, testing, DNS coordination, SSL validation, post-migration verification, and a rollback plan.

Final Thoughts

WordPress migration is a technical process, but the real objective is business continuity. Visitors should continue reaching the website, customers should continue completing transactions, administrators should retain access, and search engines should continue finding the same content.

The safest migrations are rarely the fastest-looking ones. They are the migrations where the destination is prepared in advance, backups are verified, the website is tested before cutover, DNS is handled carefully, and the old environment remains available until the transition is confirmed.

Whether the website is moving to a new hosting company, a VPS, a cloud server, or a new domain, a structured migration plan dramatically reduces the risk of downtime, missing data, and unexpected failures.

The post WordPress Migration Without Downtime: A Practical Guide to Moving Your Website Safely appeared first on John Nessime.