Duplicator is one of the most trusted WordPress migration plugins, and its approach is elegantly simple: it packages your entire site — files and database — into a single archive plus a small installer script, which you then deploy on the new host to recreate the site automatically. That package-and-deploy model gives you the control of a manual migration with most of the tedium removed, and it doubles as a way to clone or template a site. This guide walks through using it end to end.

You will learn how Duplicator works, how to build a package of your existing site, how to move that package and its installer to the new host, how to run the installer to deploy and reconnect the site, how the installer handles the database and URLs for you, and how to test before going live. By the end you will be able to migrate a WordPress site with Duplicator confidently, and understand exactly what it is doing at each step.

How Duplicator works

Duplicator’s model centres on two files it creates: a package (an archive containing your entire site — all files plus a dump of your database) and an installer script (a small PHP file that, when run on the new host, unpacks the archive and rebuilds the site). Together these two files are a complete, portable copy of your WordPress site that can be deployed anywhere.

This is essentially the manual migration process — copy files, move the database, reconnect, fix URLs — bundled into a package and automated by the installer. Instead of you moving files by FTP and importing the database by phpMyAdmin and editing wp-config.php by hand, Duplicator packages it all and the installer performs the deployment and reconnection for you, prompting you for the new database details and handling the URL search-and-replace automatically.

So Duplicator gives you the control and universality of a manual move — it works host-to-host regardless of the hosts involved, and the package is a genuine portable copy — with the manual labour removed. Understanding that the package is ‘your whole site in a file’ and the installer is ‘the thing that rebuilds it’ makes the whole process intuitive. The workflow is simply: build the package, move both files, run the installer.

Building the package

On your existing site, install and activate Duplicator, then create a new package. The plugin runs a scan (checking your site is ready to package and flagging anything unusual, like a very large size), and then builds the package — compressing all your files and dumping your database into the archive. When it finishes, you download two files: the archive package and the installer script.

For a smooth build, it helps to clean up your site first — remove unused plugins, themes, and old media — so the package is smaller and builds faster, and to be aware that very large sites may need Duplicator’s paid tier or may hit host resource limits during the build. For a typical site, the free version builds a package without trouble. Make sure both downloaded files (the archive and the installer) are saved, as you need both to deploy.

So building the package is a matter of running Duplicator on the old site and downloading the two resulting files. This package is also, usefully, a complete backup of your site at that moment — so building it gives you a safety net as well as a migration bundle. With the archive and installer in hand, you are ready to move them to the new host and deploy.

Moving the package to the new host

Next, place the two Duplicator files — the archive package and the installer script — into the destination directory on the new host, typically the web root where you want WordPress to live. You upload them via FTP or the new host’s file manager. Unlike a standalone WordPress migration, you do not upload a full WordPress installation here; Duplicator’s package already contains everything, and the installer will extract it.

You also need to create an empty database on the new host (with a user and password), just as in a manual migration, because the installer needs a database to deploy your content into. Note down the new database name, username, and password — the installer will prompt you for these to establish the connection, which is how Duplicator handles the wp-config reconnection automatically.

So the move step is: upload the archive and installer to the new host’s web root, and create an empty database ready to receive the data. This is lighter than a manual migration’s file upload, because it is just two files rather than a whole WordPress folder, and the database work is only creating the empty container — the installer does the import. With both files in place and an empty database ready, you run the installer to deploy the site.

Running the installer

To deploy, you run the installer script by visiting it in your browser at the new host — because your domain does not yet point there, you access it via the new host’s temporary URL or IP, or via a hosts-file entry. The installer launches a guided, step-by-step deployment: it validates the package, then asks for the new database details (name, username, password) you created, connects to that database, and imports your site’s data into it.

• Validation: the installer checks the package and the environment are ready.
• Database connection: you enter the new empty database’s name, user, and password, and the installer connects and imports your database dump.
• URL/path update: the installer detects or lets you confirm the new site URL and path, then updates them throughout the database automatically.
• Finalisation: it extracts your files, writes a correct wp-config.php, and completes the deployment.

The installer’s guided flow is what makes Duplicator so convenient: it performs the database import, the wp-config reconnection, and the URL search-and-replace — the three fiddliest parts of a manual migration — automatically, based on the details you provide. When it finishes, it typically prompts you to log in and remove the installer files for security, which you should do promptly. At that point your site is deployed and reconnected on the new host, ready to test.

How it handles the database and URLs

The reason Duplicator is safer than a naive manual migration is how its installer handles the two trickiest parts: the database connection and the URL search-and-replace. For the database, rather than you hand-editing wp-config.php, the installer takes the new database credentials you enter, imports your data into that database, and writes a correct wp-config.php pointing at it — eliminating the classic ‘database connection error’ from a typo, because the installer sets it up directly.

For URLs, the installer performs a proper search-and-replace across the database as part of deployment, updating the old site’s URLs and paths to the new location. Crucially, it does this in a way that handles WordPress’s serialised data safely, which is exactly the pitfall that trips up a naive manual find-and-replace. So the images-loading-from-the-old-host and links-pointing-back problems are handled for you.

