That is the moment most people properly meet the command line, usually at the worst possible time. The dashboard is fine for editing a post. It is a bad tool for anything that touches a thousand rows, twelve plugins, or two servers at once.

This is a working list of the WP-CLI commands that save hours, grouped by the job that eats the hours rather than by command name. Each section leads with the failure mode, because with a couple of these the command finishes, prints Success, and leaves you with a subtly broken database that nobody notices for a week.

The migration hour: search-replace, and the one that bites back

Changing a domain by running SQL against wp_posts is how sites break. WordPress stores a great deal of configuration as PHP serialized arrays, and serialized strings carry their own byte length. Change https://old.example.com to https://new.example.org with a plain UPDATE ... REPLACE() and the length prefix no longer matches the string. PHP refuses to unserialize the value, returns false, and the widget or page-builder section silently renders nothing.

The whole point of wp search-replace is that it unserializes, replaces, and reserializes, so the lengths stay correct. Run it in dry-run mode first, every single time:

wp search-replace 'https://old.example.com' 'https://new.example.org' 
  --all-tables-with-prefix 
  --skip-columns=guid 
  --precise 
  --report-changed-only 
  --dry-run

What each flag is actually doing:

• --dry-run runs the whole operation and prints the report without writing. The report has a “Type” column: PHP means the value was serialized and handled properly, SQL means a plain string replacement. If you expected hundreds of changes and see zero, your search string is wrong, not the tool.
• --all-tables-with-prefix widens the scope to every table sharing your prefix, not just the tables registered with $wpdb. Plugins that create their own tables live here. --all-tables goes wider still and will happily rewrite tables belonging to a completely different application sharing the database, so reach for the prefix version first.
• --skip-columns=guid is the one people leave off. The guid column is a permanent identifier for feed readers, not a URL to be followed. Rewriting it makes every historical post look brand new to anything that has subscribed to your feed.
• --precise forces PHP-side serialization handling on every column instead of letting MySQL do the simple cases. It is slower. On a large database it is noticeably slower. It is also the difference between “probably fine” and “definitely correct”.
• --report-changed-only trims the report to tables that actually changed, which makes the output readable instead of a wall of zeros.

Read the dry-run output. When the numbers look right, run the identical command without --dry-run.

The step everyone forgets

You changed the database. Every cache layer still holds the old values. On a site with Redis or Memcached behind a persistent object cache drop-in, the old URLs will keep being served from memory and you will spend twenty minutes convinced the replacement failed.

wp cache flush
wp transient delete --expired
wp rewrite flush

Be aware that on multisite with a shared persistent object cache, wp cache flush can clear entries for every site on the network, not just the one you are working on. Then purge the page cache and the CDN through their own controls. If you are on Cloudflare, the database change means nothing until the edge cache is purged too.

Finally, re-run the dry-run. It should report zero remaining replacements. If it does not, you have a second URL format hiding somewhere: protocol-relative //old.example.com, or an escaped form like https://old.example.com inside JSON stored in an option. Run a second pass for each shape you find.

The plugin conflict hour: bisect without touching the dashboard

Classic scenario: something fatals, the admin is white, and the usual advice is “deactivate all plugins and switch to a default theme.” On a production site that means real downtime while you click through a list.

WP-CLI has two global parameters that skip loading plugins and themes for the duration of a single command. Nothing is deactivated. Nothing is written. The site keeps serving visitors exactly as it was.

# Does WP-CLI work at all with nothing loaded?
wp --skip-plugins --skip-themes option get siteurl

# Is it the theme?
wp --skip-themes option get siteurl

# Skip one specific plugin
wp --skip-plugins=akismet option get siteurl

If the first command works and the unmodified one does not, the fault is in your plugins or theme, not in WP-CLI or WordPress core. From there you can walk the active list one at a time. This one-liner from the WP-CLI handbook does the walk for you:

wp plugin list --field=name --status=active --skip-plugins 
  | xargs -n1 -I % wp --skip-plugins=% plugin get % --field=name

The inner --skip-plugins on the listing command matters. Without it, a plugin broken badly enough to crash the bootstrap will also crash the command that is trying to build the list, and you get nothing.

