All-in-One WP Migration: How It Works and the Import Limit That Blocks You

All-in-One WP Migration packages an entire WordPress site into a single archive file, database included, and restores it elsewhere with the URLs rewritten automatically, which is the part that makes it worth using.

It is genuinely good software and the most common reason people search for it is that the import failed. The free version caps how large a file it will restore, and that cap is well below the size of most real sites with a media library.

So this covers how the tool works, why the limit exists and where it bites, and the routes around it including the ones that do not involve buying anything.

Table of contents

• What the archive actually contains
• Doing the migration
• The import limit, and why it exists
• Getting under the limit without paying
• Where the destination matters more than the tool
• How this fits the rest of the stack
• FAQ

What the archive actually contains

The export produces one file with a .wpress extension, and it is not a zip. It is a custom container holding four things:

• The database, as a SQL dump of every table with your configured prefix.
• The uploads directory, meaning your entire media library.
• Themes and plugins, including inactive ones unless you exclude them.
• A manifest describing the site URL, the WordPress version and the table prefix.

The manifest is the interesting part, because it is what makes the import work rather than producing a site full of broken links.

WordPress stores absolute URLs throughout the database, and many of them live inside PHP serialised strings where the string length is recorded alongside the content. A naive find-and-replace changes the text and not the recorded length, which corrupts the value and breaks whatever depended on it. That is the classic symptom of a hand-rolled migration: widgets vanish, theme options reset, some plugin settings silently revert.

This plugin handles serialised data correctly during the URL rewrite. That single capability is most of its value.

Doing the migration

The process is short, and the order matters more than it appears.

1. Install the plugin on both the source and destination sites.
2. On the source, open the export screen. Before exporting, use the advanced options to exclude anything you do not need, because size is the constraint everything else follows from.
3. Export to file and download the archive.
4. On the destination, install WordPress fresh, install the plugin, and go to the import screen.
5. Upload the archive. The importer warns that it will overwrite the destination database entirely, which is exactly what it does.
6. After the import, log in with the source site’s credentials, because the destination’s user table has been replaced.
7. Go to Settings, then Permalinks, and save without changing anything. This regenerates the rewrite rules and fixes the 404-on-every-page-but-the-homepage symptom.
8. Check the media library, the contact forms and anything with a licence key, since those frequently need reactivating against the new domain.

That seventh step catches out a lot of people. The site appears completely broken, the homepage works, and the cause is stale rewrite rules that one page save fixes.

The import limit, and why it exists

The free version restores archives only up to a modest size ceiling. Beyond that the import is refused, and this is a deliberate product boundary rather than a technical one, with an extension sold to raise it.

Worth being clear about the mechanics: your hosting environment has its own separate limits, and they can block you before the plugin’s does.

# The three PHP settings that matter for an upload of this kind.
upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
memory_limit = 256M

If you have server access, raising these in php.ini and restarting PHP is the first thing to try, because an upload failing at 2MB is a host limit rather than a plugin one. On shared hosting these are frequently adjustable from the control panel, and where they are not, your host can raise them on request.

Even with generous server limits, the plugin’s own restore ceiling stands. That is the boundary the extension exists to remove.

Getting under the limit without paying

The most reliable free route is to make the archive smaller, and the largest component is nearly always the media library.

Export with the media excluded, using the advanced options on the export screen. The archive drops to the database plus themes and plugins, which for most sites is a small fraction of the total and comfortably under any limit.

Then move the uploads directory separately, which is a plain file copy with no database involvement:

# Direct server to server, fastest if you have shell access on both.
rsync -avz --progress \
  user@old-host:/path/to/wp-content/uploads/ \
  user@new-host:/path/to/wp-content/uploads/

# Or via your machine if the hosts cannot reach each other.
rsync -avz user@old-host:/path/to/wp-content/uploads/ ./uploads/
rsync -avz ./uploads/ user@new-host:/path/to/wp-content/uploads/

Afterwards, confirm ownership and permissions match what the web server expects, since a mismatch produces images that exist on disk and 403 in the browser.

Other things worth excluding while you are there: inactive themes and plugins, any cache directory, and the spam comments table if the site is old. It is common to halve an archive with those alone.

The other free route is a straight manual migration, which is a database dump, a file copy, and a careful search-and-replace using a tool that understands serialised data. More steps, no size ceiling at all, and worth knowing how to do because it works when every plugin route has failed.

Where the destination matters more than the tool

A migration exposes whatever the new host is going to be awkward about, and the awkwardness is usually the same short list: PHP version mismatches, missing extensions, upload limits, and no straightforward way to look at the database when something has gone wrong.

That last one is the painful part of a failed migration. The site is white, the logs are terse, and the question you need answered is what a specific row in the options table contains, which traditionally means finding phpMyAdmin credentials somebody set up two years ago.

RunxBuild’s managed WordPress includes a file manager and a database browser directly in the dashboard, so browsing files and reading, editing or exporting database rows during a migration is part of the product rather than a separate credential hunt. The WordPress database docs cover the browser, and the WordPress ladder starts at $3 a month.

None of which replaces the migration tool. It replaces the part of the migration where you cannot see what went wrong.

How this fits the rest of the stack

A migration is also the natural moment to check whether the destination plan actually fits the site, because carrying a slow setup to a new host reproduces the slowness with a new invoice attached. The RunxBuild hosting calculator shows the WordPress ladder alongside storage and bandwidth so the sizing decision happens before the move rather than after the first busy week.

Useful related references:

• Joomla to WordPress Migration: What Transfers, What Does Not, and the Redirects
• Cloud Migration Solutions: The Six Strategies and When to Use Each
• Cloud Migration Challenges: The Nine That Always Come Up
• Services on RunxBuild

FAQ

What is a wpress file?

It is the custom archive format All-in-One WP Migration produces, containing the database dump, the uploads directory, themes, plugins and a manifest. It is not a zip archive and cannot be opened with standard extraction tools; it is designed to be restored by the plugin, which rewrites URLs correctly during import.

How do I get around the import size limit?

The reliable free route is to shrink the archive: export with media excluded using the advanced options, then copy the uploads directory separately with rsync or FTP. Also check your host’s PHP upload limits, since those can block you before the plugin’s ceiling does.

Why is my site showing 404 on every page after importing?

Stale rewrite rules. Go to Settings, then Permalinks, and click save without changing anything. That regenerates the rules for the new environment. It is the single most common post-import issue and takes one click to fix.

Does the import overwrite the destination site?

Yes, completely. The importer replaces the destination database and files entirely, including the user table, which is why you log in afterwards with the source site’s credentials. Never import onto a site with content you want to keep.

Can I migrate without a plugin?

Yes. Export the database with mysqldump, copy wp-content with rsync or FTP, import the database on the destination, and update wp-config.php. The critical step is the URL search-and-replace, which must use a tool that handles PHP serialised data correctly, or theme options and widget settings will break.