So Duplicator automates precisely the steps most likely to go wrong in a hand migration — the reconnection and the URL fixing — and does them safely. This is why it is trusted for migrations: it gives the control and portability of a manual move while removing its two biggest sources of error. You still provide the new database details and confirm the URLs, but the plugin does the delicate work correctly, which is the whole value of using it over a purely manual approach.

Testing and going live

After the installer completes, test the deployed site on the new host before pointing your domain at it. Because your domain still resolves to the old host, use a hosts-file preview (mapping your domain to the new server’s IP) or the temporary URL to view and check the new site: click through pages and posts, confirm images and styling load, test internal links, forms, and logins. This catches anything the deployment did not handle perfectly, while the public still sees the old site.

Once the migrated site is confirmed working, go live by updating your domain’s DNS to point at the new host — changing nameservers or the A record — and keep the old host running through propagation so no visitor meets a gap. If you lowered your DNS TTL a day or two beforehand, the switch propagates quickly. Then re-verify on the live site, confirm email flows, and clear any caches.

Finally, once everything is confirmed stable and DNS has fully propagated — typically after a few days — retire the old host, and make sure you removed the Duplicator installer files from the new host for security. So a Duplicator migration finishes exactly like any migration: test privately, cut over via DNS, verify, and retire the old host last. Duplicator’s contribution is making the copy-and-reconnect middle of that process a clean, guided, two-file deployment rather than a manual chore — but the surrounding migration discipline of backing up, testing, and careful cutover remains yours to follow.

FAQs

How do I migrate WordPress with Duplicator?

Install Duplicator on your existing site and build a package (an archive of all files plus a database dump) and its installer script. Upload both files to the new host’s web root, create an empty database there, then run the installer in your browser: it imports the database, writes wp-config.php, and fixes URLs automatically based on the details you provide. Test the deployed site privately, cut over DNS, verify, and retire the old host last.

What does Duplicator create when migrating?

Two files: a package (an archive containing your entire site — all files plus a dump of your database) and an installer script (a small PHP file that rebuilds the site on the new host). Together they’re a complete, portable copy of your WordPress site. The package is also effectively a full backup at that moment, so building it gives you a safety net as well as a migration bundle.

Do I need to create a database for Duplicator?

Yes — create a new empty MySQL database (with a user and password) on the new host before running the installer, because the installer needs a database to deploy your content into. You note down its name, username, and password, and the installer prompts you for them, then imports your data and writes a correct wp-config.php automatically — which is how Duplicator handles the reconnection for you.

How does Duplicator handle URLs and the database connection?

Its installer automates the two fiddliest manual steps. It takes the new database credentials you enter, imports your data, and writes a correct wp-config.php (eliminating the typo-caused ‘database connection error’), and it runs a proper search-and-replace across the database to update old URLs to new — handling WordPress’s serialised data safely, which is exactly where a naive manual find-and-replace goes wrong.

Can Duplicator handle large WordPress sites?

The free version handles typical sites well, but very large sites may hit host resource limits during the package build or need Duplicator’s paid tier, which is built for larger sites. Cleaning up your site first (removing unused plugins, themes, and old media) shrinks the package and helps. For very large sites, a paid tier or a manual migration (no size limit) may be needed.

Do I still need to test after a Duplicator migration?

Yes. Duplicator automates the copy-and-reconnect, but you still verify the result: test the deployed site privately on the new host (via a hosts-file preview or temporary URL) before pointing your domain at it — checking pages, images, styling, links, forms, and logins. Also remove the installer files afterward for security. The surrounding migration discipline of backing up, testing, and careful cutover remains yours.

The bottom line

Duplicator makes a WordPress migration into a clean two-file operation built on a simple model: it packages your entire site — all files plus a database dump — into a single archive, and pairs it with a small installer script that rebuilds the site on the new host. That package-and-deploy approach is really the manual migration automated: instead of moving files by FTP, importing the database by phpMyAdmin, editing wp-config.php, and running a search-and-replace by hand, you build the package on the old site, upload the two files to the new host, create an empty database, and run the installer — which imports the database, writes a correct wp-config.php, and fixes the URLs for you, handling WordPress’s serialised data safely. Those are precisely the steps most likely to go wrong in a hand migration, which is why Duplicator is trusted: it delivers the control and host-to-host portability of a manual move while removing its two biggest sources of error.

The workflow is straightforward — build the package (which doubles as a full backup), move the archive and installer to the new host’s web root, create an empty database, and run the guided installer, then remove the installer files afterward for security. But Duplicator automates only the copy-and-reconnect middle of a migration; the surrounding discipline is still yours. Test the deployed site privately on the new host before pointing your domain at it, checking pages, images, links, forms, and logins; then cut over by updating DNS while keeping the old host alive through propagation (faster if you lowered your TTL beforehand); re-verify the live site and confirm email; and retire the old host only after a few stable days. Follow that, and Duplicator turns the fiddliest part of a WordPress move into a reliable, guided deployment while you keep the safeguards that make any migration safe.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Duplicator migrates WordPress via two files: a package (all files plus a database dump) and an installer script. Build the package on the old site, upload both to the new host’s web root, create an empty database, and run the installer — it imports the database, writes wp-config.php, and fixes URLs safely. Then remove the installer, test privately, cut over DNS, verify, and retire the old host last. It’s the manual migration, automated.