Clone a WordPress Site: Migration and Cutover Checks
To clone a WordPress site with Duplicator Lite, create a backup containing the site’s files and database, download its matching archive and installer.php, then install both in an empty directory on the destination server. You do not need to install WordPress on that empty destination first. The process can copy a site to staging, move it to another host or create a development version under a different domain—but the clone is only complete after you test the URLs, forms, images and database, and remove every public installer file.
Which migration method fits your site?
New, empty destination: use Duplicator Lite’s classic installer, described below. Overwrite an existing site: make a separate destination backup first; overwrite mode can permanently replace its database and files. Want dashboard-to-dashboard drag-and-drop imports, automatic staging or scheduled cloud backups? compare Duplicator Pro’s documented features and the current plan before paying.
Duplicator’s official WordPress.org listing shows an actively maintained plugin, with version 5.0.4 listed in September 2026. The vendor now calls the export a backup rather than the package used in older screenshots. Treat the current interface as authoritative if a button label differs.
Control side effects on the cloned site
A clone can inherit live email, payment, webhook and scheduled-task settings. Before testing, disable or sandbox outbound actions that could notify real customers, charge money or send data to production systems.
Password-protect staging and review indexing settings. Use sample transactions, then confirm the final production site has the correct domain, HTTPS, sender configuration and integration credentials.
For an active store, agree a cutover window and a method to preserve orders created after the first copy. Do not replace a live database with an old staging database just to deploy visual changes. After success, remove migration installers and archives from publicly accessible locations and test the original important URLs.
When is cloning different from making a backup?
A backup is a recoverable copy stored safely for an emergency. A clone is a functioning second installation created from that copy. A migration moves the live site to a new location, where DNS, email and visitor transactions may need coordinated changes. Duplicator can support all three, but creating an archive alone does not prove the clone will boot or that a live store’s latest orders were captured.
For a content site, a pre-migration database snapshot is often sufficient when combined with a short publishing freeze. For a busy WooCommerce store, coordinate a maintenance window or a final database sync so orders placed after the archive was created do not disappear from the new site. Do not promise zero downtime or zero data loss simply because a plugin’s marketing page uses those phrases.
Duplicator Lite vs Pro: what actually changes?
| Task | Duplicator Lite | Duplicator Pro |
|---|---|---|
| Make a full-site archive | Yes | Yes |
| Classic archive + installer migration | Yes | Yes |
| Overwrite existing site | Documented, with destructive risks | Documented, with destructive risks |
| Drag-and-drop import | Not in the documented Lite classic workflow | Documented import feature |
| Scheduled Dropbox and other third-party remote backups | Check limited free cloud options separately | Vendor lists Dropbox, Drive, S3 and other integrations |
| One-click staging and multisite tools | Not part of this basic cloning walkthrough | Listed Pro features; check plan availability |
Feature descriptions follow the vendor’s current classic installation and overwrite installation documentation. The Pro product’s exact prices, renewals and site limits change; check the live checkout rather than relying on an old price in a migration tutorial.
How to clone a WordPress website with Duplicator Lite: seven steps
1. Prepare the source and destination
Before making a backup, update or document your installed plugins and theme, confirm access to both hosts, and record the source URL, PHP and database versions. Take an independent backup of the source. Decide whether you are making a private staging copy or moving a public live domain. On staging, use suitable access controls and prevent the test site from sending real customer emails or processing live payments.
Important: the classic method below assumes a new empty directory and a database you can safely write to. If the destination already contains an important site, do not treat this as an ordinary empty-directory install; use the separate overwrite documentation and back up that destination first.
2. Install Duplicator and create a backup
On the source site’s WordPress dashboard, install Duplicator from Plugins → Add New. Open Duplicator → Backups and start a new backup. Include the WordPress database, themes, plugins, uploads and other site files required by your project. The vendor’s current docs call this a backup; older guides and screenshots call it a package.
Review the pre-build scanner. Large archives, a nearly full disk, unreadable files or blocked directories can cause incomplete exports. Don’t dismiss critical scan errors simply to proceed.
3. Download both matching files
When the backup finishes, download both the archive (.zip or .daf) and its matching installer.php. Keep them together and preserve their names. The installer without the archive cannot rebuild the site, and an archive alone does not complete this classic workflow. Store a second copy somewhere private rather than in a publicly browsable uploads folder.
Get Duplicator Lite from WordPress.org →
4. Prepare a clean folder and destination database
Create an empty destination directory for the new site, and create a separate database and database user with appropriate privileges. The actual web root varies by host: it might be public_html, www or a domain-specific folder. Do not assume that public_html is always the correct path.
If the new site is not yet live in DNS, use your host’s supported preview or a local hosts-file test to reach the correct destination. Protect the installer from unrelated visitors while the migration is in progress.
5. Transfer the archive and installer securely
Upload the two matching files to the empty target directory using your host’s file manager or a secure transfer method such as SFTP. FileZilla is one possible client if your hosting provider supports it. The classic Duplicator documentation describes either an archive ZIP or a DupArchive .daf file. Do not extract the archive manually unless you are following a specific supported troubleshooting procedure.
6. Run the installer and verify every database choice
Visit the destination’s installer URL over HTTPS, such as https://example.com/installer.php, using the domain and path you actually configured. Follow the prompts, enter the destination database credentials, and inspect the database-action screen carefully before confirming it. Some installer database actions can delete existing tables. If the database is not the new empty one you intended, stop rather than clicking through.
Review the new URL and file path, run the import, and sign in using the credentials appropriate to the cloned installation. Duplicator’s installer can update URLs during migration; verify the outcome, especially if the source was localhost or a different domain.
7. Check the clone, then remove installer artifacts
Open a few posts, pages, images, menus and forms. Review Settings → Permalinks if routes return 404, and test login, HTTPS, scheduled tasks, redirects and any store checkout in the appropriate test mode. Duplicator strongly instructs operators to remove its installer and archive files from the web server after a successful installation.
Look for installer.php, installer-backup.php, the dup-installer directory, installer logs and the archive file; use Duplicator’s automatic cleanup where offered and verify the removal yourself. A request to the old installer URL should no longer present the installer. See the vendor’s complete cleanup checklist.
Moving a live domain without losing new content
For a site that keeps receiving comments, orders or registrations, the archive is a snapshot at a particular time. If you continue accepting changes on the source while building the destination, the clone can miss those later changes. Agree on a content freeze, maintenance window or a vendor-supported final synchronization process before the DNS cutover. Lower the DNS record TTL ahead of time when appropriate, verify the destination SSL certificate and monitor both locations during the transition.
Keep the original hosting intact until you have verified the new site and its backups. A cloned site that looks correct on the homepage can still have broken images, mail delivery or checkout integrations.
Why a Duplicator clone can fail
| Symptom | Check first |
|---|---|
| Archive build fails or times out | Scanner warnings, available disk space, server limits and archive engine |
| Installer cannot find archive | Matching archive and installer in the same intended target directory |
| Database connection error | Correct new host, database name, username, password and privileges |
| Old domain appears in links | Installer search-and-replace report, cache and hard-coded theme settings |
| Pages return 404 | Permalinks, Apache rewrite or Nginx routing configuration |
| Clone is visible to Google | Staging access control and search-engine indexing settings |
When the installer fails, inspect Duplicator’s own log rather than repeatedly deleting or overwriting the database. The vendor’s migration troubleshooting guide explains its logs and validation checks.
When is Duplicator Pro worth considering?
For a one-off clone into an empty directory, Lite’s classic workflow may cover the entire job. Pro becomes relevant when you perform repeated migrations for clients, require import workflows, scheduled remote backups, a dashboard-created staging site, or advanced multisite tools. The current vendor documentation reserves its drag-and-drop Import Install for Pro. Do not buy it expecting that a higher licence tier will make a database overwrite non-destructive.
Compare Duplicator Pro plans and migration tools →
Frequently asked questions
Can I clone a WordPress website for free?
Yes. Duplicator Lite documents creating a site backup and moving its matching archive and installer to a new empty destination. Check hosting limits and test the completed site; the plugin does not include the destination hosting or domain.
Do I install WordPress on the destination first?
Not for Duplicator’s classic installation into an empty directory: the matching archive and installer provide the WordPress files and database content. An already installed destination requires a different, potentially destructive overwrite or import workflow.
Is Duplicator’s drag-and-drop migration free?
The vendor’s current installer guide labels drag-and-drop or URL-based Import Install as Pro only. Lite supports the classic archive-plus-installer route described above.
Will my old domain and links change automatically?
The installer can update URLs during a migration, but you must still verify the destination URL, hard-coded links, caching, SSL and any third-party integrations. A database import alone cannot correct every outside service setting.
Should I delete installer.php after cloning?
Yes. Duplicator warns that publicly reachable installer files and archives can expose or allow reinstallation of site data. Complete the vendor’s cleanup procedure and verify the files are gone.
Can I clone a WooCommerce store with no lost orders?
Not by assuming the first archive stays current. New orders placed on the source after the backup will not automatically appear on the destination. Plan a maintenance window or supported final sync and check the order count before switching traffic.
Start with the free classic workflow: install Duplicator Lite and keep the official classic installation instructions open while you perform the move. For other backup strategies, see WPNeon’s WordPress backup plugins guide.
