1-Click WordPress Migration Plugin – Backup, Migrate & Clone
| 开发者 | 1clickmigration |
|---|---|
| 更新时间 | 2026年11月12日 02:20 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv3 or later |
| 版权网址: | 版权信息 |
标签
下载
3.1.20
3.1.11
2.3.6
3.1.12
2.3.1
3.2.5
3.1.5
3.1.10
3.1.8
3.1.21
3.1.31
2.3
3.1.27
3.1.28
3.1.32
3.1.15
2.0
2.3.2
3.1.14
3.1.33
3.1.16
3.1.17
3.1.35
3.1.22
3.1.34
3.2.0
3.1.29
3.2.2
3.2.3
3.1.24
3.2.4
3.2.6
3.1.13
3.1.18
3.1.23
3.1.26
3.1.30
3.1.6
3.1.7
3.1.9
3.2.7
3.2.8
3.3.0
3.1.25
3.3.1
3.3.2
3.3.3
详情介绍:
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. There's no account and no license key. Each migration costs $9.99, with success guaranteed or a refund.
https://vimeo.com/1236211963
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 size cap. Back up and restore the database, plugins, themes and uploads together, or one part at a time.
- $9.99 per migration, success guaranteed or a refund. One payment per backup, through PayPal, from the link in your restore-code email, before you restore. It covers retries, and restoring the same backup on a second site.
- $15 a month for unlimited migrations. For agencies and anyone who moves many sites. Subscribe with the email you use in the plugin, and cancel anytime.
- If it doesn't work, we fix it or refund you. Reply to the restore-code email and we'll fix the migration or refund you in full. No questions asked.
- 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.
- Available 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.
- 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.
- Payments happen on PayPal's own page. The plugin never asks for card or payment details.
安装:
- 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.
屏幕截图:
常见问题:
How much does it cost?
$9.99 per migration, with success guaranteed or a refund. You pay once through PayPal, from the link in your restore-code email, before you restore. If you move many sites, $15 a month covers unlimited migrations, and you can cancel anytime.
What if the migration doesn't work?
Reply to the restore-code email and we'll fix it or refund you in full, no questions asked.
Do I pay again if I retry, or restore the same backup twice?
No. One payment covers the backup for the 48 hours it is kept. You can retry a restore, or restore the same code on a second site.
How do I pay?
With a PayPal account or a card, on PayPal's own page. The plugin never asks for payment details. If the restore check says a backup hasn't been paid for yet, it shows the payment link too.
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 size 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.
更新日志:
3.3.3
- "Out of disk space" now shows on the page: When a hosting account ran out of space during a backup, the plugin's own progress notes could get cut short. The page then stayed on the last step, such as "Archiving plugins", without saying the backup had stopped or why. It now shows that the account is out of disk space and how to fix it.
- Backups that take a while to get ready: Before a backup starts, the plugin measures your folders and registers the backup, which takes more than 20 seconds on some sites. With the plugin page open, it could take that pause for a stalled backup and stop it with "Backup failed: it stopped unexpectedly", again on every try. A backup now gets up to 10 minutes to get ready before the page checks on it.
- Listing: A shorter description. No change to the plugin itself.
- Pricing: A migration now costs $9.99, with success guaranteed or a refund. You pay through PayPal from the link in the restore-code email, before you restore. $15 a month covers unlimited migrations. If a migration doesn't work, reply to that email and we'll fix it or refund you in full.
- Paying is part of the restore check: When a backup hasn't been paid for yet, the restore check says so and shows the payment link, and the backup-completed notice names the price.
- Restores on a site that can't reach itself: A restore moves from step to step by having the site call itself. Some new sites can't do that, for example when their domain isn't live yet. On those, the restore stopped after its first minute and left the site in maintenance mode, without saying why. The restore now checks this before it starts, and if the site can't reach itself, it asks you to keep the plugin page open, which keeps the restore going.
- Large restores on hosts with a short request limit: Some hosts end every request after a minute or two. On those, a large database part (over 1 GB) could never finish decrypting or unzipping, because each attempt started over, and the restore stopped with "database part could not be downloaded or unpacked". Decrypting and unzipping now save their progress and continue in the next step, as downloads already did.
- After a restore: The "Restore complete" window now asks whether everything came across. "Yes, looks good" leads to the review ask and says that a free WordPress.org account is needed. "Something's off" leads straight to the support forum instead.
- Restores that use the MySQL command line: On some servers the database import reported success while WordPress couldn't see the imported tables, and the restore stopped with "the backup's main options table didn't pass the check". The restore now checks each imported table and, if WordPress can't see it, imports that table again through WordPress.
- Out of disk space during a backup: When the hosting account ran out of disk space while a backup was being prepared, the backup stopped with "encryption of the archive failed" and left its unfinished files behind. It now says the account is out of disk space, shows how to fix it, and deletes those files right away so the account isn't left full.
- Linked database tables: A restore could stop with "the database could not be imported" when a plugin on the old site keeps database tables that point to each other, such as a popup plugin's A/B test and visit log tables. These tables now restore and stay linked on the new site.
- Stop & Reset: Clicking Stop & Reset right after starting a backup could leave the backup running in the background, and it then reported "Backup failed". Stop & Reset now stops the backup straight away.
- Interrupted restores: When a restore picks up again after being interrupted just as a part of your backup finished downloading, it now keeps that download instead of fetching the same part again, so the restore finishes sooner.
- Short service hiccups: Starting a backup, uploading it, emailing the restore code and checking a restore code now try again on their own when the 1-Click Migration service is briefly busy or a connection drops, instead of stopping.
- Large uploads: If uploading a large backup in parts runs into a problem, the backup now picks up the upload where it left off instead of trying to send the whole file again in one go, which could never work for files over 5 GB.
- Clearer restore message: When the restore-code service is busy or can't be reached, the Restore tab now says so and that your backup is safe, instead of saying no backup was found for your code.
- PHP 8.4 and 8.5: The plugin no longer adds "Deprecated" notices to your error log, or to your pages when your site shows PHP errors. Its built-in libraries are updated to current versions, including security fixes in the library that encrypts your backups. Backups made with earlier versions still restore.
- Slow connections: A restore on a slow connection could sit on one download for up to 20 minutes until the host stopped it, or stop with "Restore failed while downloading" after a short pause in the connection. Downloads now pass the work on in short steps, a pause is simply tried again, and a slow download that keeps moving is no longer given up on after a set number of attempts.
- Restores from a shared database: If the old site's database also holds the tables of another WordPress site, such as a staging copy or a second install, the restore now brings over only your site's tables instead of stopping. If it can't tell which tables are yours, it stops before changing anything and says what to do.
- Very large folders: When the host keeps stopping a backup while it packs a big folder, the backup now waits for the packing already under way instead of starting it over, which could fill the disk. If it still can't finish, it explains how to make the folder smaller. Folders larger than 80 GB can now be uploaded.
- Clearer guidance: Starting a backup while another one runs now says so instead of waiting silently. If you get logged out during a restore, the page tells you before it reloads, and the logout tip now appears at the step where it happens. The restore-code reminder stays on the page after you reload it. If restored files can't be put in place, the page explains that the site stays in maintenance mode on purpose and how to leave it. The downloaded log starts with a short note on sharing it safely.
- Backups recover on their own too: If an unexpected error stops a backup partway, it now picks up again from where it stopped, up to two times, even with the plugin page closed. A backup that crashed no longer blocks Start backup until you click Stop & Reset.
- Clearer messages: The progress card explains problems in plain language instead of showing server errors, and a failed backup or restore still shows what happened and how to fix it after you reload the page. Hosts that need the page kept open now say so.
- Fix: A backup or restore could stall after handing its work to a new background request and wait forever. It now continues, and a run that truly can't continue ends with a clear message. Each backup's log also no longer includes the previous backup's log.
- Restores recover on their own: If an unexpected error stops a restore partway, it now picks up again from where it stopped, up to two times, and the site stays in maintenance mode while it does. It can also recover with the plugin page closed, and a download that had already finished before the interruption no longer makes it fail. In 3.1.30, a PHP time-limit error could take the site out of maintenance mode while the restore was still running.
- Fix: restores no longer crash when another plugin (such as WooCommerce) bundles an older background-processing library; a crashed restore no longer leaves the site in maintenance mode.
- Fix: a restore started right after one that crashed no longer waits forever with no progress. It clears what the crashed run left behind and starts, or tells you to click Stop & Reset if an earlier restore may still be running.
- 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.
- 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.
- 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.
- 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.
- Listing update: New plugin title and short description on WordPress.org. Backup and restore work exactly as in 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.
- 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.
- 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.
- 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.
- 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.