migro

Stop using site-migration tools for editorial work.
Plugins like Duplicator and All-in-One WP Migration were built for moving hosts. Clone the whole database, overwrite everything, hope nothing breaks. That’s the wrong tool for the weekly grind of pushing finished posts to production.
Migro is built for that weekly grind.
Pick a post. Click Push. Migro deploys only that post (with its categories, tags, featured image, embedded media, and alt text) and leaves the rest of the destination site untouched. Pull works the same way in reverse: grab live content back to staging for testing.
<h4>Built for agencies and freelancers</h4>
You’re managing client sites with a staging-to-production workflow. The writer drafts on staging, you review, you deploy. Maybe the client wants to push their own finished drafts. Migro handles all of it:
<ul>
<li>Selective deployment. Pick exactly the posts that should move. Nothing else on the destination changes.</li>
<li>Bidirectional Push and Pull. Push staging to production, or pull production back to staging. Same flow either way.</li>
<li>Sync-key tracking. Re-deploying the same post updates it in place, even if its slug or ID differs on the destination.</li>
<li>Backups before every overwrite. One-click restore if a deployment was wrong.</li>
<li>Editor role can deploy. Let your client push their own finished drafts without giving them admin access.</li>
<li>Unlimited. No monthly cap, no upsell prompts blocking your work.</li>
</ul>
<h4>Headline features</h4>
<ul>
<li>Selective Push and Pull between any two WordPress environments.</li>
<li>AI-powered alt text for images missing it. Bring your own Anthropic, OpenAI, or Google Gemini key via the WordPress AI Connector. Existing alt text is never overwritten.</li>
<li>One-click backup and restore before every overwrite.</li>
</ul>
<h4>What comes with a deployment</h4>
When you push a post, Migro brings everything attached to it:
<ul>
<li>Post content, excerpt, slug, status, dates, notes and ping settings</li>
<li>All post meta (custom fields)</li>
<li>Categories and tags, with hierarchies preserved</li>
<li>Featured images, with smart MD5 deduplication so identical files aren’t re-uploaded</li>
<li>Embedded inline images, PDFs, videos, and other attached media</li>
<li>Image alt text, in both the Media Library and inside post content (kept in sync)</li>
<li>Author attribution (falls back to the deploying admin if the source author doesn’t exist on the destination)</li>
</ul>
<h4>Using a page builder?</h4>
Page builders like Elementor, Divi, Beaver Builder, Bricks, Oxygen, Breakdance, Droip, and WPBakery store layouts as serialized data with hardcoded URLs, which doesn’t survive a staging-to-production move without specialized handling. The free version detects page builder content in your posts and warns you before deployment, so you don’t accidentally break a destination layout. Safe page builder migration (serialized data rewriting and CSS regeneration) is part of Migro Pro.
<h4>Built for real production workflows</h4>
<ul>
<li>Two conflict modes. Overwrite (update in place, same post ID and URL) or Skip (don’t touch existing content).</li>
<li>Pre-deployment backups stored locally, retained for 30 days, restorable in one click.</li>
<li>Migration logs with full status, error messages, and configurable retention.</li>
<li>Direct database connection for reliable transfers, plus WordPress REST API authentication via Application Passwords.</li>
<li>Encrypted credentials at rest. Database passwords are encrypted before they’re saved to the options table.</li>
<li>Works with local development environments including Local by WP Engine, with custom sockets, configurable timeouts, and SSL verification toggles.</li>
<li>Available in English, Brazilian Portuguese (pt_BR), and Spanish (es_ES).</li>
</ul>
<h4>How it compares to site-migration tools</h4>
Full-site migrators are built for moving hosts: one-shot, all-or-nothing, clone everything. Migro is built for ongoing editorial deployment: pick the post, click Push, leave the rest alone.
Specifically, Migro gives you:
<ul>
<li>Single-post granularity instead of whole-site cloning</li>
<li>Bidirectional Push and Pull instead of one-way export/import</li>
<li>Sync-key tracking so re-deploying the same post updates in place instead of duplicating</li>
<li>Automatic backup before every overwrite, with one-click restore</li>
<li>No monthly cap on deployments</li>
</ul>
<h4>How it works</h4>
<ol>
<li>Install Migro on both your staging and production sites</li>
<li>Run the setup wizard to connect the two</li>
<li>Pick the posts to deploy and click Push (or Pull)</li>
<li>Review the per-item operation summary, and restore from backup if anything looks wrong</li>
</ol>
<h4>Need more?</h4>
Migro Pro adds Custom Post Types, ACF, Yoast SEO, WooCommerce, scheduled migrations, WP-CLI, full page builder migration, the Quick Migrate sidebar in Gutenberg, and AI-generated SEO metadata. The free version is fully functional on its own. No usage caps, no feature locks, no nag screens.

Migro Content Migrator

You changed one post. Why clone the whole site? Migro deploys individual posts and pages between staging and production.

Tyler Shuster

This is a plugin to manage deployment of WordPress sites to one or multiple servers, whether development, staging or production. Add, remove, push to, or pull from environments under Tools -> Deploy.
Requires: 
rsync 
If using ssh and not the command line, must use key-based authentication
Add the following constants to your wp-config.php or add them via the admin interface.
(ENV can be any name of your choosing for your remote environment)
<pre><code>DEPLOY_[ENV]_DB_HOST
DEPLOY_[ENV]_DB_USER
DEPLOY_[ENV]_DB_NAME
DEPLOY_[ENV]_DB_PORT
DEPLOY_[ENV]_DB_PASSWORD
</code></pre>
* Database dsn for the environment 
* Mandatory: Yes except for port (default 3306)
<pre><code>DEPLOY_[ENV]_SSH_DB_HOST
DEPLOY_[ENV]_SSH_DB_USER
DEPLOY_[ENV]_SSH_DB_PATH
DEPLOY_[ENV]_SSH_DB_PORT
</code></pre>
* If you need to connect to the destination database through SSH (you probably do) 
* Mandatory: No, port defaults to 22
<pre><code>DEPLOY_[ENV]_SSH_HOST
DEPLOY_[ENV]_SSH_USER
DEPLOY_[ENV]_SSH_PORT
</code></pre>
* SSH host to sync with Rsync 
* Mandatory: No, port defaults to 22
<pre><code>DEPLOY_[ENV]_PATH
</code></pre>
* Server path for the environment (used to reconfigure the WordPress database) 
* Mandatory: Yes
<pre><code>DEPLOY_[ENV]_URL
</code></pre>
* Url of the WordPress install for this environment (used to reconfigure the WordPress database) 
* Mandatory: Yes
<pre><code>DEPLOY_[ENV]_EXCLUDES
</code></pre>
* Add files to exclude from rsync. List must be separated buy semicolons. 
* Mandatory: No

WP Deploy Flow

This adds functionality that allows developers to pull or push their entire site or only the files from a variety of remote environments.

Migro Content Migrator vs WP Deploy Flow