How to Make All-in-One WordPress Migration Upload more than 128 MB

How to Increase the All-in-One WordPress Migration Upload Limit Beyond 128 MB

WordPress site migrations frequently fail at the final import phase due to restrictive server configurations. The All-in-One WP Migration plugin enforces a default upload restriction of 128 MB, a threshold that modern WordPress deployments with extensive media libraries, large enterprise databases, and numerous commercial plugins easily exceed. When a system administrator or webmaster attempts to import an archive (.wpress) file larger than 128 MB without adjusting the underlying PHP and web server directives, the operation terminates prematurely, resulting in HTTP 500 errors, broken database imports, or silent execution failures.

Executing large file uploads requires a synchronized configuration across multiple layers of the application stack: the web server (Apache or Nginx), the PHP processor (PHP-FPM or CGI), and the WordPress application layer itself. Neglecting any single layer will cause the upload pipeline to reject the payload. This technical guide outlines the exact root causes behind these limitations, provides step-by-step remediation procedures utilizing configuration files and the command line, and details advanced production hardening techniques to ensure seamless execution of large WordPress migrations.

Root Cause Analysis & Architecture

To understand why the 128 MB upload barrier exists, one must examine the PHP execution lifecycle and the request handling architecture of modern web servers. The default values are defined in the master php.ini configuration file or enforced by hosting control panels to prevent resource exhaustion, denial-of-service (DoS) conditions, and out-of-memory errors on shared infrastructure.

When an HTTP POST request is initiated to upload a large archive file via WordPress admin-ajax or the REST API, several configuration directives dictate whether the request succeeds:

• upload_max_filesize: Defines the absolute maximum file size permitted for a single uploaded file. The default in many legacy PHP installations is set conservatively to 2 MB or 128 MB.
• post_max_size: Sets the maximum amount of data accepted via POST requests. This value must always be equal to or greater than upload_max_filesize because an upload request includes headers and other form data alongside the binary file.
• memory_limit: Defines the maximum amount of RAM a single PHP script is allowed to consume. During uncompression and database restoration phases, unpacking a 500 MB .wpress file requires substantial memory overhead to parse chunks into the MySQL database.
• max_execution_time and max_input_time: Dictate the maximum time in seconds a script is allowed to run before the server terminates it. Large migrations will consistently time out under the default 30-second limit.
• Nginx client_max_body_size: For Nginx-fronted servers, the web server itself acts as a reverse proxy. Even if PHP is configured to accept large files, Nginx will immediately drop requests exceeding its internal body size limit, typically returning a 413 Request Entity Too Large error.

Failing to account for the interplay between these variables results in migration failures that are difficult to diagnose without inspecting raw error logs.

Step-by-Step Implementation & Remediation Guide

Resolving upload bottlenecks requires modifying the configuration across your specific web stack. Below are the definitive methods for Apache, Nginx, PHP-FPM, and the WordPress application layer.

Method 1: Configuring Apache Web Servers via .htaccess

If your WordPress installation runs on an Apache web server with mod_php or a compatible handler, you can override global PHP directives locally using the .htaccess file located in the root directory of your WordPress installation.

1. Access your server via SFTP or Secure Shell (SSH) and navigate to your WordPress document root.
2. Open or create the hidden .htaccess file.
3. Append the following directives to increase the limits to 512 MB (adjust the values to meet your specific archive size requirements):

# BEGIN SiteSuraksha Migration Limits
php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value memory_limit 512M
php_value max_execution_time 600
php_value max_input_time 600
# END SiteSuraksha Migration Limits

Warning: If your server runs PHP-FPM instead of mod_php, inserting php_value directives into an .htaccess file will trigger a 500 Internal Server Error. If this occurs, immediately remove the lines and proceed to the PHP-FPM or global php.ini configuration methods.

Method 2: Updating Global php.ini Configuration

Modifying the master php.ini file is the most reliable method for servers running CGI, FastCGI, or PHP-FPM. The location of the php.ini file varies depending on your operating system and PHP version (e.g., /etc/php/8.2/fpm/php.ini on Ubuntu or /etc/opt/remi/php82/php.ini on RHEL-based systems).

1. Locate your active php.ini file by executing an SSH command or checking your phpinfo() output:

php -i | grep "Loaded Configuration File"

