Description
Back up, migrate and clone a WordPress site
1-Click Migration backs up your WordPress website and emails you an 8-character restore code. Paste that code into a new host, a new domain or a second install, and the site is restored there. Site addresses are updated throughout the database, serialized data included. Your live site stays online while the backup runs. It’s free, with no account or license key.
What you can do with it
- Move to a new host. Transfer a website between any two hosts without downloading or uploading backup files yourself.
- Change your domain name. Copy a WordPress site to a new domain, and the old address is replaced everywhere in the database, including inside serialized options and widgets.
- Hand a site over to a client. Move WordPress to the client’s own hosting account. The site transfer takes one backup and one restore.
- Go from localhost or staging to live. Push staging to live, or move WordPress from localhost to a server. Back up the staging or local site and restore it on the live server.
- Clone or duplicate a site. Duplicate a WordPress site for staging or testing by restoring its backup on a second install.
- Move large sites. There is no 4GB zip cap. Back up and restore the database, plugins, themes and uploads together, or one part at a time.
Use it for any WordPress site migration: a hosting migration to a new provider, a server migration within the same host, a domain migration, or a move from localhost to live. You can move WordPress to another server, host or domain, and the migration itself needs no FTP, cPanel or phpMyAdmin, just a WordPress login on each site. It’s a free, automatic migration tool for a complete website migration, from the database to the uploads folder.
Built to fail safely
- The database is imported into temporary tables and checked before it replaces anything. If a check fails, the restore stops, says why, and leaves your site as it was.
- Before the restore starts, the plugin checks your code and lists other domains found in the backup, such as an old domain or a CDN, so you choose which ones to rewrite.
- Free disk space is checked before files are unpacked.
- Long backups and restores run in short steps and pick up where they left off, so hosts with strict PHP time limits are fine.
Private by default
- Every part of the backup is AES-256 encrypted on your server before it’s uploaded.
- Backups are stored on Amazon S3 and deleted after 48 hours.
- Only someone with the restore code can restore the backup, and we email the code only to the address you enter.
Learn more at 1clickmigration.com.
How it works
On the site you’re moving from
- Remove themes, plugins and media you don’t need. A smaller site backs up faster.
- Deactivate every plugin except 1-Click Migration.
- Go to Tools One Click Migration, enter your email and click Start backup. Most backups finish in 10–30 minutes.
- Keep the email with your 8-character restore code. It’s the only way to restore the backup.
On the site you’re moving to
- Install WordPress and 1-Click Migration on the new host or domain.
- Delete any other plugins the host pre-installed.
- Paste the restore code, click Check backup & restore, review any extra site addresses, then start the restore.
- Log in with the usernames and passwords from the original site.
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.
Reviews
If 1-Click Migration moved your site, please leave a review. It helps other people find the plugin and helps us improve it.
Screenshots
Installation
- Install 1-Click Migration from Plugins Add New, or upload the
1-click-migrationfolder to/wp-content/plugins/. - Activate it on the Plugins screen.
- Go to Tools One Click Migration to start a backup or a restore.
FAQ
-
How long does a migration take?
-
Most backups and restores finish in 10–30 minutes. Large sites and slow hosts take longer.
-
How long is my backup available?
-
48 hours. After that the backup is deleted from storage and the restore code stops working, so run a new backup.
-
I lost the restore code email. Can you resend it?
-
No. We can’t retrieve a lost code. Check your spam folder; if it isn’t there, run the backup again to get a new code.
-
Can I move only part of a site?
-
Yes. Use Advanced options to back up or restore the database, plugins, themes and uploads separately. Each partial backup gets its own restore code.
-
Will links and images work on the new domain?
-
Yes. The restore replaces the old site address throughout the database, including inside serialized data. You choose whether other domains found in the backup are rewritten too.
-
Is there a size limit?
-
There’s no 4GB zip cap, and no 512MB import limit to fix or upload limit to bypass. You never upload a backup file through your browser, so there’s no file size limit to increase in php.ini. Very large databases may need a higher PHP memory_limit on the source host. If a big site fails in one go, move it one part at a time.
-
Does my site go down during a migration?
-
The site you back up stays online, so the migration causes no downtime there. The site you restore onto shows a maintenance page while the restore runs.
-
Can I use it to create a staging site?
-
Yes. Restore the backup on a separate WordPress install, such as a staging subdomain. The copy uses the staging site’s address.
-
Can I migrate a WooCommerce store?
-
Yes. Products, orders and customers are in the database, so a WooCommerce store moves like any other site. Orders placed on the old store after the backup starts may not be in it, so move the store at a quiet time or pause orders until the new site is live.
-
Does it work with WordPress Multisite?
-
Not yet. It supports single-site installs.
-
Can I move a local site to a live server?
-
Yes. Back up the local site, then restore it on the live server with the restore code. The local site needs an internet connection to upload the backup.
-
Which hosts does it work with?
-
Any host that runs WordPress on PHP 7.4 or later, including Bluehost, SiteGround, Hostinger, GoDaddy, HostGator, DreamHost, Namecheap, IONOS, A2 Hosting, InMotion Hosting, GreenGeeks, ScalaHosting, Liquid Web, Cloudways, WP Engine, Flywheel, Kinsta, Pressable and Pantheon, plus cloud servers on DigitalOcean, AWS Lightsail, Vultr and Linode, and local development sites. It works with cPanel, Plesk or no control panel at all. It also works on hosts that block background requests or cut long PHP requests short. On Pantheon, restore onto the Dev environment in SFTP mode, because code folders on Test and Live are read-only.
Reviews
Contributors & Developers
“1-Click WordPress Migration Plugin – Backup, Migrate & Clone” is open source software. The following people have contributed to this plugin.
Contributors
Translate “1-Click WordPress Migration Plugin – Backup, Migrate & Clone” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
3.1.29
- Minimum WordPress 5.3: The plugin now lists WordPress 5.3 as its minimum. It’s the first version that officially supports PHP 7.4, which the plugin already requires. Backup and restore work exactly as in 3.1.28.
3.1.28
- Ready for translation: The plugin page, its notices and the help shown with backup and restore progress can now be translated on translate.wordpress.org. Once a translation for your language is ready, WordPress installs it with the plugin. Progress steps come from the migration log and stay in English. The minimum WordPress version is now listed as 4.9, which the plugin already needed.
3.1.27
- Listing update: The description and FAQ now cover WooCommerce stores, more hosts and cloud servers, staging to live and domain name changes, and link to step-by-step guides on 1clickmigration.com. Backup and restore work exactly as in 3.1.26.
3.1.26
- Listing update: More hosts and a local-to-live question in the FAQ. Changelog entries before 3.1.20 moved to changelog.txt. Backup and restore work exactly as in 3.1.25.
3.1.25
- Listing update: New plugin title and short description on WordPress.org. Backup and restore work exactly as in 3.1.24.
3.1.24
- Help links go to the support forum: When a backup or restore fails, stops or stalls, the progress card now links to the WordPress.org support forum instead of the 1clickmigration.com contact form. It asks you to share your site’s domain and never your restore code, because anyone who has the code can restore your backup. The help sections on the plugin page and the summary of an unfinished restore link there too.
- Updated plugin listing: New title, short description and description on WordPress.org. Two corrections: a restore needs only the restore code, and the plugin page is under Tools One Click Migration.
3.1.23
- Clearer progress card: The progress card no longer shows internal log lines (such as “SYSLOG: Dispatching backup worker”) or full server paths for routine steps. It now shows plain step names such as “Starting the backup worker” or “Archiving themes”. Error messages still include the path, so you can fix permissions or quota.
- No more false “taking longer than expected” notice: Workers hand over to the next worker every 20 seconds. These planned hand-overs no longer show “Process is Restarting” or the “taking longer than expected” notice. The notice now appears only when a worker has actually stalled. It goes away once the run is moving again and is cleared when the run finishes. A new run no longer picks up the previous run’s stall state.
- The progress bar no longer jumps backwards: During a restore the bar could drop back to 1% (“Starting restore…”) on log lines it didn’t recognize. After the database import it went 84% 40% 83% 62%. It now keeps the current step and moves forward in the order the restore actually runs.
3.1.22
- Quieter restore log: Restores no longer log a warning for each temporary copy of a database file that was already removed.
- No empty folders after backups: A finished or failed backup now removes its empty work folder instead of leaving one behind for every run.
3.1.21
- Restores survive strict server time limits: Some hosts end a PHP request after 30 seconds, sooner than the plugin expected. Backup and restore workers now hand over to the next worker before that limit (20 seconds by default) without losing finished steps. If a worker is cut off during the database import anyway, the next one resumes the import where it stopped, instead of stopping with “the backup’s main options table didn’t pass the check”.
- Restore files kept out of the web root: The restore used to unpack the database dump and the other parts into
wp-content/ocm_restore. Servers that ignore.htaccess(such as nginx) could serve those files to anyone during a restore and after a failed one. Restore and backup work files now go to the private folder outside the web root. Where that isn’t possible, they go to a randomly named, access-protected folder. A leftoverwp-content/ocm_restorefrom an older version is removed. - Separate logs for sites in the same folder: Sites installed side by side in one folder no longer share the migration log and the restore lock. Each site now has its own folder inside
.ocm-private. - Every stopped restore cleans up: Each restore that stops with “No changes were made” now clears the success and review prompts, the restore queue and any temporary tables. This includes a database part that can’t be downloaded.
- Restore right after a stopped one: A restore started from the admin page soon after a failed or stopped run could stop at once with “the database could not be imported”. The progress check no longer clears anything while a new restore starts.
- No leftover restore workers: After a restore fails or stops, no worker from that run keeps downloading, decrypting or logging, and a new restore no longer overlaps a worker from the previous run.
- Source site’s scheduled events stay behind: A restore no longer copies the source site’s scheduled 1 Click Migration events to the destination.
- Faster logging: The migration log is now sent to storage at most every 10 seconds and immediately when a run ends, instead of after every line. This made backups and restores slower.
3.1.20
- Site addresses updated before the swap: The restore now updates site addresses on the imported copy of the database, before it replaces the live database and files. If that step can’t finish safely (for example a table with no primary key, a row too large for the PHP memory limit, or the memory limit itself being reached), the restore stops with no changes made to the site, instead of leaving it half-restored.
- Restore never resumes the source’s backup: A backup’s database is dumped while that backup is still running. After a restore, the destination could pick up the source site’s unfinished backup and upload into the source’s storage. The destination now keeps its own plugin state when the database is swapped in, and a backup can’t run while a restore is in progress.
- One restore worker at a time: Long downloads and decryption now report progress, so the restore is no longer mistaken for stalled and started twice. A process lock also keeps a second restore worker from running alongside the first. A missing temporary file is no longer reported as a disk-quota problem.
- Progress check after backup: Checking progress the moment a backup finished could log a fatal
count()error. It now exits quietly and never finishes the backup twice. - Crashes are always logged: A fatal PHP error during a backup or restore is now always logged, including parse and compile errors and a repeat of an earlier crash. A crashed run no longer looks like it is still in progress.
- Clearer storage and disk errors: Running out of disk space while decrypting a part is reported at that step, not later as a corrupt archive. A failed upload of a large part no longer leaks the storage error into the progress screen, and an upload without a storage receipt is now logged.
- No address prompt after a stopped restore: A restore that stops with no changes made no longer offers to update extra site addresses.
- Steadier progress bar: Some internal log lines, such as low-memory notices and duplicate-worker exits, could send the progress bar back to 1% or show as the current step. They no longer do.
Older versions are listed in changelog.txt.