The honest limitation: skipping a plugin at the CLI does not reproduce browser-side behaviour. If the bug only appears for logged-in users on a specific admin screen, this narrows the field but will not fully confirm the culprit. It still turns a thirty-minute click-through into about two minutes of scrolling output.

The silent-cron hour: scheduled jobs that quietly stopped

This is the invisible failure. Nobody opens a ticket saying “cron is broken.” They open a ticket saying backups have not run since last month, or scheduled posts are stuck in the future, or order emails stopped going out. WP-Cron is not a scheduler. It is a queue that gets drained when someone loads a page, which means a low-traffic site drains it rarely and a fully page-cached site may never drain it at all.

# Can the site reach its own wp-cron.php?
wp cron test

# What is scheduled, and how overdue is it?
wp cron event list

# Drain everything that is due, right now, in this process
wp cron event run --due-now

In wp cron event list, the column to read is next_run_relative. If events are showing as long overdue, the queue is not being drained and you have found your problem.

The fix is to stop relying on page loads. Disable the loopback trigger in wp-config.php, above the “stop editing” line:

define( 'DISABLE_WP_CRON', true );

Then add a real system cron entry for the user that owns the site files:

* * * * * /usr/local/bin/wp --path=/var/www/example.com cron event run --due-now --quiet

Why the CLI form and not a curl of wp-cron.php: wp cron event run executes the events in the current PHP process. No HTTP loopback is involved, so it cannot be defeated by a firewall rule, a reverse proxy, HTTP authentication on staging, or a host that rate-limits self-requests. Errors surface in the cron mail or the log you redirect to, instead of vanishing into a request nobody reads.

One warning. Set DISABLE_WP_CRON and then forget the crontab entry, and you have upgraded an unreliable scheduler into one that never runs at all. Verify with wp cron event list a few minutes later before you close the ticket.

The bulk-edit hour: piping IDs instead of clicking pages

The pattern that does the real work here is --format=ids feeding another command. Once that clicks, most “there is no plugin for this” tasks become one line.

# How many revisions are we carrying?
wp post list --post_type=revision --format=count

# Delete them, skipping the trash
wp post delete $(wp post list --post_type=revision --format=ids) --force

# Every administrator on the site, in one table
wp user list --role=administrator --fields=ID,user_login,user_email

# Regenerate only the thumbnail sizes that are missing
wp media regenerate --only-missing --yes

Two things to know before you run the delete. It is irreversible, so take a database export first. And if the inner command returns nothing because there are no revisions, the outer command gets no arguments and will error rather than doing nothing quietly. That is a harmless failure, but it looks alarming the first time.

Revisions come back unless you cap them. Adding define( 'WP_POST_REVISIONS', 5 ); to wp-config.php keeps enough history to recover from a bad edit without letting wp_posts grow without limit.

For anything you want to script rather than read, add --format=json and pipe it into jq. Every list command in WP-CLI supports it, which makes the whole tool usable as a data source for monitoring and reporting rather than just an admin replacement.

The “is this thing compromised?” hour: checksums

A site is behaving oddly, there is a suspicious redirect, and the first instinct is to install a security scanner. Before that, run the two commands that compare what is on disk against the official hashes on WordPress.org.

wp core verify-checksums
wp plugin verify-checksums --all

These download the published checksums for your exact version and locale and report every core or plugin file that has been modified, plus files that should not exist at all. The core command deliberately avoids loading WordPress, so it still works when the site itself is too broken to boot.

Know the blind spots before you trust a clean result:

• Only plugins hosted on the WordPress.org directory can be verified. Premium plugins, custom code and anything from a private repository have no published source of truth and will be skipped or warned about.
• Nothing in wp-content/uploads is covered. A dropped PHP file in an uploads subdirectory is a common backdoor and checksums will never see it.
• Themes are not covered by an equivalent bundled command.
• Getting a locale or version mismatch produces alarming warnings that are not real findings. Pass --version and --locale explicitly if the output looks wrong.

A clean checksum run is not proof the site is clean. A dirty one is proof it is not, which is worth a great deal in the first five minutes of an incident.

The database hour: find the bloat before you optimise anything

“The site is slow” is not actionable. “One table is carrying most of the database” is. Start by looking, not by running an optimiser.

