A classic WordPress migration with Duplicator is based on a simple package: a matching installer file and an archive containing the selected WordPress files and database data. After transferring both files to the destination server, you open the installer in a browser, connect it to the destination database and deploy the site.
The important decisions happen before and after the installation. A clean migration normally uses a new, empty directory, while an overwrite installation replaces the files and database already present at the destination. Back up the source site before starting, and create a separate backup of the destination if existing data may be replaced. A completed installer does not automatically prove that every page, form, URL or integration works correctly.
When to Use Duplicator’s Classic Migration Workflow
The classic Duplicator workflow is useful when you need to move a WordPress site to another host, server directory or destination environment. The process consists of creating or obtaining a package, transferring the matching installer and archive, opening the installer through the browser and providing the database connection details required for deployment.
The archive contains the selected WordPress files and a scripted copy of the database. During deployment, Duplicator extracts the files and executes the database script in the destination environment. This is why the installer and archive must remain together and why the destination database must be identified carefully before continuing.
Clean installation versus overwrite
For a clean classic installation, upload the package to a new, empty destination directory. Before launching the installer, that directory should contain only the matching installer and archive. This approach avoids treating unrelated destination files as part of the migration target.
An overwrite installation is different. It replaces the existing destination files and database data, so it should not be treated as a reversible test. Create a fresh backup of the destination before choosing an action that may remove or replace its data. The installation process itself cannot undo that replacement.
Prepare the Source Backup and Destination
Preparation reduces the risk of transferring an incomplete package or connecting the installer to the wrong database. First, retain a verified backup of the source site. Confirm that the installer and archive were created as a matching pair and can be downloaded or transferred together.
Next, determine the intended destination domain or path and identify the database connection details that the installer will need. The database host, database name, user and password must belong to the destination intended for the migrated site. If the domain, site path, database name or database user will change, note those changes for the verification stage.
Pre-migration safety checks
Before uploading anything, decide which installation scenario applies:
- Use a new, empty directory for a clean classic installation.
- Back up the existing destination separately if its files or database may be replaced.
- Confirm the installation target and database before approving a deployment action.
- Keep database credentials, backup archives, installer URLs and logs out of public screenshots and examples.
Exact document-root behavior, permissions, hosting setup, database server and PHP configuration are environment-specific. When you are uncertain about the correct directory or server requirements, confirm them with the hosting provider rather than assuming that every environment behaves identically.
Which Duplicator Files You Need
A classic Duplicator migration uses two matching files. The first is the installer file, commonly named installer.php. The second is the archive created with that installer. The archive may use the .zip format or Duplicator’s .daf format, depending on the archive engine used to create it.
The archive contains the selected WordPress files and database data. It is not enough to transfer only the installer, because the installer needs the corresponding package to extract the files and restore the database. Likewise, do not combine an installer from one backup with an archive from another backup.
Installer and archive matching
Before beginning the transfer, check that the two files belong to the same backup:
- Keep the installer file and its corresponding archive together.
- Accept
.zipand.dafas possible archive formats rather than assuming that.zipis the only valid option. - Do not rename or substitute files in a way that makes it unclear which package the installer should use.
- Keep the package controlled during migration and plan to remove temporary files after verification.
The exact archive extension depends on how the backup was created. The file format alone does not establish that two files match, so validate the package relationship before uploading it.
Upload the Backup to the New Host
Transfer both matching files to an accessible directory on the destination server. FTP, cPanel or the hosting provider’s file manager can be used for this step. The correct document root depends on the hosting environment, so verify the intended location if the destination URL and server directory are not obvious.
For a clean installation, create or select a new, empty directory. Upload the installer and archive there, then check the directory before opening the installer. Unrelated files in the target can make it less clear whether you are performing a clean deployment or working with an existing site.
Verify the destination directory
Make the following checks before launching the browser-based installation:
- The files are in the intended destination directory.
- The directory is accessible through the destination URL that will be used to open the installer.
- A clean installation directory contains only the matching installer and archive before launch.
- You are not placing an overwrite installation in an unintended directory.
- The destination database selected for the installation is the correct one.
Permissions and document-root rules vary between hosts. If you cannot confirm that the uploaded files are in the directory served by the intended domain or path, stop and verify the setup before proceeding.
Run the Duplicator Installer
Launch the classic installer by opening its URL in a browser. For example, the destination domain may be followed by /installer.php. Run it only from the controlled location where you intentionally uploaded the matching files.
The workflow includes an environment validation step. Review the reported conditions before deployment, then enter or confirm the destination database host, database name, user and password. These details allow Duplicator to connect to the database that will receive the restored data.
Before confirming deployment, check the installation target and database one more time. This is especially important when the destination already contains a site or when the selected action may remove or replace existing tables. In an overwrite scenario, the destination files and database data are replaced; that action should be covered by the separate destination backup created beforehand.
Database connection and deployment confirmation
Use this sequence to keep the consequential decisions visible:
- Open the installer URL for the intended destination.
- Review the environment validation results.
- Enter or confirm the destination database connection details.
- Verify the database and installation target before continuing.
- Proceed through deployment only after confirming that replacement actions are intended.
During deployment, Duplicator extracts the archived WordPress files and executes the database script. Allow the workflow to complete, then move to functional verification instead of treating the completion message as the only test.
Post-Migration Verification, Cleanup, and Troubleshooting
After redeployment, verify the site from both the public and administrative perspectives. A migration can complete while a URL, rewrite rule, form or site-specific integration still needs attention. The checks below should be adapted to the functions that actually exist on the website.
Verification checklist after redeployment
Start by logging in to the WordPress administrator area and opening the public front end. Check important pages, media and forms, then review the site’s relevant functionality.
- Confirm that administrator login works.
- Open key front-end pages and inspect media.
- Submit important forms and check redirects.
- Review HTTPS behavior, internal links and media URLs.
- Test search and other functionality relevant to the site.
- For sites that use them, test ecommerce flows, email notifications, multilingual workflows, memberships, cron jobs, payment gateways and third-party integrations.
If the domain or path changed, verify the WordPress Address and Site Address settings. Also review redirects, canonical URLs, media references and custom rewrite rules. Duplicator should not be assumed to correct every third-party URL reference, plugin setting or integration automatically.
When pretty URLs return 404 errors, visit or save the WordPress Settings > Permalinks screen to refresh rewrite rules. If the server cannot write the relevant rewrite configuration, or if custom redirects are involved, those rules require separate review.
Cleanup and selected troubleshooting steps
Once the migrated site has been confirmed, remove temporary Duplicator files. This includes the installer, archive, installer backup files, logs and the dup-installer directory. Removing the Duplicator plugin alone does not necessarily remove these files. Leaving installer files accessible creates a security risk because the installation process could potentially be invoked again.
If the installer reappears or deployment reports an error, inspect the installation directory for unexpected files and review the install report and installer log. Database-transfer and archive-extraction errors may need investigation, as may object-cache, hosting or other server-specific conditions. These are troubleshooting areas, not universal explanations for every failed migration.
Do not switch traffic or disable the old site until the destination has passed the checks relevant to your website. Keep the source and destination backups available until you are satisfied that the transfer is complete.
A controlled WordPress site transfer follows a clear sequence: protect the source and, when necessary, the destination; keep the installer and archive matched; upload both files to the intended directory; verify the database target; run the installer; test the redeployed site; and remove temporary migration files. Domain changes, permalink behavior and hosting configuration may require additional review, while ecommerce, forms, email and third-party integrations need site-specific testing. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.