How to Migrate WordPress With the Duplicator Plugin (Step-by-Step)

Duplicator moves a WordPress site by packaging its files and database into an archive, then restoring that package on another server. For the classic migration, you create a package on the old site, download installer.php and the archive, upload both to the destination, run the installer, enter the destination database details, update the site URL when necessary, test the restored site, and remove the migration files. A separate Duplicator Pro feature called Import Install can replace an existing WordPress installation from a local archive or an archive URL.

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

The process does not normally require WordPress to be preinstalled in the destination directory when you use the classic package installer. You do need a destination hosting account or cloud server, a database, and enough access to upload files and open the installer URL. The destination host’s directory and database instructions take precedence. Duplicator describes its purpose as backing up a site or transferring it to another location; the WordPress.org listing attributes that description to expert web developer Richard McAdams.

#	Preview	Product	Price
1		How to Migrate Your WordPress Site with WordPress Duplicator Plugin: Duplicator is a free and...	$7.00	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

What Duplicator actually moves

A WordPress site is more than the files visible in the media library. Its themes, plugins, uploads, configuration, and content records live in different places. Duplicator collects the site data into one deployment package and supplies a PHP installer that knows how to unpack and configure it at the destination.

The archive contains the site data; installer.php launches the process that deploys it. The installer workflow is divided into deployment, database installation, data updates, WordPress configuration, plugin activation and settings, and a final test-site stage, as documented in Duplicator’s installer guide.

#1 Best Overall

How to Migrate Your WordPress Site with WordPress Duplicator Plugin: Duplicator is a free and powerful WordPress plugin, with over 25 million downloads. Duplicator successfully gives WordPress users.

$7.00

Buy on Amazon

Check compatibility and access first

Confirm the source and destination environments before creating a package. Duplicator’s published requirements are the baseline for a supported migration.

For the full, version-specific list, consult Duplicator’s system requirements. Record the current site’s domain, administrator login, database host conventions, PHP version, and any special services such as object storage, mail delivery, payment callbacks, or external APIs. You will use that inventory when testing the copy.

Access you should have

• Administrator access to the source WordPress dashboard so you can install and activate Duplicator and create a package.
• FTP, SFTP, or the destination host’s file manager so you can upload the archive and installer.
• Permission to create or identify a destination database, database user, and password.
• Ability to open the destination domain or temporary host URL in a browser.
• A way to change DNS later, after the restored site has passed testing.

Prepare the destination directory and database

Create the destination site or identify the directory that will serve the new domain. When using the classic package installer, a host migration guide recommends creating the destination without preinstalling WordPress; the package supplies the WordPress files and database instead. Follow the host’s instructions if it requires a particular document root or database naming convention. The destination database can be empty, but it must exist and the database user must have the privileges needed for installation.

Do not confuse the classic package process with Pro Import Install. Import Install is designed to replace an existing WordPress site, so its destination already contains WordPress and its data will be overwritten after you confirm the operation.

Choose the right Duplicator route

There are two practical workflows. Selecting the correct one prevents you from uploading files manually when you do not need to, or accidentally overwriting a live site.

The classic route gives you the clearest separation between the old and new sites: restore into a new directory, test it, then point DNS to it. Import Install is quicker when the destination is already running WordPress, but the overwrite decision is irreversible unless you have a separate backup.

Classic migration: complete step-by-step procedure

1. Install Duplicator on the source site

1. Sign in to the source WordPress dashboard.
2. Install and activate Duplicator from the normal Plugins screen. The free Duplicator Lite edition is listed in the WordPress.org plugin directory; Pro provides additional commercial features.
3. Open Duplicator’s package or backup screen and start a new package.
4. Let the package scan complete. Read any warnings about files, database tables, or server limits before proceeding. Resolve a blocking warning rather than assuming the archive is complete.
5. Build the package and wait for the archive and installer to finish. Do not close the browser or delete the package while it is still being assembled.

A package is a migration backup, so keep an independent copy until the new site has been verified. The package itself is not a substitute for a tested recovery plan if the source site is still receiving orders, comments, form submissions, or other live data.

2. Download both required files

Download installer.php and the archive generated by the package. The archive normally ends in .zip; if the DupArchive engine was selected, it may be archive.daf. Download both files to a local computer before touching the destination. If one file is missing, the installer cannot restore the site.

Use a reliable connection and check the local file sizes against the values shown by the host or file manager. A partial archive can upload successfully yet fail during extraction, which is harder to diagnose after the old site has been taken offline.

3. Create the destination database

1. In the destination hosting panel, create a database or select the database assigned to the new site.
2. Create a database user, set a strong password, and grant the privileges required by the host.
3. Record the database name, username, password, and database host. The host value is not always localhost; use the value supplied by the hosting provider.
4. Confirm the destination directory associated with the new domain or temporary URL.

