How to Use All-in-One WP Migration in WordPress: Complete Technical Guide
All-in-One WP Migration is a WordPress plugin that serializes your entire site — database, media uploads, themes, plugins, and core configuration — into a single portable .wpress archive, which can then be imported into any WordPress installation with zero manual database manipulation. It is the fastest path to a complete site migration or point-in-time backup without touching phpMyAdmin, SSH, or raw SQL dumps.
This guide goes beyond the basic click-through. It covers the full migration workflow, the critical technical constraints that cause most failed imports, PHP configuration tuning, URL serialization behavior, and post-migration validation steps that are routinely skipped and later cause production incidents.
What the Plugin Actually Does Under the Hood
Before touching the dashboard, understanding the plugin's internal mechanics prevents surprises during large migrations.
When you trigger an export, All-in-One WP Migration performs the following sequence:
- Dumps the WordPress MySQL database to a flat SQL file inside a temporary working directory.
- Serializes all PHP object data in the database (options, widget configurations, post meta) and rewrites absolute URLs to a placeholder token so they can be rewritten on import.
- Packages
wp-content/uploads, active theme files, and plugin directories alongside the SQL dump. - Wraps everything into a
.wpressarchive, which is a custom format — not a standard ZIP or TAR — with its own manifest header.
On import, the process reverses: the archive is unpacked, the SQL is replayed against the new database, and the URL placeholder tokens are replaced with the new site URL. This URL rewriting step is why the plugin handles domain changes gracefully without requiring a separate wp-cli search-replace pass — though you should still verify it, as discussed in the post-migration section.
Step 1: Install the Plugin on the Source Site
Log in to your existing WordPress dashboard and navigate to Plugins > Add New. Search for All-in-One WP Migration, install it, and activate it. The free version is sufficient for sites under the upload size threshold of your server (typically 128 MB to 512 MB depending on the host's PHP configuration).
No configuration is required after activation. The plugin registers itself in the left sidebar immediately.
Step 2: Export Your Website
Navigate to All-in-One WP Migration > Export in the dashboard sidebar.
Click Export To and select File. The plugin will begin packaging your site. For a typical site under 500 MB, this takes 30 seconds to 3 minutes. For multi-gigabyte sites with large media libraries, plan for 10 to 20 minutes.
What gets included in the export:
- Full MySQL database dump (all tables with the configured prefix)
wp-content/uploads directory
Active and inactive themes in wp-content/themeswp-content/pluginswp-config.php is intentionally excluded for security reasons — the destination site's own wp-config.php is preserved on import
What is excluded by default:
Spam comments
Post revisions
Unused themes and deactivated plugins (configurable via the Advanced Options toggle)
Error logs and cache directories
The Advanced Options section lets you exclude specific tables, file paths, or post types. Use this to strip transient caches or large log tables before export, which meaningfully reduces archive size.
Once packaging completes, click Download to save the .wpress file locally. Store it somewhere reliable — this file is your complete site backup.
Step 3: Prepare the Destination Environment
If you are migrating to a new server, you need a clean WordPress installation at the destination before importing. Most managed hosting environments provide one-click WordPress installers. If you are working on a VPS Hosting environment, you can install WordPress manually or use a control panel stack.
The destination WordPress installation does not need to match the source in terms of theme, plugins, or content — the import will overwrite everything. However, the following must be in place:
WordPress core is installed and accessible via its admin dashboard
The database user has CREATE, DROP, INSERT, UPDATE, DELETE, and ALTER privileges on the target database
PHP version is compatible with your plugins (check your source site's PHP version under Tools > Site Health)
The wp-content directory is writable by the web server process
Critical: The destination site's domain or subdomain does not need to match the source. The plugin rewrites URLs during import. However, if you are migrating to the exact same domain (e.g., moving between servers), DNS propagation timing matters — do not update DNS until the import is verified.
Step 4: Install the Plugin on the Destination Site
Repeat the installation process on the new WordPress instance: Plugins > Add New, search for All-in-One WP Migration, install, and activate.
This step is frequently overlooked when people set up a fresh WordPress install and assume the plugin will be present. It will not be — the import process requires the plugin to already be active on the destination.
Step 5: Increase the Upload Size Limit Before Importing
This is the single most common point of failure. The free version of All-in-One WP Migration respects the server's PHP upload limit. If your .wpress file exceeds that limit, the import will silently fail or throw a vague error.
Check your current limit by navigating to All-in-One WP Migration > Import. The plugin displays the maximum upload size directly on that screen.
To increase it, use one of the following methods depending on your server access level:
Method 1: Edit php.ini directly (recommended for VPS and dedicated servers)
upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
Restart PHP-FPM or Apache after saving:
sudo systemctl restart php8.1-fpm
# or for Apache with mod_php:
sudo systemctl restart apache2
Method 2: Override via .htaccess (shared hosting environments)
php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value memory_limit 512M
php_value max_execution_time 300
Method 3: Override via wp-config.php
@ini_set('upload_max_filesize', '512M');
@ini_set('post_max_size', '512M');
@ini_set('memory_limit', '512M');
After applying changes, refresh the Import page in the plugin to confirm the new limit is reflected. If you are on a Shared Web Hosting plan, contact your host to raise PHP limits at the server level, as .htaccess overrides may be restricted.
Alternative for very large sites: Use the free plugin combined with the official "Basic" extension, or upload the .wpress file directly to wp-content/ai1wm-backups/ via FTP/SFTP and then select it from the Import screen. This bypasses the HTTP upload size restriction entirely.
Step 6: Import the Archive
On the destination site, navigate to All-in-One WP Migration > Import.
Click Import From > File and select your .wpress archive. The plugin will upload the file and then begin the restoration process. A progress bar tracks the operation.
What happens during import:
The .wpress archive is unpacked into a temporary directory under wp-contentwp-content are overwritten with the archived versionswp-config.php)When the import completes, you will see a confirmation dialog. Click Proceed (or Restore depending on plugin version) to confirm the database replacement. This action is irreversible without a separate backup of the destination database.
You will be logged out immediately after the import completes. This is expected behavior — the database now contains the user accounts from the source site. Log in using the credentials from your source site.
Step 7: Flush Permalinks
After logging back in, navigate to Settings > Permalinks. Do not change any settings. Simply scroll to the bottom and click Save Changes.
This forces WordPress to regenerate the .htaccess rewrite rules for the new environment. Skipping this step results in all post and page URLs returning 404 errors even though the content exists in the database.
If you are running Nginx instead of Apache, there is no .htaccess file. You must ensure your Nginx server block includes the standard WordPress try_files directive:
location / {
try_files $uri $uri/ /index.php?$args;
}Step 8: Post-Migration Validation Checklist
A migration is not complete until every item on this list is verified. Skipping validation is how broken sites reach production.
URL and domain integrity:
- Visit Settings > General and confirm both WordPress Address and Site Address reflect the correct destination URL
- Run a search-replace check: install WP-CLI on the server and run
wp search-replace 'olddomain.com' 'newdomain.com' --dry-runto catch any URLs the plugin missed in serialized data - Check for mixed content warnings in browser developer tools if migrating from HTTP to HTTPS
Functional testing:
- Test all navigation menus and internal links
- Submit at least one contact form and verify delivery
- Test WooCommerce checkout flow if applicable
- Verify media attachments load correctly (broken images often indicate a missed URL rewrite in the
wp_poststable)
Security and configuration:
- Confirm your SSL Certificates are active and HTTPS is enforced on the destination domain
- Review
wp-config.phpon the destination — database credentials,WP_DEBUGstatus, and salts should reflect the new environment, not the source - Regenerate WordPress security keys via Settings > General or by replacing the salt constants in
wp-config.phpusing the WordPress secret key generator
Caching:
- Clear all caching layers: object cache (Redis/Memcached), page cache plugins (WP Rocket, W3 Total Cache), and any CDN caches
- Deactivate and reactivate caching plugins to force them to detect the new environment paths
Comparison: All-in-One WP Migration vs. Alternative Migration Methods
| Method | Technical Skill Required | Handles Large Sites | URL Rewriting | Cost | Best For |
|---|---|---|---|---|---|
| — | — | — | — | — | — |
| All-in-One WP Migration (free) | Low | Limited by upload cap | Automatic | Free | Small to medium sites |
| All-in-One WP Migration (premium) | Low | Yes (no size limit) | Automatic | Paid | Any site size |
| WP-CLI + rsync + mysqldump | High | Yes | Manual (`search-replace`) | Free | Developers, large sites |
| Duplicator Pro | Medium | Yes | Semi-automatic | Paid | Agencies, multisite |
| Manual (phpMyAdmin + FTP) | High | Yes | Manual | Free | Full control scenarios |
| cPanel/Plesk backup restore | Medium | Yes | None (same domain) | Included with host | Same-host migrations |
Migrating to a VPS or Dedicated Server
If you are moving from shared hosting to a VPS Hosting or Dedicated Servers environment, the All-in-One WP Migration workflow is identical, but the destination server setup requires additional attention:
- Install a LAMP or LEMP stack (Apache/Nginx, MySQL/MariaDB, PHP)
- Configure a virtual host pointing to the WordPress document root
- Create a dedicated MySQL database and user with appropriate privileges
- Install WordPress core before running the plugin import
- Configure PHP-FPM pool settings to match or exceed the source site's resource requirements
For teams that prefer a managed control panel interface, a VPS with cPanel significantly reduces the server configuration overhead — cPanel provides a one-click WordPress installer, PHP version switcher, and file manager that simplify the pre-import setup.
Common Errors and How to Fix Them
"Import failed: could not extract archive"
This typically means the .wpress file is corrupted, the upload was interrupted, or disk space on the destination is insufficient. Verify the file size matches the original, check available disk space with df -h, and re-upload via SFTP directly to wp-content/ai1wm-backups/.
"Maximum execution time exceeded"
The PHP max_execution_time directive is too low for the size of the import. Increase it to 300 or 600 seconds in php.ini or .htaccess as shown above.
"The uploaded file exceeds the upload_max_filesize directive"
The upload size limit has not been raised, or the change was not applied to the correct PHP configuration file. Run php -i | grep upload_max_filesize from the command line to confirm which php.ini is active.
php -i | grep upload_max_filesize
php -i | grep "Loaded Configuration File"White screen of death after import
Enable WP_DEBUG temporarily in wp-config.php to surface the actual PHP error:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Then check /wp-content/debug.log for the specific error. Common causes are a plugin incompatible with the destination PHP version or a memory limit exhaustion.
Broken images after migration
Run a targeted database search-replace for the old domain in the wp_posts and wp_postmeta tables. Using WP-CLI:
wp search-replace 'https://olddomain.com' 'https://newdomain.com' wp_posts wp_postmeta --precise --report-changed-onlyTechnical Decision Matrix: When to Use All-in-One WP Migration
| Scenario | Recommended Approach |
|---|---|
| — | — |
| Site under 512 MB, moving to new host | Free version, direct file upload |
| Site over 512 MB | Upload `.wpress` via SFTP to `ai1wm-backups/` or use premium |
| Moving from HTTP to HTTPS | Run WP-CLI `search-replace` after import to catch serialized URLs |
| Migrating multisite network | Use premium version; free version does not support multisite |
| Automated recurring backups | Use a dedicated backup plugin (UpdraftPlus, BackWPup) instead |
| Moving to a different PHP version | Test plugin compatibility in staging before production import |
| Domain change involved | Verify URL rewrite in Settings > General post-import |
Practical Key Takeaways
- Always upload the
.wpressfile via SFTP directly towp-content/ai1wm-backups/for sites over 200 MB — this avoids every HTTP upload size restriction. - Raise
upload_max_filesize,post_max_size,memory_limit, andmax_execution_timeon the destination before starting the import, not after encountering an error. - The plugin excludes
wp-config.phpfrom the archive — your destination database credentials are preserved, but verifyWP_DEBUG,WP_SITEURL, and security salts manually after import. - Always flush permalinks immediately after import. On Nginx, verify the
try_filesdirective is present in the server block. - Run
wp search-replace --dry-runafter any migration involving a domain change to catch serialized URL remnants the plugin may have missed. - Confirm SSL is active on the destination before going live — a SSL certificate mismatch after migration is a common cause of browser security warnings that erode user trust.
- For production migrations, always test in a staging environment first, especially when changing PHP versions or moving between significantly different server stacks.
Frequently Asked Questions
Does All-in-One WP Migration work for moving WordPress to a different domain?
Yes. The plugin automatically rewrites the source domain to the destination domain during import using a token-substitution process on the SQL dump. After import, verify the rewrite succeeded by checking Settings > General and running a WP-CLI search-replace --dry-run to catch any URLs embedded in serialized PHP data that the plugin may have missed.
What is the maximum file size supported by the free version?
The free version has no hard-coded size limit in the plugin itself — the constraint comes entirely from the server's PHP upload_max_filesize and post_max_size directives. On many shared hosts this defaults to 128 MB. You can bypass this restriction entirely by uploading the .wpress file via SFTP to wp-content/ai1wm-backups/ and selecting it from the Import screen, which skips the HTTP upload mechanism.
Will the migration overwrite the destination site's database completely?
Yes. The import drops all existing tables in the destination database and replaces them with the tables from the source site. Back up the destination database before importing if it contains any data you need to preserve.
Can I use All-in-One WP Migration for WordPress Multisite?
The free version does not support Multisite network migrations. The premium "Multisite Extension" is required for exporting and importing a full Multisite network. Individual subsites within a network can sometimes be migrated as standalone sites using the free version, but this requires manual cleanup of network-specific database entries.
Why am I logged out immediately after the import finishes?
This is correct behavior. The import replaces the entire database, including the wp_users table, with the data from the source site. Your destination site's admin account no longer exists — the source site's user accounts are now active. Log in using the username and password from the original source site.