# Size per table, sorted by whatever is worst
wp db size --tables --human-readable

# Take an export before touching anything
wp db export ~/backups/example-com.sql

# Run a query and strip the ASCII table borders
wp db query 'SELECT option_value FROM wp_options WHERE option_name="home"' --skip-column-names

In practice the offenders are nearly always wp_options stuffed with autoloaded rows and orphaned transients, wp_postmeta from a plugin that never cleans up after itself, or wp_posts full of revisions. Autoloaded options are the sneaky one, because every row marked for autoload is loaded on every request, including requests that will never look at it.

Two clean-up commands worth knowing, and the difference between them:

wp transient delete --expired
wp transient delete --all

The first removes only what has already expired and is safe to run on a schedule. The second removes everything, including live cache entries, which forces WordPress to rebuild them on the next requests. That is safe but produces a short performance dip, so it belongs in a maintenance window rather than in a cron job.

Note that on a site with a persistent object cache drop-in installed, transients bypass the database entirely and wrap the object cache instead. If wp transient delete --all reports nothing, that is usually the reason and not a failure.

The setup that makes everything above faster

If you manage more than one site, the biggest single time saving is not a command at all. It is aliases. Put a wp-cli.yml in a project directory, or ~/.wp-cli/config.yml for a global one:

@production:
  ssh: deploy@example.com/var/www/example.com
@staging:
  ssh: deploy@staging.example.com/var/www/staging

Now you run commands against a remote site from your own machine, without an SSH session:

wp @staging plugin list --status=active
wp @production cron event list

This needs WP-CLI installed on the remote host, and it needs your host to actually give you SSH. That varies more than people expect. A plain VPS from a provider like InterServer or DigitalOcean gives you root and you install what you like. Managed WordPress hosts differ: some ship WP-CLI preinstalled and hand you an SSH key immediately, others restrict which commands you can run, and a few give you no shell at all on entry-level plans. Worth checking before you build a workflow that depends on it.

Two optional packages are worth the install if you do maintenance work regularly:

wp package install wp-cli/doctor-command
wp package install wp-cli/profile-command

wp doctor check --all
wp profile stage

wp doctor runs a set of health checks, including one for autoloaded options size, and gives you a pass or warn per check. wp profile breaks a request into stages so you can see where the time is going before you start guessing.

The honest trade-off: these are separate packages, not bundled commands, and they get less attention than the core set. If you are working across client servers you do not control, installing packages everywhere is friction you may not want. On your own infrastructure they earn their place. For continuous visibility rather than point-in-time checks you still want proper monitoring, whether that is a self-hosted Prometheus and Grafana stack or a hosted uptime service.

Troubleshooting: when WP-CLI itself will not run

Before blaming the tool, run wp cli info. It prints the PHP binary in use, the PHP version, the loaded php.ini, and the WP-CLI version. Most problems are visible in that output.

• “This does not seem to be a WordPress installation.” You are in the wrong directory, or the document root is elsewhere. Pass --path=/full/path/to/wordpress rather than guessing.
• Wrong PHP version. On a control panel server the shell PHP is often not the PHP the site runs on. Check the binary in wp cli info, and invoke the right one explicitly if they differ, for example /usr/local/php83/bin/php $(which wp).
• Memory exhaustion on large operations. The CLI uses its own memory limit, not the web one. Raise it for a single command with php -d memory_limit=512M $(which wp) ... instead of editing configuration globally.
• A fatal error the moment you type anything. Confirm with wp --skip-plugins --skip-themes cli info. If that works, the fault is in site code.
• A warning about running as root. WP-CLI is telling you that files created by this command will be owned by root and the web server may not be able to write to them later. --allow-root silences the warning without fixing the ownership problem. Run as the site user instead, unless you are inside a container where root is the normal case.

Common mistakes

• Running search-replace without --dry-run because you have done it before and it worked.
• Reaching for --all-tables by reflex when --all-tables-with-prefix is what you meant, on a server where several sites share one database.
• Forgetting to flush the object cache and CDN after a database write, then re-running the replacement several times chasing a ghost.
• Setting DISABLE_WP_CRON without adding the system cron entry.
• Treating a clean verify-checksums result as proof that a site is not compromised.
• Running destructive commands over SSH without screen or tmux, then losing the connection mid-write on a large table.
• Using --allow-root as a habit and leaving root-owned files scattered through wp-content.

