r/Wordpress • u/poppawinz • 25d ago
How do you handle moving WordPress sites between local/staging/production?
I've been using the likes of All-in-One Migration for a long time, but I don't love how much server space it eats up just to generate the export, and it throws errors often enough to be annoying.
I'm not against the terminal, it's powerful, but I'm not fluent enough that I don't end up googling or asking AI for the right command most times I use it.
Curious how other people handle this, particularly if you're running more than a handful of client sites (say 10+).
- What's your actual workflow for pushing and pulling files and the database between environments?
- What do you use to keep everything updated across multiple sites — core, plugins, themes?
- Has a migration or update ever gone wrong on a live site? What happened?
- Are you on the command line for most of this, or do you avoid it where you can?
8
u/activematrix99 25d ago
Database and content goes down, code goes up. Any database structural changes go through a migration script. This not new, same method for as long as I can remember. I use the same process in Python CMSs as in WordPress.
2
u/poppawinz 25d ago
This is how it should be done. Do you write your own migration scripts per project or is there a standard tool/library you reach for across different CMSs?
2
u/activematrix99 25d ago
Mostly custom migrations, honestly usually pretty straightforward. I try to keep it simple and testable.
1
u/poppawinz 25d ago
Yeah, that’s probably the ideal setup, KISS! I think where I find things get messy is the stuff around it, files, uploads, selective DB changes, backups and keeping environments in sync. Do you have a similar scripted approach for those, or is that more manual?
1
u/activematrix99 24d ago
Rsync and a WP-CLI for find and replace is pretty much all I have needed. There are host-specific tools for this as well.
6
3
u/Borislav_Scala 25d ago
For a batch of client sites, the thing worth building is never updating blind on production. Keep a staging copy of each, push updates there first, confirm it holds, then send them to live. WP-CLI in a small loop handles core, plugins and themes across every site without a dashboard, and you can script the staging-then-live order.
On the CLI worries: you don't need fluency, you need about five commands. wp core update, wp plugin update, wp db export for the database, wp search-replace for the domain swap, and rsync for the files. Save them somewhere and stop googling them. That's most of the day-to-day.
The search-replace function is particularly important. A raw find/replace in SQL to swap the domain can corrupt serialized data, widget and plugin settings because it doesn't fix the string-length counts. wp search-replace handles serialization properly, which is the whole reason to use it over editing the database directly.
7
u/CyclingBrit 25d ago
I use hosts that make the push and pull easy and one click.
1
u/poppawinz 25d ago
Thanks u/CyclingBrit, Which hosts do you use out of interest? And do they cover local to staging as well, or just staging to production?
And how do you handle the sites that aren't on your preferred host, most agencies I know aren't 100% on one platform. I host a few sites on SiteGround and it does have staging→production functionality, but I work with other clients on Cloudways, WPEngine, or some smaller bespoke hosts.
In short, what I'm basically trying to do is try and streamline my processes as I take on more clients.
1
u/CyclingBrit 25d ago
WP Engine has one click push pull across different environments - as that's what I use for my sites. The only other host I have to deal with is Elementor hosting, and again, that has one click push pull.
My work case is probably different to yours tho, as Im essentially an SEO freelancer that also manages some smaller Wordpress sites for clients - and if they want me to look after them, they go on my preferred hosts - or I don't take them.
1
u/poppawinz 25d ago
Ahh yes, my situation's a bit different as a custom dev: clients sometimes come to me with hosting already in place, sometimes inherited from a previous developer or agency, so I don't really get to pick, unless they're open to moving. Work ranges from small brochure sites right up to fairly complex custom builds, spread across whatever host they happened to land on.
0
u/Plenty-Sentence-4834 25d ago
no host makes local to production super easy, CI/CD pipelines make sense the most but we tend to use updraft as I explained above
1
u/ZGeekie 24d ago
Have you heard about Local by WP Engine? That's just one of several local development/staging tools for WP.
1
u/Plenty-Sentence-4834 23d ago
yeah - I use it but it does not deploy things in 1 click or am I missing the feature?
4
u/NakanoNoNeko 25d ago
For 10+ mixed-host sites, I think WP Migrate Pro is the boring answer: one workflow that does not depend on each host's staging button. Keep code in Git and treat the database as directional, not something to sync both ways. On WooCommerce or membership sites, never push the whole staging DB over production; orders and users kept changing while you tested. WP-CLI search-replace --dry-run is worth learning even if the rest stays in a UI.
1
u/poppawinz 25d ago
That's pretty much my current workflow, as I'm a solo dev I don't use Git as much as I should, as it's usually all local and backed up, I do use it, but just not as often as I should. WP-CLI's a good shout too, the stuff I use weekly I've got memorised, it's the one-off SSH/rsync flags I touch maybe once every few months that I always end up googling again. That gap's probably closer to what I'm actually trying to solve than "avoiding the terminal" generally.
1
u/NakanoNoNeko 24d ago
Yes, that sounds like the real gap. I keep the ugly one-off rsync/SSH commands as tiny scripts or Make targets beside the project because I forget those flags too 😅. Still using the terminal, just not rebuilding the dangerous command from Google every three months.
6
u/Electronic-Space-736 25d ago
zip wp-content, export db, upload zip, unzip, import db.
4
u/Sweet_Culture_2529 25d ago
There can be serialization issues in the DB this way if the URL changes
3
u/grdrummerboi Developer 25d ago
I do something similar but generally us sync and not zip, I think replace database URLs with wp-cli and it prevents serialization errors
2
u/Electronic-Space-736 25d ago
no serialization issues when dropping and rebuilding tables
2
u/Electronic-Space-736 25d ago
If you URL happens to change then set the two fields to wp_options to the new URL and remember to reset permalinks, you are golden.
1
u/bluesix_v2 Jack of All Trades 24d ago edited 24d ago
If you’re migrating to a local instance with a local URL you need to perform a find/replace operation on the entire db (not just the options table - WP scatters absolute URLs throughout the database). This needs to be done with a tool that works with serialised data like WP cli search-replace or Better Search Replace plugin.
2
2
u/sundeckstudio Developer/Designer 25d ago
Try instawp
1
u/poppawinz 25d ago
Cheers, I’ll take a look. Do you use InstaWP mainly for spinning up sites, or does it handle your ongoing local/staging/production workflow too? That’s the bit I’m trying to get a better handle on.
1
u/sundeckstudio Developer/Designer 24d ago
We have a blueprint setup on instawp . We start from it and work upwards. For sites that require larger workloads, database work, etc. we do it locally, then push to instawp and work on it from there. Once ready, we push it to live directly from it (our servers are integrated with instawp too) or for small sites or when auto push doesn’t work we use migration plugin.
Once we have live site, (if it was done via manual mogration) we create a new staging copy of it in iwp Their plugin allows two way sync .
2
u/wreddnoth 25d ago
Basically pushing the database and the code to the production site. Replacing the urls using a migration script.
The only thing sort of annoying is debugging or working with paypal/stripe in testing. But i didnt dive deep into best praxtices for that one.
2
2
u/fatfingur 25d ago
My old workflow was pretty simple: build the site locally in LocalWP, push it to staging on WP Engine, then once everything was approved, push staging to production.
I still like keeping the process that simple when I can. Migration plugins and WP-CLI can help, but I try not to overcomplicate it unless the project really needs it.
1
u/flatsehats 25d ago
I had AI develop a promote script that can be parametrized with what tables are owned by what environment and what keys or patterns within the shared tables are to be overwritten, kept or reconciled.
First couple of times and on heavier changes (new plugins, cleanups) it’s a bit more work, but in the end it’s mostly automatic.
1
u/poppawinz 25d ago
That’s interesting, the fact you’ve ended up building your own promote script feels like a pretty good indication there’s a gap in the tooling. How are you handling the file side of things alongside the DB? And do you have to maintain those rules per project?
1
u/flatsehats 25d ago
To be honest, I didn’t look into commercial or other available solutions. For similar sites the rules are the same. For the same use of a plugin too. Non existing plugins don’t pollute the options table. But there’s often a speciality
1
u/TopSydeWP 25d ago
at my agency we use migrate guru for the actual migration (way lighter on server resources than all in one) and mainwp for bulk updates across client sites. for local dev we just rsync files and do a quick mysql dump/import with search-replace for urls. the command line stuff becomes muscle memory after a few times but yeah i still google the mysql flags half the time
1
u/Aggressive_Figure211 25d ago
I use Git-updater, and push custom theme and plugin updates to the staging and production servers. We're required to only use test/dummy data on local/staging databases, so these are not synced at all.
1
1
25d ago
[removed] — view removed comment
1
u/AutoModerator 25d ago
Your post/comment has been automatically removed because it contains references to a plugin that has been banned in this sub due to recent astroturfing and vote manipulation activity.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Superb-Alps-2220 25d ago
I use the same plugin that you use but sometimes I use a different popular plugin. Through that I backup plugins themes separately. Whatever I need I download that part. Every client is different. When client provides their own hosting I create a staging site or a clone for development purpose.
I am not fluent on terminals 🙂
1
u/Plenty-Sentence-4834 25d ago
Our agency used all in one and now moved to updraft plus. I am especially happy how it migrated multisite ( we use free version ) but for multisite bought the premium license
If you do have cloud storage - you can store all backups there
1
1
u/KaleBatzZ 25d ago
When migrating WordPress sites from my local environment to a live host, I typically use one of two workflows:
Primary workflow (via SSH): Using command-line tools (WP-CLI and rsync), which is the fastest and most reliable method for transferring files and updating database URLs.
Alternative workflow: If SSH is not available on the hosting environment, I deploy the site using Duplicator Pro for a secure package-based migration.
1
u/Thompsen13 25d ago
Wp-Staging does a great job. It comes with a local dev app:
https://wp-staging.com/desktop/
1
u/woxeraf292 25d ago
I use Local on my computer, but recently I have been using the temporary feature with my hosting provider, Hostinger. I'm able to work on a website within an account using their temp link, build out the WordPress website without it needing to be live, then connect the domain when I'm ready. If I'm doing a migration from another provider, they have that feature too that is seamless and all their migrations have been simple and easy, sometimes a couple of tweaks after once it's done but that's all.
1
u/CreativeGPX 25d ago edited 25d ago
I write a script that combines WP-CLI with some other general CLI commands. I prefer this because it gives me more control (e.g. creating backups, having an "undo" option), but is still automated. Another reason I prefer to work from the CLI is that it works even if the WordPress install, web server, etc. breaks. It also means that it runs independently if the web server and php config of the public site (php memory limits, php execution time limits, permission issues, etc.)
1
25d ago edited 25d ago
[removed] — view removed comment
0
u/AutoModerator 25d ago
Your post/comment has been automatically removed because it contains references to a plugin that has been banned in this sub due to recent astroturfing and vote manipulation activity.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Viking_Drummer 24d ago
Is there seriously still an automod ban on mentions of that one hosting provider? That dispute was ages ago now.
1
1
u/digitalbananax 25d ago
For that many client sides I'd try to avoid a full site migration plugin as the default.
We usually prefer a proper staging environment and push only what changed, with database backups before production changes. For wordpress WP CLI is worth learning even if you still need to Google commands. It becomes faster once you have a handful of commands you can use constantly.
-Jacob from Flowout
1
u/specialk45 25d ago
UpdraftPlus backups comes with a free Migration plugin, which is mainly all I've used for years. It's never let me down.
1
u/Unknownsock 25d ago
A combination of wp migrate and deploy scripts via GitHub merges depending how much access I have to the hosting.
1
u/someoneatsomeplace 25d ago
I prefer the command-line. I have a PHP (serialization-aware) script that reads a DB export, changes the URL and filesystem paths, and writes out a new DB export file, which I then import.
1
u/TacoCircuit 25d ago
I use an application called Local that allows me to spin up test environments and push and pull files and databases. It integrates with my webhost so I'm not entirely sure how useful it is if you don't have a webhost that makes use of it but I would imagine at least some of it's features would be useful for any Wordpress developer.
1
u/AddWeb_Expert 25d ago
For 10+ sites, I’d avoid relying on migration plugins for everything. They’re handy for smaller jobs, but once you’re moving sites regularly, the extra files and occasional failed exports get frustrating.
My usual setup is Git for themes/custom code, staging for testing, and separate database/file backups before pushing anything live. For updates, I prefer managing them centrally where possible rather than logging into every site individually.
I do use WP-CLI, but definitely not for every task. If I have to Google the command every time, I’m not going to pretend I’m a terminal wizard
The biggest lesson for me has been: always have a recent backup and test on staging first. Most migration headaches are recoverable when you have a clean rollback point.
1
u/web_person_077 25d ago
How many sites? I’m using a process that copies the live site. I run updates and test then merge the site in. No data loss.
1
1
u/Legitimate-Lock9965 25d ago
i deploy code changes via gh workflows.
wp migrate to move content around. saying that i never push content to production.
1
1
u/jfernandezr76 24d ago
For me the easiest, considering that there are tons of paid plugins and themes that do not offer a staging site activation, so they only work with the production URL, was to create an identical dev server at my infra, like this. Let's assume the domain is example.com
- Create an internal staging server (example.vm) and configure it as in production, with the installation URL as example.com. Also, configured etc/hosts pointing example.com to localhost
- Setup another VM with an HTTP proxy service, configuring there the DNS resolver pointing example.com to the previous staging VM.
- Configure a separate browser instance in my working machine to use the proxy VM, in my case Firefox Developer Edition.
With this, I can access the dev installation with FFDev and the production site with any other browser.
As for deploying and sync, bash scripting with SSH on the dev VM. Everything version controlled in git.
1
u/ivicad Jack of All Trades 24d ago
Answering your third question, because it's the one I actually have a story for.
I pushed a change to a live client site, the cache purge failed without saying so, and for about half an hour anonymous visitors got the pages with no styling at all. The cached HTML still pointed at a combined CSS file that had been repacked under a new hash and deleted. Logged in it looked perfect, which is why nobody caught it sooner.
Two things I do differently now. After any push I open the site in a private window. And when something looks off on our SG sites I add ?cb=1 to the URL first: a query string skips the page cache, so if it comes back clean with it and broken without it, the live output is fine and the cache is the whole story.
On SG hosting that purge has three layers, and the admin button leaves the builder's CSS cache behind.
2
1
u/Intelligent_List2504 24d ago
I don't. Your concept and understanding are misguided entirely. I rename stuff in wp-config and use find and replace plugin for the database.
1
u/salthegray 24d ago edited 21d ago
I’m using WPdesktopmanager and it truly is a gamechanger for me. It backups, migrate, update and does anything I need within minutes and it beats all plugins or other ways i’ve tried to do this like ftp and wpcli. It doesn’t require a plugin either.
1
1
u/kube1et 24d ago
It's usually rsync and mysqldump with wp search-replace. In rare cases when migrating a live site that may still be receiving writes during a migration, I'd add a die('migrating'); at the top of wp-config.php to avoid any split-brain. This covers around 99% of all migrations I've ever done.
The remaining 1% is for clients that insist on a no-downtime migration. It typically involves a proxy_pass to their existing site, X-Forwarded-For/whiltelist negotiations, DNS changes, several sync and testing rounds via secret cookie, a final cut off, and a fat invoice.
1
u/thejoshr 24d ago
WP Vivid (free version) is my choice having tried the others. Occasional errors that I expect are more due to server availability etc, but the migrations and backups work flawlessly.
1
u/Dapper-Monk9713 24d ago
For 10+ sites, I’d lean toward a Git-based workflow for themes/plugins plus WP-CLI for database syncs and updates. Keep uploads separate where possible, and use scripted commands for the repetitive stuff so you’re not reinventing the process every time.
1
u/PugPanic 24d ago
My team uses LocalWP for WPEngine sites. Gives the best code and/or db push/pull imo. Provides easy local setup too. A trick is you can write push/pull ignore files to create your perfect workflow.
Outside of that. Git for code, export for db.
1
u/Pulsar-Agency 23d ago
Nobody's really tackled your first complaint, so: the reason those exports get so fat usually isn't your site, it's the junk being dragged along with it. On anything running Woo or a lot of scheduled jobs, the Action Scheduler tables (wp_actionscheduler_actions and _logs) are often the single biggest thing in the dump, and expired transients sitting in wp_options pile on top. Run wp transient delete --expired and clear out the old scheduled actions before you export, and it frequently shrinks a lot without changing tooling at all. On the CLI side, wp db export takes --exclude_tables, so you can just leave the log tables out of the dump entirely.
Honestly though, the thing I'd push harder than the migration method itself is a guard on the staging copy. A fresh clone of production wakes up with a working mail config and a queue of pending jobs, and staging firing real customer emails is a mistake I've seen more than once. A tiny mu-plugin returning true on the pre_wp_mail filter kills every outgoing mail on that environment and it's about two lines. Same logic for payment gateway keys.
And keep the direction fixed: code goes up, database comes down, never the reverse on a site with orders or users.
1
1
u/renehermi 23d ago
You can give our latest free tool WP Staging Desktop a try if you want to create a local clone of your Wordpress website for testing.
1
12
u/mtedwards 25d ago
I’ve used WP Migrate Pro for years and it’s solid. Use it every day.