Migro – Push Posts & Pages from Staging to Live

Those are site migration tools, built for moving an entire WordPress install from one host to another in a one-shot, all-or-nothing transfer. Migro is a content deployment tool, built for the ongoing workflow of pushing individual posts from staging to production while leaving the rest of the live site alone. Different problem, different product.

Yes. Migro needs to be active on both the source and destination site.

No. Since version 2.7, Migro connects through WordPress using an Application Password, so it works on hosts that block outside database access. If the database is reachable, Migro uses it for speed. Settings shows which connection is in use.

Yes. Push and Pull are both first-class operations. You can pull live content back to staging just as easily as pushing staging drafts to production.

Migro hashes incoming media with MD5. If an identical file already exists in the destination's Media Library, Migro links to the existing attachment instead of uploading a duplicate.

Migro preserves the original slug. The destination URL will match the source unless the permalink structure differs between environments.

Overwrite updates the existing item in place: same post ID, same URL, updated content. Skip leaves any existing destination post untouched. You pick the mode at deployment time.

Every deployment that overwrites existing content creates a local backup first. The Backups page lets you restore the previous version with one click. Backups are retained for 30 days by default.

Migro's AI integration uses the WordPress 7.0 AI Connector. You bring your own API key (Anthropic, OpenAI, or Google Gemini) and pay your provider directly. Migro never charges you for AI usage, never proxies the requests, and never sees your key. Generated alt text is cached locally so re-deploying the same content doesn't re-call the provider. Existing alt text is never overwritten.

Editors can run deployments, and that is the default. For agencies, it lets a client push their own approved drafts without being given admin access. Settings, pairing, and backups stay administrator-only either way. If you do not want that, the Editor Access setting hides Migro from everyone except administrators. The administrator decides who deploys.

No. Migro is unlimited. There's no monthly cap and no nag screen. The Pro version adds features (Custom Post Types, ACF, Yoast, WooCommerce, scheduling, WP-CLI), not volume.

Migro is designed for single-site installations. Multisite is not currently supported.

No. User accounts are not migrated. If a post author doesn't exist on the destination, the post is assigned to the admin who ran the deployment.

Yes. If you give Migro a database password, it is encrypted before being saved, as is the Application Password. Neither is stored or sent in plain text. You can also skip the database entirely: Migro works without it.

Yes. All you need is an administrator account on the remote site and an Application Password from it. Database credentials are optional. Migro also supports custom sockets (for Local by WP Engine and similar) and SSL verification toggles for tricky local environments.

Yes. Dry Run resolves your selection item by item and reports what would change, including a side-by-side diff of the source content against the destination. Nothing is written to the destination during a Dry Run.

No. Migro tracks what has already been synced. Items that are identical on both sides are labelled "In sync" and skipped, so a re-run only moves what actually changed. Use the "Re-migrate everything" toggle if you want to force an overwrite regardless.

Copy the pairing code from one site and paste it on the other. That is all: the sites connect through WordPress, with no database settings. To make large deployments faster, you can also give Migro the database. LocalWP does not show a database password, and where the database lives depends on your operating system. On macOS and Linux, LocalWP serves MySQL over a Unix socket: open the site's Database tab in LocalWP and use the socket path shown there as the database host. On Windows, LocalWP serves MySQL over TCP on a per-site port: open the destination site in LocalWP, go to the Database tab, note the Port (a five-digit number such as 10017), and enter the host as localhost:10017, substituting your own port. If the connection is refused, try 127.0.0.1:10017 instead.

Each item is deployed independently. If one fails, the others continue. The Logs page shows exactly which items succeeded, which were skipped, and which failed with the error message and a retry option.

Yes, but WooCommerce migration requires the Pro version. Variable products and all their variations are fully migrated including pricing, stock, attributes, and images.

The free version detects page builder content (Elementor, Divi, Beaver Builder, Bricks, Oxygen, Breakdance, Droip, WPBakery) and leaves those pages out of the deployment, because page builders store their layouts as serialized data with hardcoded URLs that don't survive a host change without specialized handling. Safe page builder migration, including serialized data rewriting and CSS regeneration, is part of Migro Pro.

Yes. English, Brazilian Portuguese (pt_BR), and Spanish (es_ES) are bundled. The non-English translations started as machine translations and improve with community contributions.

Only if you explicitly opt in. After installation Migro shows a one-time prompt asking whether you want to share anonymous usage data. Nothing is sent unless you choose "Yes". If you decline or ignore the prompt, no data ever leaves your site, and you can change your choice at any time on the Settings page. When enabled, Migro sends anonymous, non-personal information such as the plugin version, WordPress/PHP version, and aggregate deployment counts. It never sends post content, URLs, credentials, or any personally identifiable information.

WordPress 5.6. This is the version that introduced Application Passwords, which Migro uses for REST API authentication.