Best practices

1. Export the database before any command that writes. wp db export takes seconds and has saved more afternoons than any other command in this post.
2. Dry-run first, read the report, then repeat the command verbatim without the flag. Do not retype it.
3. Run as the site user, not root, so file ownership stays correct.
4. Use aliases in wp-cli.yml so you cannot run a staging command against production by muscle memory.
5. Verify after the write. Re-run the read-only version of whatever you just did and confirm it reports zero remaining work.
6. Test the restore path, not just the backup. An export you have never imported is a hope, not a backup.
7. Keep WP-CLI current with wp cli update, particularly before working on a site running a recent PHP release.

Frequently asked questions

Is wp search-replace safe to run on a live site?

Safer than raw SQL, because it handles serialized data correctly. Still a write against production. Export the database first, dry-run first, and use --skip-columns=guid. On a large database the operation can hold the site in a slightly inconsistent state for the duration, so a quiet window helps.

Why do my changes not show up after search-replace?

Almost always caching. Run wp cache flush, purge the page cache and the CDN, then reload. If the old value still appears in a dry-run report, you have a second URL format stored somewhere, such as a protocol-relative or escaped variant.

Does WP-CLI need SSH access?

It needs shell access on a machine that can reach the WordPress files and database. That usually means SSH. Some managed hosts provide a browser terminal instead, and some restrict the available commands. On a self-managed VPS you install it yourself and nothing is restricted.

What is the difference between –skip-plugins and deactivating a plugin?

--skip-plugins prevents the plugin from loading for that one command only. Nothing is written to the database and visitors are unaffected. Deactivating changes site state and takes the plugin offline for everyone, which is why the skip flags are the right diagnostic tool on production.

Can I schedule WP-CLI commands with cron?

Yes, and that is the recommended way to run WordPress scheduled events reliably. Use the full path to the wp binary, pass --path, run as the site user, and redirect output so failures are visible rather than silent.

Will verify-checksums detect all malware?

No. It compares core files and WordPress.org-hosted plugins against published hashes. It does not cover themes, premium or custom plugins, or anything in the uploads directory. Treat a failure as a definite finding and a pass as one data point among several.

Which WP-CLI commands should I learn first?

wp db export, wp search-replace --dry-run, wp --skip-plugins, and wp cron event list. Those four cover backup, migration, conflict isolation and the most common silent failure on a WordPress site.

The one thing worth remembering

Most of the WP-CLI commands that save hours do it by turning a job you cannot see into a job you can read. --dry-run shows you the write before it happens. wp cron event list shows you a queue that was failing silently. verify-checksums shows you a file that changed without anyone deciding it should.

The speed is real, but the speed is not the point. The point is that you stop guessing. If you take one habit from this post, take the dry-run: run the read-only version, read the output, then run the identical command for real. That single pattern prevents the majority of the incidents I see caused by command-line work on WordPress.

Need a hand with this?

I work on WordPress infrastructure, and command-line automation is most of what makes that maintainable. Things I can help with directly:

• Domain and host migrations run properly, with staged dry-runs, correct table scoping and a verified rollback before anything is written.
• Replacing WP-Cron with real system cron across a fleet, including alerting when a job stops firing instead of finding out weeks later.
• Writing repeatable WP-CLI maintenance scripts, with proper exit codes and logging, so they can be scheduled rather than remembered.
• Diagnosing slow WordPress sites at the database layer, from autoloaded options and table bloat down to the query causing it.
• Incident triage on a site suspected of being compromised, starting with integrity checks and file-level evidence rather than a scanner plugin.
• Setting up multi-site management workflows with WP-CLI aliases, SSH keys and deployment pipelines that do not depend on anyone opening the dashboard.

If something specific is going wrong, send the actual output. A dry-run report, a wp cli info dump, a wp cron event list table, and I can usually tell you where the problem is before we talk about scope.

The post WP-CLI Commands That Save Hours (And the One That Bites Back) appeared first on John Nessime.

