Frequently Asked Questions

Custom post types (CPT) don’t appear in “Post types to migrate”

The list is fetched live from your source site once its credentials are saved and “Test connection” succeeds. If a CPT is missing, it was almost certainly registered without REST API support (show_in_rest) by the plugin or theme that declares it — WPMove can only see and migrate post types exposed through the REST API of the site it reads (the source for a direct or pull migration, the target for a push). Fix: install the free WPMove Migration Connector on that site (2.1.9 or later, or Premium 2.6.20+) and tick the type in its “REST API visibility” section — per type, nothing else changes, with one caveat shown there: an exposed type becomes readable through that site’s public REST API. Then click “Test connection” again so the list refreshes. If no plugin can be installed on that site, the must-use plugin from the next entry works the same way with register_post_type_args.

A custom post type’s categories or custom taxonomy never migrate

This is almost always the same cause as the previous entry — the taxonomy itself wasn’t registered with show_in_rest support by the plugin or theme that declared it — but it can happen even when the post type and its other fields migrate fine, since a post type and its taxonomies are registered separately. Two fixes, depending on what’s installed on the affected site: if the WPMove Migration Connector (Lite or Premium) is installed there, open its settings and use the “REST API visibility” section to opt that taxonomy in — nothing else needs to change. If no connector plugin can be installed on that site, ask whoever manages it to add a small must-use plugin that forces show_in_rest for that taxonomy specifically, saved as a .php file directly inside that site’s wp-content/mu-plugins/ folder (create the folder if it doesn’t exist yet — no activation needed):

<?php
/**
 * Plugin Name: Force show_in_rest on a custom taxonomy
 * Description: Exposes a specific taxonomy through the REST API so tools
 *              like WPMove can read its terms. Replace 'your_taxonomy_slug'
 *              with the actual taxonomy name.
 */
add_filter( 'register_taxonomy_args', function ( $args, $taxonomy ) {
	if ( 'your_taxonomy_slug' === $taxonomy ) {
		$args['show_in_rest'] = true;
	}
	return $args;
}, 10, 2 );

Media isn’t migrating even though “Import media” is checked

On the Free plan, media is never migrated regardless of that checkbox — it’s a plan limitation, not a bug. Media migration is available on Starter, Pro and Unlimited plans, each with its own yearly media quota (see the Pricing page).

“Please wait N days before your next migration”

This is the Free plan’s cooldown between migrations. Paid plans (Starter, Pro, Unlimited) have no cooldown and allow unlimited migrations.

A migration seems stuck — no progress for a while

WPMove monitors migrations in the background; if one stops reporting progress for more than ~15 minutes, you’ll automatically receive an email about it (at most one per hour). From the Migrate page, use Restart to resume from where it left off, or Reset to clear it and start over. Migrations run via a queue, so brief pauses of a few minutes between pages are normal and not a sign of being stuck.

Elementor layouts, ACF fields or SEO metadata are missing after migration

WordPress’ REST API only carries the custom fields a plugin has explicitly opened to it — most plugins do not. Elementor layouts, ACF fields and some SEO metadata are therefore left behind, and nothing warns you. To carry them, install the free WPMove Migration Connector on both sites — the one you migrate from and the one you migrate to — then run the migration again. WPMove will transfer every custom field, including the images an ACF field points to. The plugin is free, needs no account, and only answers requests authenticated with the application password you already use here.

Sync mode migrated everything — or migrated nothing

Sync mode carries only what changed since your last successful migration between the same two sites, so a run that finds nothing to do is usually correct — nothing changed. It deliberately falls back to a full migration in four cases, and the migration log always states which one applies: there is no previous successful migration towards this target; the previous run stopped at your plan’s post limit, so older content is still waiting; you added a content type the previous run did not cover, whose existing content is older than the sync point and would otherwise be skipped for ever; or your earlier migrations predate sync mode and never recorded which content types they covered, so the first sync run cannot tell what a partial one would leave behind. That last case is the one most people meet: one full migration records the scope, and every sync after it is incremental. One limit worth knowing: content deleted on the source is never removed from the target. Sync mode adds and updates — it is not a mirror.

Comments are missing after a migration — or arrived awaiting moderation

Comments only travel when “Import comments” is ticked; it is off by default. When it is on, comments awaiting moderation come across too — and stay awaiting moderation, so nothing appears on your site without your say-so. Spam and trash are deliberately left behind: migrating is a good moment to be rid of them. Threads are rebuilt, with one exception worth knowing — a reply whose parent was not migrated is attached at top level rather than pointed at the wrong comment, and the log says so. Commenters always arrive as guests, identified by name and email: an account id from one site means nothing on another. Re-running a migration never duplicates comments already on the destination.

The post author received one email per migrated comment

That email comes from the target site, not from WPMove: WordPress notifies a post’s author whenever an approved comment is created, and a comment migrated over the core REST API is created exactly like a new one — moderation rules, duplicate check and notification included. The fix is to install the free WPMove Migration Connector (2.1.7 or later) on the target: WPMove then writes migrated comments through it, directly into the database, with none of those automatisms — no email, no comment sent to moderation, no reply rejected as a “duplicate”. The migration log tells you which path is in use. Without the plugin on the target, untick “Email me whenever anyone posts a comment” in Settings → Discussion there for the duration of the migration.

What does installing the free Connector on the target change?

Three things, all silent otherwise. Custom fields: the core REST API only carries the fields a plugin has opened to it, so Elementor layouts, ACF fields and SEO meta stay behind unless the Connector is installed on both sites (it also carries page templates). Comments: written directly into the database instead of through the core route — no moderation, no duplicate rejection, no notification email to post authors (see above). Reachability: with the Premium version, a site on localhost or behind a firewall can drive the migration itself. One requirement: the Application Password used on that site must belong to an administrator — the Connector writes past WordPress’ usual gates and only trusts an admin to do so. The plugin is free, needs no account, and is the same one used for file export/import.