Restores on any server
Every package ships with an installer.php that needs no WordPress on the target. Same file for moving hosts, cloning live to staging, or rolling a site back.
★ Free plugin
Packages your whole site — every file plus a full database export — into one archive, with a standalone installer that rebuilds it on any server. The build runs in short, resumable slices, so it finishes on shared hosting that kills a request after thirty seconds.
Overview
A backup is only worth what it restores. Every Sitecarry package carries the files, a complete database export and a standalone installer — one program that rebuilds the site on a server with no WordPress on it at all, rewriting URLs and paths as it goes.
The hard part of moving a WordPress site is that a lot of its settings are PHP serialized data, where every string carries its own byte length. A plain search and replace breaks those lengths, and that is how a migration quietly wipes widget settings and page builder layouts. Sitecarry rewrites the serialized form directly and repairs the lengths, including the JSON-escaped URLs Elementor stores its content in.
Screenshots
Pricing
$0
The whole plugin. Backup, restore, schedules, incremental, every storage destination. No tier that unlocks the part you actually needed.
Quoted
Sitecarry is the tool we use to move sites. If you would rather the move simply happened, that is a service we offer.
Sitecarry is not on the WordPress.org plugin directory yet — the download here is the current build, and updates will move to the normal WordPress updates screen once it is listed.
Changelog
Deleting the plugin now clears its settings and scheduled events, and deliberately leaves your packages alone — deleting a plugin should not destroy the only copy of a site.
Ten fixes, most of them cases where an interrupted backup could resume into a corrupt archive. The database export now pages by primary key, which is both correct and far faster on large tables.
Sitecarry writes the ZIP itself, appending and never rewriting, so build time grows with the size of the site instead of with its square. ZIP64 throughout, and PHP's zip extension is no longer needed.
Two more destinations, both chunked and resumable. Drive uses an OAuth client of your own, so authorisation never routes through anyone else's servers.
When the archive is no longer on the server — pruned, or because the server itself is gone — the installer downloads it from S3. That is the situation a backup exists for.
Questions
If you would rather not do the migration yourself, the website migration page covers that.
Comfortably into the tens of gigabytes. Sitecarry writes its own archive format rather than using PHP's zip extension, appending each file to the end and never rewriting what is already there — so the work grows with the size of the site instead of with the square of it. ZIP64 is used automatically, so neither the archive nor any file in it stops at 4GB.
You still need free disk space for the package, and enough for the database export while it is being written.
Because it replaces the very files WordPress is running from. Anything doing that from inside WordPress would be pulling the floor out from under itself partway through.
The installer is a standalone program that never loads WordPress, which is also why it works on a server that has nothing installed on it yet.
The same reasoning is why WordPress itself documents a manual restore as a file-level operation rather than something done from the dashboard — see the WordPress backup documentation.
Yes, and this is the part most migrations get wrong. WordPress stores a lot of settings as PHP serialized data, where every string records its own byte length; replacing a domain with a longer one using a plain search and replace breaks those lengths and WordPress can then no longer read the value.
Sitecarry rewrites the serialized form directly and repairs the lengths, and it also handles the JSON-escaped form (https:\/\/) that Elementor and other page builders store their content in.
No, and nothing short of restoring it does. Verifying proves the archive is the one that was written, still opens, and holds the files a restore starts from — which catches truncated uploads, disks that filled mid-write, and silent corruption. It cannot tell you the database inside will import cleanly on a different server.
In wp-content/uploads/sitecarry/, with an unguessable filename, direct web access blocked by .htaccess and web.config, and downloads served only through an authenticated admin request — never a public URL.
Every package also has its own restore passphrase, shown in the admin and deliberately kept out of the archive, so an installer left behind on a server cannot be used by anyone else to overwrite the site.
When packages are sent off-site, use a key scoped to one bucket rather than an account-wide one — Amazon S3 and every service that speaks its protocol support this, and it limits what a leaked key can reach.
Nothing. Sitecarry removes its own settings and scheduled events and leaves the packages in wp-content/uploads/sitecarry/ exactly where they are — deleting a plugin should never be the thing that destroys your last copy of the site. Delete that folder yourself once you are sure.