Do not import the old SQL dump separately when using the Duplicator package installer. The package contains the database data and the installer handles the database installation stage.

4. Upload the installer and archive

1. Connect with FTP, SFTP, or the host file manager.
2. Open the destination document root—the directory that will answer for the new site.
3. Upload installer.php and the matching archive into that directory.
4. Wait for each upload to finish. Large archives can require substantially more time than the small installer file.

The files should be side by side. If the archive is in a subdirectory while the installer is in the document root, the installer may not find it automatically; move both into the same intended deployment directory before continuing.

5. Open the installer

In a browser, visit the destination URL followed by /installer.php, for example https://new-example.test/installer.php. Use the temporary host URL if DNS still points to the old server. The classic procedure and its browser stages are documented in Duplicator’s Classic Installation guide.

The first screen checks the package and server conditions. Read the status messages, expand warnings, and correct a problem that prevents the installer from continuing. Do not start the deployment in a directory that contains an unrelated live WordPress site unless you have intentionally chosen to replace it and have a separate backup.

6. Enter and validate the destination database

1. Choose the database installation option offered by the installer.
2. Enter the destination database host, name, username, and password you recorded earlier.
3. Run the installer’s connection or validation check.
4. If validation fails, recheck every character, confirm that the database user has access to that database, and ask the host whether a nonstandard database host value is required.
5. Proceed only after the installer can connect and the selected database is the one intended for the new site.

A database connection test proves that the credentials work; it does not prove that the destination site is ready for public traffic. You still need to complete the data update and configuration stages and test the restored site.

7. Set the destination URL and review replacement settings

If the domain is changing, enter the final domain in the installer’s URL or search-and-replace settings. If the domain is staying the same but the site is moving hosts, verify that the URL shown is still correct. Review the path, protocol, and any configuration options before applying them.

For a domain change, use the final HTTPS URL only when the destination certificate is ready. If you must test on a temporary URL, keep track of the temporary address and complete the final URL update before launch. Check both the home URL and the site URL values because a mismatch can send administrators or visitors back to the old address.

8. Complete data updates, WordPress configuration, and plugins

Continue through the installer’s data-update stage, then review the generated WordPress configuration. The installer also provides stages for plugin activation and settings. Let each stage finish and read its result instead of navigating away as soon as the files appear.

Some plugins depend on the domain, server path, PHP version, scheduled tasks, or external credentials. A successful package extraction does not guarantee that every integration will work unchanged. Make a note of any plugin that reports an activation or configuration error and handle it during testing.

9. Test the restored site before changing DNS

Open the site using the destination or temporary URL and test the parts that matter to its audience and business operations.

• Load the home page, several pages, posts, categories, search results, and a 404 page.
• Open images, downloadable files, galleries, and other media from the uploads library.
• Sign in as an administrator and confirm that the dashboard, editor, menus, widgets, and theme customizer work.
• Submit every important form and verify that the expected notification or stored entry is produced.
• Test user registration, password reset, checkout, membership, or other account workflows if the site uses them.
• Check redirects, canonical links, internal links, navigation menus, and links in widgets or reusable blocks.
• Verify analytics, search tools, advertising tags, webhooks, API keys, cron-driven jobs, and transactional email integrations.
• Inspect the browser address bar and page source for old-domain references, mixed HTTP/HTTPS content, or requests still pointing at the old host.

Keep the old site available while these checks run. New submissions or orders made on the old site after the package was created will not automatically appear in the restored copy, so plan a short content freeze or a final synchronization for sites with active data.

10. Remove migration artifacts after success

After you have confirmed the restored site and decided it is the one visitors should use, delete installer.php and the archive from the destination server. These files contain or expose migration material and should not remain in a publicly reachable directory. Retain a protected, offline copy of the archive only if you need it for recovery, and keep it outside the web root.

Moving to a new domain without broken URLs

A host move keeps the domain but changes the server. A domain move changes the address stored throughout WordPress content and configuration. Treat the second case as a URL migration, not just a file transfer.

Use a controlled test address

Restore the package in the destination directory while the old domain still serves the original site. Use a temporary host name or a hosts-file test arrangement supplied by your administrator so you can inspect the new copy privately. Avoid changing public DNS until the new copy passes the functional checklist.

Apply the new URL in the installer

Enter the final domain in the installer’s URL and search-replace settings. Include the correct protocol and any path component. For example, moving from a site installed at the web root to a site installed in a subdirectory is a different path update from changing only the domain name.

After the update, inspect menus, buttons, media URLs, embedded content, redirects, forms, and plugin settings. Content inserted by themes or plugins can contain URLs that are not visible on the home page. Search the database or use the installer’s update result to identify references that still use the old address.

Plan the DNS cutover

