Site icon Spiracle Themes

WordPress Duplicator: Move or Clone a Site Safely (2026)

Editor Team
WordPress-Duplicator

Duplicator turns a WordPress site into two downloadable files — an installer.php and an archive containing every file plus a database dump — which you upload to the new location and run in a browser to rebuild the site. It is the most direct way to move a site between hosts or domains without touching a database export and an FTP client separately.

The current release is 5.1.0, updated 27 October 2026, running on roughly a million sites with a 98% rating across nearly 5,000 reviews. It works. What goes wrong in practice is not the plugin but the environment around it: archive size against host limits, timeouts during the build, and the security hole left behind when someone forgets to delete the installer.

Key takeaways

What a package actually contains

When you build a package, Duplicator produces:

Both files must sit in the same directory on the destination server. If you would rather take a partial export instead of a full package, exporting a WordPress site walks through the database-plus-content route. The installer reads the archive, extracts it, creates the database tables, imports the dump, updates siteurl and home to the new domain, and then asks you to log in.

Because the archive holds your entire site including wp-config.php and the database dump, it contains database credentials, user password hashes and any API keys stored in options. Treat the download as you would a database dump — which is also why leaving it on a public server is dangerous.

Before you build: the checklist that prevents most failures

If the site is on shared hosting you do not control, check the upload limit before committing to a browser-based file transfer. Moving a 2 GB archive through a browser-based file manager is where several hours disappear.

Step 1: Build the package

  1. Go to Duplicator ? Packages and click Create New.
  2. Name the package something you will recognise later — live-to-staging-2026-10-30 beats backup1.
  3. Leave storage as Local for a migration you are doing now. Cloud destinations matter for scheduled backups, which are a Pro feature anyway.
  4. Run the scan. Duplicator checks the server before building: PHP version, zip support, disk space, and whether it can reach the database.
  5. Review the size warnings. This is the step people skip, and it is where a build that will time out announces itself.
  6. Click Build. On a small site this is under a minute; on a large one it can take twenty.

Excluding what should not travel

Every extra gigabyte in the archive is a gigabyte to upload. Before building, exclude things that are regenerable or already elsewhere:

Most sites drop 30–50% of their archive weight by excluding those four categories, and the migration time falls accordingly.

Step 2: Move both files

Download the installer.php and the archive from the package’s download page. If the package is large, download the archive first and the installer second — a timed-out download of the installer is trivial to retry, a partitioned archive is not.

