Bulk migration stalled
If the bulk migration progress bar stops moving and the migration does not appear to be continuing, work through the checks below. The most common causes are a blocked loopback request, a disabled WP-Cron, or a dropped storage connection.
How the bulk migration runs#
Understanding the background process helps diagnose a stall. When you click Start Migration, WP Media Cloud fires a non-blocking loopback POST request to your own server’s admin-ajax endpoint. That loopback request processes a batch of files, saves its progress, and fires another loopback to continue. Each batch runs for up to 20 seconds or until 90% of PHP memory is reached, whichever comes first.
A WP-Cron healthcheck runs every 5 minutes as a fallback in case the loopback chain breaks. If both the loopback and WP-Cron are blocked, the migration stalls.
Check 1: Loopback requests#
Go to Media Cloud > Health and run the health check. Look at the loopback request result. A failing loopback check is the most common reason a migration stalls immediately or stops early.
Common causes of loopback failure:
- The server cannot make HTTP requests to itself — some hosts block this
- An SSL certificate issue on the site prevents the loopback from completing
- A security plugin is blocking requests to
admin-ajax.php - Basic authentication is enabled on the site (common on staging environments) and the loopback request cannot authenticate
Contact your host if the loopback is failing and you cannot identify the cause. Ask them to confirm that your server can make HTTP requests to itself on port 80 and 443.
Check 2: WP-Cron#
Go to Media Cloud > Health and check the WP-Cron status. If WP-Cron is disabled via define('DISABLE_WP_CRON', true) in wp-config.php, the 5-minute healthcheck fallback does not run. If the loopback also fails, the migration has no mechanism to continue.
If WP-Cron is disabled and you are running cron via a system cron job, confirm the system cron job is executing wp-cron.php at least every 5 minutes. If you do not have a system cron job configured, re-enable WP-Cron during the migration by removing or commenting out the DISABLE_WP_CRON constant.
Check 3: Storage connection#
Go to Media Cloud > Settings > Storage and run the connection test. If the test fails, the migration is stalling because WP Media Cloud cannot reach your storage bucket to upload files. Fix the connection issue and then click Resume Migration on the Dashboard.
A connection can drop mid-migration if credentials expire, API rate limits are hit, or the storage provider has a temporary outage. Resuming after the issue is resolved continues from where the migration left off without re-processing completed files.
Check 4: PHP memory limit#
WP Media Cloud stops a batch when PHP reaches 90% of the configured memory limit. If the memory limit is very low (under 128MB), individual batches may stop after processing very few files and have difficulty re-dispatching. Each re-dispatch requires a fresh request, and on low-memory hosting this can cause the migration to crawl or appear stalled.
Check your PHP memory limit in Tools > Site Health > Info > Server. Increasing it to 256MB or higher in wp-config.php or php.ini will allow larger batches and faster migration:
define( 'WP_MEMORY_LIMIT', '256M' );Check 5: Very large files#
Individual files that are very large — video files, high-resolution RAW images, or large PDFs — take longer to upload to cloud storage and may approach the 20-second per-batch time limit on their own. The migration does not skip these files, but it may appear stalled while a single large file uploads. Check whether progress resumes after a minute or two before assuming a stall.
Resuming after fixing a stall#
WP Media Cloud saves its cursor position after every batch. If a stall occurs and you resolve the underlying issue, go to Media Cloud > Dashboard and click Resume Migration. The migration continues from the last successfully processed file. No files are duplicated or re-uploaded.
Using WP-CLI as an alternative#
If background processing is unreliable on your host, you can run the bulk offload directly from the command line using WP-CLI, which bypasses loopback requests and WP-Cron entirely:
wp wpmc offloadThis runs the offload synchronously in the terminal. It respects your PHP memory and time limits but does not rely on any background processing mechanism. Run it in a screen or tmux session if you expect it to take a long time.