Then it clicks. Somebody logged into wp-admin last month, saw an update notice, clicked it. The plugin got updated on the server and never in git. Last night’s deploy synced the repo over the top and put the old version back, along with the vulnerability the update was patching. No error, no warning. The deploy did exactly what it was told.

That is the failure mode that kills most attempts at Git-based WordPress deployment, and it has nothing to do with your pipeline. WordPress is designed to modify itself. It installs plugins, updates core, writes files, all from the browser. The moment you put it under version control you have two systems that both believe they own the file tree, and they will quietly overwrite each other until somebody notices.

This post covers the whole chain: what belongs in the repo, how to shut the second write path, how configuration differs per environment, which way the database is allowed to travel, and how to make staging safe enough that you can restore production data into it without emailing your customers by accident.

The two things that make WordPress awkward under Git

Everything in this workflow follows from two facts.

State is split across files and a database. Your theme is code. Your posts are data. But so are your plugin settings, your menus, your widget layouts, and your permalink structure, and those live in the database next to the content. Git only manages half your site, and it is not obvious which half a given change landed in.

The two halves travel in opposite directions. Code moves forward, local to staging to production. Content moves backward, production to staging to local. Once a site is live, production is the only authoritative source of orders, comments and posts, and pushing a database upward destroys everything written since your last pull.

Write that rule somewhere the whole team can see it. Almost every catastrophic WordPress deployment story is somebody pushing a database in the wrong direction.

Decide what actually goes in the repo

Three approaches, in increasing order of discipline and payoff. Pick one deliberately rather than drifting into the first.

1. Theme only. The repo contains one custom theme, sometimes a custom plugin. Everything else is installed through wp-admin. Easy to start, and it means you have no reproducible build: rebuilding the site from the repo is impossible.
2. All of wp-content, minus uploads. Themes, plugins and mu-plugins in git; core and media excluded. This is the pragmatic middle and where most teams land. You get reproducible plugin versions and a real diff when a plugin changes.
3. Composer-managed, Bedrock-style. Core, plugins and themes are all declared as dependencies. The repo holds a composer.json and your own code, nothing else. The lockfile is the source of truth and composer install rebuilds the site anywhere.

Option three is the one I reach for on anything with more than one developer, because “which plugin version is production running” becomes a question with an answer. The honest cost: premium plugins that are not on a Composer repository need either a private repository or a manual step, and that friction is real. If most of your plugin stack is commercial, option two is a reasonable place to stop.

One thing to check if you are following an older tutorial. The Composer repository landscape for WordPress plugins shifted recently: WPackagist was acquired by WP Engine, and the Roots team launched WP Packages as an independent alternative with different package naming. Both work. Any guide written before that change will use the older wpackagist-plugin/ prefix, so make sure the repository URL and the prefixes in your composer.json match each other.

The gitignore that matters

# Secrets and machine-specific config. Never committed.
wp-config.php
.env

# Content, not code. This gets pulled down from production,
# it never gets deployed up.
wp-content/uploads/

# Generated at runtime or by the build.
wp-content/cache/
wp-content/upgrade/
wp-content/debug.log
node_modules/
vendor/

Ignoring vendor/ assumes your deploy runs composer install. If your pipeline just rsyncs the repo with no build step, commit it instead, or you will ship a site with no dependencies. Decide which, then be consistent, because half-and-half is how you end up with a missing autoloader at two in the morning.

Close the second write path

This is the step people skip, and it is the one that makes everything else work. If production can still install and update plugins from the browser, your repo is not the source of truth. It is a suggestion.

// wp-config.php on production and staging.

// Removes the ability to install, update or delete plugins and
// themes from the admin. Also disables the built-in file editor,
// so DISALLOW_FILE_EDIT is implied by this one.
define( 'DISALLOW_FILE_MODS', true );

// Stops core from updating itself behind your back, including
// the automatic minor updates that would otherwise change files
// your deploy is about to overwrite.
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Be clear-eyed about the trade-off, because it is a real one. You have just taken away automatic security updates. That is only an improvement if you replace them with something: a scheduled dependency update job, a weekly review of the update list, a bot that opens a pull request when a plugin version changes. If you disable updates and then do nothing, you have made the site less safe, not more controlled.

The update flow now runs through the repo. On your local machine:

