3.1.15 is live on WordPress.org.

This ship hardens cross-prefix restores when large options rows used to die as invalid data after a prefix remap. It also fails closed when an S3 part never lands, checks SQL dump and remap temp writes, and validates DROP before it runs.

Huge uploads still use ZipArchive first. If close hangs or times out, a slower monitored zip path can take over. Destination review notices stay off after a failed restore, and a prior “don’t ask again” is preserved across restores.

Update from the Plugins screen, or install from https://wordpress.org/plugins/1-click-migration/

People search this after a WordPress backup dies on a cheap host, or after PHP logs a memory exhausted / Allowed memory size error during a database dump. Those are two different problems, and they are not the same failure in 1-Click Migration today.

Memory limit vs a large WordPress database

A large database used to crash PHP when the dump was built in memory. That is already handled.

In 1-Click Migration 3.1.10 and later, the SQL dump streams to disk in chunks. Before the dump starts, the plugin compares database size to PHP memory_limit. If an in-memory dump would run out of memory, it takes the streamed path instead of dying. Low-memory warnings go to the plugin log. They are a leading indicator, not a silent failure.

You do not need to raise memory_limit just to get a database backup to finish. A memory warning in the log means the streamed path is already in use.

How to tell which parts of a backup completed

A backup is not all-or-nothing. 1-Click Migration can finish the database, themes, and plugins even when uploads do not make it into the archive.

Look at three places:

1. The plugin UI. A backup that skipped a part finishes as completed with missing parts, with a warning banner. It does not report a clean backup.
2. The restore-code email. That email lists what is in the backup and what was skipped.
3. The Restore tab on the destination. Restore reads the backup’s part list first and warns which parts the code does not contain.

The four parts are database, plugins, themes, and uploads.

Auto-recovery when a backup stalls

Long backups can look frozen when a host kills a background worker or blocks admin-ajax loopback.

The plugin writes a heartbeat while it works. If the worker stalls, the progress poller resumes it. If the host blocks loopback, backup switches to direct processing instead of waiting on a worker that never starts. Stop & Reset is still there if you need to start over.

That recovery is for stalls and timeouts. It is not a claim that every site archives in one pass.

The failure that still hits huge sites: archive timeout on uploads

The live large-site failure is not the database memory crash. It is building and closing a huge uploads archive.

Sites with around 44GB of uploads, or around a million files under wp-content/uploads, can sit on the zip-close step until the host times out. After retries, the plugin skips uploads and keeps the parts that did finish. That is intentional honesty, not a silent success.

This is a different symptom from a memory_limit fatal. The database can stream fine while uploads are skipped. A plugin update does not make a million-file zip close faster on a host with a hard time limit.

What the restore code contains after a partial backup

If uploads were skipped, the restore code still works. It restores the parts that were backed up, usually the database, themes, and plugins. It does not include the media library.

After restore you get a working WordPress site without the skipped files. Media that lived in wp-content/uploads is not in that code. Copy those files separately (SFTP, rsync, or your host’s file manager) onto the destination, or run a second backup with only uploads if the library is small enough to archive.

Do not restore expecting photos, PDFs, and other uploads to appear from a code that listed uploads as skipped.

Finishing a move on a tight host

Use selective backup when the host is tight on disk, time, or process limits:

1. Backup database, themes, and plugins first. Restore that code on the new host.
2. Copy uploads yourself, or run an uploads-only backup if the media library is not huge.
3. Exclude cache, old backup zips, and unused themes or plugins before you start. Those files add time and size without moving the site.

There is no 4GB zip-download cap. Selective backup is still the right move when a host cannot finish a giant uploads folder in one pass.

Need help? Use the contact form and include the email you used with the plugin so we can find your logs.

Related: Step By Step Backup & Restore

This Labor Day weekend, WordPress migrations with 1-Click Migration are complimentary through September 7.

If you have been postponing a host move, a domain change, or a backup you keep meaning to take, this is a good window to do it.

How a WordPress migration works

1-Click Migration backs up a WordPress site, emails you an 8-character restore code, and restores it on a new host or domain. URLs and serialized data update automatically. The live site stays up during backup.

Backup your site

1. Install 1-Click Migration from the WordPress plugin directory.
2. Open Backup & Restore and enter the email that should receive the restore code.
3. Click Start backup. You can exclude plugins, uploads, themes, or the database if you only need part of the site.
4. When the backup finishes, we email you the restore code.

Backups are AES-256 encrypted before they leave your server. There is no 4GB zip cap. Very large databases may need a higher PHP memory_limit on the source host. Use selective backup when a host is tight on memory.

Restore on the new host

1. Install WordPress and 1-Click Migration on the destination site.
2. Open the Restore tab and enter the restore code from your email.
3. Click Restore.

Backups and restore codes are valid for 48 hours after the backup is created.

Through September 7

Complimentary WordPress migrations with 1-Click Migration run through September 7. We start charging September 8.

If you have a migration you have been postponing, this weekend is a good time to do it.

Need help? Use the contact form on 1clickmigration.com and include the email you used with the plugin so we can find your logs.

This guide moves a WordPress site to a new host or a new domain with 1-Click Migration: back up the old site, then paste the restore code on the new one. The same steps clone a site to staging or move a localhost or staging site to live.

Before you start

• Remove themes, plugins and media you don’t need. A smaller site backs up faster. Old backup zips and cache folders add time and size without moving anything.
• Deactivate every plugin except 1-Click Migration.
• Install 1-Click Migration from WordPress.org on the site you’re moving from.

Step 1: Back up the site you’re moving from

1. Go to Tools → One Click Migration.
2. Enter your email and click Start backup. Most backups finish in 10–30 minutes, and the site stays online while it runs.
3. Keep the email with your 8-character restore code. It’s the only way to restore the backup, and it works for 48 hours.

Step 2: Restore on the site you’re moving to

1. Install WordPress and 1-Click Migration on the new host or domain.
2. Delete any other plugins the host pre-installed.
3. Go to Tools → One Click Migration, paste the restore code and click Check backup & restore.
4. Review any extra site addresses the check found, such as an old domain or a CDN, choose which ones to rewrite, then start the restore.
5. Log in with the usernames and passwords from the original site.

Site addresses are updated throughout the database, serialized data included, so links and images point at the new domain.

If a large site fails

If a large site fails to back up or restore in one go, click Stop & Reset and use Advanced options to move one part at a time, with the database last. Each partial backup gets its own restore code.

If a backup hits a PHP memory error or finishes with uploads skipped, read WordPress migration plugin memory limit.

Good to know

• Every part of the backup is AES-256 encrypted on your server before it’s uploaded. Backups are deleted after 48 hours; after that the restore code stops working, so run a new backup.
• The database is imported into temporary tables and checked before it replaces anything. If a check fails, the restore stops, says why, and leaves the site as it was.
• We can’t resend a lost restore code. Check your spam folder, or run the backup again.

Need help?

Ask on the 1-Click Migration support forum on WordPress.org. Include your site’s domain, but never your restore code: anyone who has the code can restore your backup.