1. Lowering DNS time-to-live in advance can reduce how long different visitors reach different servers, but the timing depends on the DNS provider’s actual caching behavior.
2. Complete the final content and order freeze on the old site.
3. Repeat the highest-risk tests on the destination copy.
4. Change the domain’s DNS records to the new host.
5. Monitor both sites during propagation and preserve the old server until traffic is consistently reaching the destination.
6. Configure redirects from the old URL structure when the domain or permalink structure changed.

Do not delete the old site immediately after changing DNS. DNS caches can keep the previous address in use for some visitors, and a rollback is much easier while the original installation remains intact.

Using Duplicator Pro Import Install

Pro Import Install is an alternative to the classic upload-and-installer route. It accepts a local archive or a URL pointing to an archive and can replace an existing WordPress site. Duplicator states that the feature requires a Basic-or-higher Pro license and is not available in Lite; see the Import Install documentation for the current workflow.

When Import Install is appropriate

• The destination already has WordPress installed and you want the package to replace it.
• You prefer selecting an archive from the destination dashboard or supplying its URL instead of uploading installer.php manually.
• You have confirmed that the existing destination data is disposable or backed up.

Safe Import Install sequence

1. Verify that the destination runs a compatible PHP, WordPress, and database environment.
2. Take a separate backup of the existing destination site, even if you believe it contains nothing important.
3. Open Duplicator Pro’s Import Install feature on the destination.
4. Select the local archive or provide the archive URL, then wait for the package validation to finish.
5. Review the database settings and destination URL presented by the importer.
6. Confirm the overwrite only after checking that the selected database and site are the intended targets.
7. Allow the import, data updates, configuration, and plugin stages to complete.
8. Sign in and run the same page, media, form, integration, and URL checks used for a classic migration.

The key distinction is the destination state: Classic Installation deploys into a directory you prepare, while Import Install is explicitly an overwrite workflow. If you are uncertain which site will be replaced, stop before confirmation and verify the domain, database, and backup.

Troubleshooting common migration failures

The installer URL returns a 404 or the host’s default page

Confirm that installer.php is in the document root associated with the URL you opened, not in a parent folder or a different site directory. Check the exact file name and open the destination URL with the correct protocol. If the domain still resolves to the old host, use the temporary destination URL or a private hosts-file test instead of assuming the upload failed.

The archive is not detected

Place the archive beside installer.php and verify that the extension matches the package you created: .zip or .daf. A truncated upload should be deleted and uploaded again. Do not rename an archive to a different extension.

Database validation fails

Re-enter the database name, user, password, and host without extra spaces. Confirm that the user is assigned to the selected database and that the host permits connections from the web server. If the host uses a database server name other than localhost, use the value shown in its control panel or documentation.

The installer stops during extraction or data updates

Check the destination PHP version against Duplicator’s requirements and confirm that the server uses a 64-bit operating system and 64-bit PHP build. Review the installer’s error text and the host’s PHP or web-server logs. Large packages may also expose hosting limits; ask the host whether the account has sufficient execution time, memory, storage, and upload capacity before retrying.

The site loads but points to the old domain

Recheck the destination URL and search-replace values used during installation. Inspect menus, media, widgets, theme settings, forms, and plugin configuration for old-domain references. Test both logged-in and logged-out views, because administrator screens and cached public pages can use different settings.

A plugin or integration fails after restoration

Confirm that the plugin is active and that its settings survived the migration. Re-enter credentials for services that bind access to a domain, IP address, callback URL, or server path. Test email delivery, scheduled jobs, webhooks, payment callbacks, and analytics separately instead of treating a working home page as proof that integrations are healthy.

You discovered a serious problem after cutover

Keep the old site available for rollback, point DNS back if necessary, and preserve the destination logs and package for diagnosis. If the destination database was overwritten through Import Install, restore the independent destination backup rather than trying to reconstruct the previous contents from memory.

Final migration checklist

• Source and destination meet PHP, WordPress, architecture, and database requirements.
• Both installer.php and the correct archive were downloaded and uploaded completely.
• The destination database credentials were validated against the intended database.
• The destination URL and any domain-change replacement settings were reviewed before applying them.
• Pages, posts, media, navigation, search, 404 handling, logins, and administrator tools work.
• Forms, email, orders, memberships, scheduled tasks, redirects, APIs, analytics, and other critical integrations were tested.
• DNS was changed only after the destination passed testing and a rollback plan remained available.
• The installer and archive were removed from the public server after the migration was confirmed.

For the classic workflow, the authoritative sequence is summarized in Duplicator’s Classic Installation documentation. For the plugin’s broader package-and-restore lifecycle, see the documented plugin workflow. Together, these steps let you move a WordPress site with a controlled handoff rather than treating a file upload as the entire migration.

Quick Recap

Bestseller No. 1

How to Migrate Your WordPress Site with WordPress Duplicator Plugin: Duplicator is a free and powerful WordPress plugin, with over 25 million downloads. Duplicator successfully gives WordPress users.

$7.00

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.