# Composer-managed: bump the lockfile, commit it, deploy.
composer update wp-plugin/some-plugin

# wp-content-in-git: let WP-CLI do the download locally,
# then commit the resulting file changes as a normal diff.
wp plugin update some-plugin

The second form is worth appreciating. A plugin update becomes a reviewable diff. When something breaks two days later, git log tells you exactly which files changed and git revert puts them back.

Configuration per environment

Database credentials, salts and API keys differ per environment and none of them belong in git. Keep wp-config.php out of the repo and place it on each server, or use an environment file with a committed .env.example showing the required keys with no values.

Core has a first-class way to tell environments apart, and it is underused:

// Per environment, in wp-config.php.
// Recognised values: 'local', 'development', 'staging', 'production'.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

<?php
// mu-plugin, committed to the repo, safe on every environment
// because it checks where it is running.

if ( wp_get_environment_type() !== 'production' ) {

    // Keep non-production sites out of search results.
    add_filter( 'pre_option_blog_public', '__return_zero' );

    // Short-circuit wp_mail() entirely. Returning a non-null
    // value stops WordPress before it hands anything to PHPMailer.
    add_filter( 'pre_wp_mail', '__return_false' );
}

That mail filter is the single most valuable line in this post. Restore a production database onto staging, forget this, and the first cron run mails real order confirmations, password resets and abandoned-cart nudges to real customers from a URL that does not work. It is silent until it is very loud.

Moving the database in the allowed direction

Set up WP-CLI aliases once and the rest becomes short commands instead of a runbook nobody follows.

# wp-cli.yml in the project root, committed to the repo.
@staging:
  ssh: deploy@staging.example.com/var/www/staging.example.com
@production:
  ssh: deploy@example.com/var/www/example.com

Now pulling production down to your machine is one pipe. The trailing hyphen means “write the dump to standard output”, and the leading hyphen on the import means “read it from standard input”, so nothing touches disk:

# Back up your local database first, then overwrite it.
wp db export local-backup.sql
wp @production db export - | wp db import -

The URLs inside that dump still point at production, and they are buried in serialized PHP arrays where a plain SQL find-and-replace corrupts the string length prefixes. This is exactly what wp search-replace exists for: it unserializes, replaces, and reserializes properly.

# Always dry-run first and actually read the table list it prints.
wp search-replace 'https://example.com' 'https://example.test' 
  --all-tables-with-prefix --skip-columns=guid --dry-run

# Then for real.
wp search-replace 'https://example.com' 'https://example.test' 
  --all-tables-with-prefix --skip-columns=guid

wp cache flush

Two flags worth understanding rather than copying:

• --skip-columns=guid because the guid column is a permanent identifier that feed readers and external systems use to decide whether they have already seen a post. Rewriting it makes subscribers re-receive your entire archive, and you find out from an angry email weeks later.
• --all-tables-with-prefix because plugins create their own tables using your prefix, and those tables are not registered with WordPress. Without this, the replacement misses them and you get half-migrated URLs in places nobody checks.

Uploads are the other half of the content problem. Do not put them in git; a media library will outgrow a repository quickly and every clone pays for it. Sync them separately with rsync when you need them, or skip them entirely locally and let a plugin proxy missing images from production. Offloading media to object storage sidesteps the question completely and is worth considering on any site with a large library.

The deploy itself

Three broad options. git pull on the server is the simplest and the one I would move away from first: it puts a .git directory next to your document root, it has no build step, and a failed pull leaves the site half-updated. Rsync from CI is the pragmatic default. Atomic releases with a symlink swap, the way Deployer or Capistrano work, are the most correct because the site switches versions instantly and rollback is a symlink change.

A workable rsync deploy from GitHub Actions, with staging on merge and production on tag:

name: Deploy
on:
  push:
    branches: [main]     # goes to staging
    tags: ['v*']         # goes to production

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4    # pin to a full SHA in production

      - name: Build
        run: |
          composer install --no-dev --optimize-autoloader
          npm ci
          npm run build

      - name: Sync files
        run: |
          echo "$DEPLOY_KEY" > deploy_key
          chmod 600 deploy_key
          rsync -az --delete 
            -e "ssh -i deploy_key -o StrictHostKeyChecking=accept-new" 
            --exclude-from=.deployignore 
            ./ "$TARGET"
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
          TARGET: ${{ secrets.DEPLOY_TARGET }}