2. Open the file using a text editor such as nano or vim with administrative privileges:

sudo nano /etc/php/8.2/fpm/php.ini

3. Locate and modify the following parameters to match or exceed your migration file size:

upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 600
max_input_time = 600

4. Save the file and restart your PHP-FPM service to apply the changes:

sudo systemctl restart php8.2-fpm

Method 3: Configuring Nginx and PHP-FPM Pools

High-performance WordPress hosting stacks often pair Nginx with PHP-FPM. In this architecture, both the web server and the PHP pool configuration must be adjusted.

First, update your Nginx server block configuration file (typically located in /etc/nginx/sites-available/your-domain.com or /etc/nginx/nginx.conf) to allow large bodies:

server {
    listen 443 ssl;
    server_name example.com;
    client_max_body_size 512M;
    
    # Remaining server block directives...
}

Test the Nginx configuration for syntax errors and reload the service:

sudo nginx -t
sudo systemctl reload nginx

Next, configure your PHP-FPM pool configuration file (e.g., /etc/php/8.2/fpm/pool.d/www.conf) to override default resource limits:

php_value[upload_max_filesize] = 512M
php_value[post_max_size] = 512M
php_value[memory_limit] = 512M
php_value[max_execution_time] = 600
php_value[max_input_time] = 600

Restart the PHP-FPM service to finalize the changes.

Method 4: Utilizing the wp-config.php Constant

The All-in-One WP Migration plugin provides a native PHP constant that explicitly overrides its internal upload validation checks. You can define this constant inside your WordPress wp-config.php file.

1. Access your root directory and open wp-config.php.
2. Add the following definition directly above the comment line that states /* That's all, stop editing! Happy publishing. */:

define('AI1WM_MAX_FILE_SIZE', 536870912); // Sets plugin limit to 512 MB in bytes

Calculation Note: The value is measured in bytes. To calculate your desired limit, multiply your target size in megabytes by 1,048,576 (e.g., 512 MB × 1,048,576 = 536870912).

Method 5: Bypassing the Web GUI via WP-CLI

For exceptionally large migrations exceeding 1 GB, relying on browser-based uploads is inherently risky due to network instability, browser timeouts, and proxy intermediary limitations. The most robust enterprise approach is to bypass the browser upload entirely by utilizing WP-CLI and the command-line extension for the migration plugin.

1. Upload your .wpress backup file directly to your server using SFTP or SCP into the plugin’s backup directory (wp-content/plugins/all-in-one-wp-migration/storage/).
2. Access your server via SSH and navigate to your WordPress installation path:

cd /var/www/html

3. Execute the WP-CLI import command, substituting your specific backup filename:

wp ai1wm restore backup-file-name.wpress

This method completely bypasses all HTTP upload limits, browser memory constraints, and web server body size restrictions, ensuring a 100% reliable restoration.

Production Hardening & Edge Cases

Implementing these modifications in a production environment requires careful attention to security boundaries, caching layers, and server performance trade-offs. Leaving high execution limits and massive memory allocations permanently enabled across an entire production server introduces security risks, opening your application up to resource starvation attacks where malicious actors flood endpoints with heavy POST requests.

Caching and Reverse Proxy Caveats: If your infrastructure utilizes Cloudflare, AWS CloudFront, or an enterprise edge proxy in front of your origin server, these services enforce their own rigid limits on maximum upload request sizes. For example, Cloudflare Free and Pro plans cap unproxied or proxied HTTP body uploads at 100 MB unless enterprise rules or bypass configurations are applied. When migrating large sites behind Cloudflare, temporarily enable “Pause Cloudflare on Site” or configure a Page Rule / Configuration Rule to bypass security checks for the WordPress administrative dashboard during the migration window.

Reverting Limits Post-Migration: Once the All-in-One WP Migration import is complete, it is a security best practice to revert your PHP execution times and memory limits back to secure production baselines (e.g., memory_limit = 256M and max_execution_time = 60), while leaving only the necessary baseline upload_max_filesize if regular user media uploads require it.

Diagnostic Verification & Checklist

Before initiating a large site migration, verify that your server configuration changes have successfully propagated across the system. Relying on assumptions frequently leads to mid-migration failures.

Following this systematic approach ensures that even massive WordPress sites migrate efficiently without running into arbitrary execution hurdles.