Upload both to the destination’s web root, side by side. Then note two things: the URL of the installer (https://newdomain.com/installer.php) and whether the host’s file manager preserved the file sizes. A truncated archive uploads without error and fails later at 60% extraction, which is a much harder failure to diagnose than a rejected upload.

Step 3: Run the installer

Open the installer URL in a browser. In Duplicator 5.x the flow is:

  1. Accept terms — and let the installer validate that the archive is readable and the destination is writable.
  2. Connection — enter the destination database host (usually localhost), database name, user and password. The installer tests the connection before continuing, so an error here is a credentials problem, not a Duplicator problem.
  3. Options — confirm the new Site URL. Leave the “advanced” defaults alone unless you specifically need to change the archive extraction path.
  4. Run the install — the installer extracts files, imports the database, then rewrites the old domain throughout the database. Do not close the tab. On a large site this step can legitimately sit at the same percentage for several minutes.
  5. Test the site — the installer offers a link. Check the homepage, the admin login and one deep URL before you delete anything.

If the installer reports a database import failure partway through, the usual cause is a table prefix collision — the destination database was not empty. Drop all tables in it and rerun the install step; the files are already extracted and do not need re-uploading.

Step 4: Finish and clean up

  1. Delete installer.php, the archive, and the installer’s log files from the destination root.
  2. Log in to the destination and confirm the site URL under Settings ? General matches the new domain.
  3. Re-save permalinks (Settings ? Permalinks ? Save) so the rewrite rules regenerate.
  4. Clear caches and regenerate the CSS cache if your theme or Elementor ships one.
  5. Check wp-config.php for any hardcoded paths or absolute URLs the rewrite could not reach.
  6. Verify email sending — many hosts block mail(), and a migrated site silently stops sending order confirmations.

Step 1 is not optional. More on that below.

The five failures that account for most support threads

The archive is too large to upload

Use the host’s file manager or SFTP rather than the browser uploader, or build with the archive split into parts. Some hosts cap a single file at 512 MB or 2 GB regardless of the panel’s stated limit. If the site is enormous, migrating wp-content/uploads separately by rsync and moving only the database plus code through Duplicator is faster than fighting the cap.

The build times out or hangs at “Prepare Files”

The server’s execution limit is shorter than the build needs. Raise max_execution_time and max_input_time, and check the memory limit — raising the PHP memory limit is often enough on a site that stalls after the database step.

The installer sticks at 100% or sits on “Extract Files”

Usually a permissions problem: the installer cannot write into the directory it is extracting to. Check that the web user owns the destination folder, or run the installer with the extraction path pointed at a writable directory. It can also be a truncated archive — compare the file size on the destination with the size reported in the package.

“Connection lost” and a restart loop

Shared hosting cuts a PHP process that runs longer than the request allows. Refresh the installer page; it resumes from the last completed step in most cases. If it loops, reduce what you are moving (the exclusion list above) rather than retrying the same package.

The site loads but every page 404s

Permalinks. The rewrite rules are stored in the database and expect the new domain, and they regenerate only when you re-save the Permalinks settings. If that fails, check that mod_rewrite is enabled or that the nginx config includes the WordPress block. A database connection error at the same stage is a different problem — usually wrong credentials in wp-config.php after the import, covered in fixing database connection errors.

The security problem with leftover installer files

This deserves its own section because it is the one mistake with serious consequences.

The installer is designed to set up WordPress with whatever database credentials you give it. If you leave installer.php and the archive in the web root, anyone who finds that URL can run it, point it at their database, and rebuild the site into a WordPress installation they control — on your domain. They do not need your password. The archive gave them all your files; the installer gives them the ability to replace your content.

Practical rules:

Duplicator vs the alternatives

Plugin Active installs Rating Last updated Best at
Duplicator 1,000,000 98% (4,940) 27 Oct 2026 Moving a full site to a new host or domain
All-in-One WP Migration 5,000,000 90% (7,676) 27 Oct 2026 Drag-and-drop migration; simplest UI, free import size limits
UpdraftPlus 4,000,000 96% (8,704) 26 Oct 2026 Backups on a schedule, restore in place
WP Migrate 200,000 84% (318) 12 Oct 2026 Pushing/pulling between environments developers control

The honest comparison: Duplicator is best when you need a portable package you can upload anywhere, including hosts where you have no SSH access. All-in-One WP Migration is easier for a first-time migration but its free version caps import size, which is a wall you hit on any site with real media. UpdraftPlus is a backup tool that can also migrate — if you already run it for backups, using it for the move avoids installing a second plugin. WP Migrate is for developers with SSH and WP-CLI, not for a one-off host change.

When Duplicator is the wrong tool

Frequently asked questions

Is Duplicator free?

The free version is fully functional for migrations and manual backups: full-site backups of any size, AES-256 encryption, one-click restore, local retention. Duplicator Pro adds scheduled backups, third-party cloud destinations (Dropbox, Google Drive, OneDrive, Amazon S3, FTP/SFTP), multisite support, staging sites and server-to-server imports. For a one-off move between hosts, the free version is enough.

Can I use Duplicator to move a site to a new domain?

Yes — that is its primary use. The installer rewrites the old domain throughout the database during the install, so internal links, image URLs and stored settings follow the new domain. Check afterwards for anything hardcoded outside the database, such as absolute paths in wp-config.php or URLs baked into page-builder templates.

Why does the installer need an empty database?

Because it creates the tables and imports a full dump; it merges nothing. If the destination database already contains tables, the import fails or partially overwrites them. Drop all tables in the destination database before running the installer. On most hosts, phpMyAdmin’s “Drop all tables” option handles it in one click.

How long does a Duplicator migration take?

The build takes a few minutes for a small site and up to twenty for a large one; the transfer depends entirely on your upload speed; the install step runs in one to five minutes on typical shared hosting. The variable that ruins estimates is archive size — exclude caches and old backups first and the whole job usually fits in half an hour.

Do I need to delete installer.php after migration?

Yes, always, in the same session. A live installer on a public URL lets anyone rebuild your site with their own database, and the accompanying archive hands them all your files. If you cannot delete it immediately, rename it to something unguessable and restrict access by IP until you can.

Will Duplicator work on any host?

It works wherever PHP runs with zip support and a writable web root — which covers essentially all shared and managed WordPress hosting. The obstacles are size limits rather than compatibility: hosts that cap single-file uploads, or kill PHP processes after 30 seconds, will break a large migration regardless of the plugin. Check both limits before you start.

Doing it properly, in order

Build the package with caches and old backups excluded, move both files, run the installer against an empty database, then delete the installer and archive before you do anything else. Re-save permalinks, clear caches, test email. Those four steps are the difference between a clean migration and a site that half-works while a stranger holds the keys to it.

And keep a copy of the package off the server — a migration is also the moment you have a perfect snapshot of the site as it was, which is worth more than the migration itself if something goes sideways. If you handle sites for clients, treating that snapshot as part of a maintenance plan rather than a one-off is what stops this being a fire drill next time.

Exit mobile version