--delete is what makes the target match the source exactly, which is the entire point of a deploy. It is also the flag that will erase your uploads directory if .deployignore is wrong. Test the exclude list against staging before you ever point this at production, and use --dry-run the first time.

Files landing on the server is not the same as a working deploy. Run a post-deploy step over SSH:

#!/usr/bin/env bash
set -euo pipefail

cd /var/www/example.com

# Applies schema changes that a core or plugin version bump needs.
# Safe to run when there is nothing to do.
wp core update-db

# Rewrite rules live in the database, so a plugin that registers
# new routes needs this or you get 404s on the new URLs.
wp rewrite flush

# Options and transients are cached; stale ones survive a file deploy.
wp cache flush

# Prove the site answers before you call the deploy finished.
# --fail makes curl exit non-zero on a 5xx instead of shrugging.
curl --fail --silent --show-error https://example.com/ > /dev/null

If you run PHP-FPM with OPcache, add a reset to that script. Otherwise PHP happily serves the previous version of your code from its compiled cache and you spend twenty minutes convinced the deploy did not run.

Making staging safe to hold real data

Staging is only useful if it mirrors production, and the moment it does it becomes dangerous. Every one of these has bitten somebody:

• Outbound email. Covered above. Kill it at the wp_mail() level rather than trusting a plugin setting somebody can toggle.
• Cron. A restored production database brings production’s scheduled jobs with it. Set DISABLE_WP_CRON on staging and do not add a system cron job unless you specifically need to test scheduling.
• Payment gateways. The database carries live API keys. Overwrite them with test-mode credentials as part of your restore script, not by hand afterwards.
• Search indexing. Filter blog_public as shown, and put HTTP basic auth in front of the whole environment. Duplicate content ranking above your real site is an avoidable embarrassment.
• Personal data. A production restore is real customer data on a server that probably has weaker access controls. Either anonymise user records during the restore or treat staging with the same seriousness as production.

Write the restore as a single script that does all of this in order, so nobody has to remember step four. If it is a checklist in a wiki, it will be skipped.

Troubleshooting

The deploy ran but the site is unchanged

In order: OPcache serving compiled bytecode, a page cache or CDN holding the old response, or rsync excluding the directory you edited. Check them in that order. Confirm the file on disk actually changed before blaming anything upstream of it.

White screen immediately after deploying

Usually a missing autoloader, meaning vendor/ was neither committed nor built. Check the PHP error log rather than guessing. A memory limit lower on the server than locally is the other common cause, and it produces the same blank page.

Site works, admin redirects in a loop

siteurl and home in the options table disagree with the URL you are actually using. Almost always a search-replace that missed. Check with wp option get siteurl and wp option get home, and set them explicitly with wp option update rather than running the replacement again.

Serialized data broken after a migration

Somebody ran sed or a SQL REPLACE on the dump. The length prefix inside each serialized string no longer matches the string, so PHP silently fails to unserialize and widgets, theme options and ACF fields come back empty. Restore from the dump and redo it with wp search-replace. There is no partial recovery worth attempting.

Permalinks return 404 after deploy

Rewrite rules are stored in the database and did not get regenerated. Run wp rewrite flush. If it recurs on every deploy, add it to the post-deploy script permanently.

Plugin reverts to an older version after every deploy

Somebody is still updating in wp-admin. That is not a pipeline bug, it is the second write path being open. Set DISALLOW_FILE_MODS and give the team a documented way to request an update.

Common mistakes

• Committing wp-config.php, and with it your database password and salts.
• Putting wp-content/uploads in the repo, then wondering why clones take ten minutes.
• Pushing a staging database over production because “the content is the same”. It never is.
• Using sed or SQL to swap URLs instead of wp search-replace.
• Replacing the guid column, and re-sending your archive to every RSS subscriber.
• Running rsync --delete against production without testing the exclude list.
• Leaving updates enabled in wp-admin, so the repo and the server drift apart silently.
• Disabling automatic updates without putting a review process in its place.
• Restoring production data onto staging with mail still enabled.
• Forgetting DISABLE_WP_CRON on staging, so scheduled jobs fire twice across two environments.
• Treating “the files copied” as proof the deploy worked, with no smoke test.

