LazyClone – Copy a WordPress Site Without FTP

What is copied

Your site travels. Your server’s settings stay put.

LazyClone copies the things that make your site your site: all your content and settings, your media library, your active theme and your active plugins. It deliberately leaves alone the things that belong to the server the site runs on — above all the file that tells WordPress where its database lives. That is why a LazyClone import cannot leave a site unable to load, which is the classic way a manual move goes wrong.

Before anything is replaced on the receiving site, LazyClone renames the existing files to a dated “previous version”. Those are never deleted automatically. When you are happy with the new site, the Previous versions tab shows each set with its size and a delete button.

For the technical reader

The technical detail, if you want it

Everything above is all most people need. This section is for the reader who wants to know what is happening underneath.

What travels

The package holds a full database dump (transients skipped) plus, as ticked, wp-content/uploads, the active parent and child theme, the active plugins (LazyClone itself excluded) and the mu-plugins directory. Nothing from the WordPress root travels: no wp-config.php, .htaccess, robots.txt or verification files, and no wp-content drop-ins such as object-cache.php. Those belong to the server they run on.

Uploads that survive real hosting

The package uploads in chunks sized from the receiving server’s own upload_max_filesize and post_max_size (80% of the smaller, capped at 5 MB). If a web server in front of PHP rejects a chunk with 413, the uploader halves the chunk and retries, down to 256 KB. Any other failure is retried up to five times, and before each retry the uploader asks the server how many bytes it actually holds and resumes from there, so nothing is sent twice or skipped. An optional SHA-256, shown at export, verifies the upload before anything is touched.

Serialization-aware search and replace

Site URL, home URL, uploads path, wp-content path and ABSPATH are rewritten from the source values to the target’s. The rewrite unserializes, walks and re-serializes PHP-serialized values rather than string-replacing them, so widget settings, theme mods and ACF fields keep their byte counts correct; it also applies each replacement in its JSON-escaped form, which is how block attributes, global styles and navigation menus store URLs. Targets are discovered, not listed: every table with the site’s prefix and every text column in it, paged by primary key, so WooCommerce lookup tables and form entries are covered too.

Different table prefixes

The target keeps its own $table_prefix. Table names, the {prefix}user_roles option and prefix-derived usermeta keys ({prefix}capabilities above all) are rewritten during import, so a standard wp_ site imports cleanly onto a hardened install with a random prefix.

Staying alive through the import

Restoring the database replaces the users table, which invalidates your session mid-import. LazyClone mints a per-job capability token before it starts, so the remaining steps run without your session. After every database step it pins siteurl and home back to the target, so a failed import cannot leave the site redirecting to the source. During the file swap a temporary must-use plugin restricts WordPress to loading LazyClone alone, so the source site’s plugin list is never booted against a half-restored database; it self-expires after 30 minutes. If a step fails, the browser shows the recorded fatal and the last database errors rather than a bare 500, and an unfinished job can be resumed or discarded from the LazyClone screen.

Known limits

• Single site only; multisite is not supported.
• Option names derived from the prefix by third-party plugins are not rewritten.
• Values holding serialized objects are skipped by the rewriter rather than risk corrupting them; raw binary in text columns needs mysqldump.
• Database views are not exported.
• Very large media libraries are slow rather than broken: the archive is rewritten at each step, so the job briefly needs a second copy’s worth of free space.
• On Nginx, wp-content/lazyclone-jobs/ is not protected by the bundled .htaccess; add a location block or rely on the unguessable job id.