Best practices

• Make the repo the only way code reaches a server, and enforce it with DISALLOW_FILE_MODS.
• Keep code moving forward and content moving backward, and state that rule where the team can see it.
• Deploy staging from a branch and production from a tag, so production releases are deliberate.
• Dry-run every search-replace and every rsync the first time.
• Back up the target database immediately before any deploy that touches it.
• Script the staging restore end to end, including mail, cron, keys and anonymisation.
• Finish every deploy with a real HTTP request through the public URL, not a file listing.
• Use environment-aware code with wp_get_environment_type() instead of commented-out blocks.
• Keep uploads out of git and sync or offload them separately.
• Replace automatic updates with a scheduled dependency review, and put it in a calendar.

FAQ

Should WordPress core be in the repository?

Only if you are not managing it another way. Committing core works and makes the repo self-contained, at the cost of noisy diffs on every update. Declaring core as a Composer dependency is cleaner and gives you a pinned version without the noise. What you should not do is leave core unmanaged, so nobody can say which version production runs.

How do I handle the database in a Git workflow?

You do not put it in Git. Git handles code; the database is handled by scripted pulls in one direction. Production to staging to local, with a search-replace on import. The only time a database legitimately goes upward is the initial launch, before there is real content to lose.

What about plugin settings changed in staging?

This is the genuinely hard part and there is no clean answer. Settings live in the database, so they do not deploy. Options are: reapply them by hand in production with a documented checklist, script them as WP-CLI commands in a deploy step, or use a plugin that exports configuration to files. Whichever you pick, write it down, because “I’ll remember” is how a setting gets applied to staging and never production.

Is Bedrock necessary?

No. It is a well-made set of defaults for Composer-managed WordPress with environment-based configuration, and it saves assembling those pieces yourself. Plenty of teams run a perfectly disciplined Git deployment with a standard directory layout. Adopt it if you want the conventions; do not adopt it as a prerequisite.

Do I need three environments?

You need local and production. Staging earns its cost when you have multiple people, a client who signs off on changes, or a site where breakage costs money. On a personal blog it is overhead. On a store, skipping it means production is your test environment.

Can I do this on shared hosting?

Partly. You need SSH and ideally WP-CLI, and plenty of shared plans have neither. Some managed WordPress hosts offer a git push deployment target, which handles the file half for you. If you want the full workflow with your own build steps and post-deploy hooks, a small VPS from a provider like InterServer gives you the SSH access and cron control the workflow assumes.

How do I roll back a bad deploy?

Files are easy: redeploy the previous tag, or swap the symlink back if you use atomic releases. The database is the hard part, which is why you take a dump immediately before any deploy that runs a migration. Rolling files back without rolling the database back can leave you worse off than the broken version, so know which of the two actually changed before you act.

The one thing to remember

Git-based WordPress deployment is not really a pipeline problem. The pipeline is the easy part, and you can build a working one in an afternoon. The hard part is making the repo the only way code reaches a server, and then keeping the database flowing in exactly one direction.

Get those two right and everything else is detail. Get them wrong and you will keep having the same confusing morning, staring at a plugin version that nobody remembers changing.

Want this set up properly on your site?

Retrofitting version control onto a live WordPress site is fiddly work, mostly because you have to do it without downtime and without losing whatever has been changed directly on the server. Things I take on:

• Moving an existing production site into Git without downtime, including reconciling whatever has drifted on the server.
• Converting a site to Composer-managed plugins and core, with a working lockfile and a sane update process.
• Building local, staging and production environments that actually match, with per-environment configuration.
• Deploy pipelines in GitHub Actions or GitLab CI: build, rsync or atomic releases, post-deploy WP-CLI steps, smoke test, rollback path.
• Scripted database refreshes from production to staging with mail, cron, API keys and personal data handled automatically.
• Server setup for the workflow: SSH deploy users, correct file ownership, OPcache resets, cron.

Tell me how your site is hosted and how plugins currently get updated, and I will tell you what the first step should be.

The post Two Sources of Truth: Git-Based WordPress Deployment From Local to Production 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.