Duplicator WordPress Migration: A Step-by-Step Walkthrough

Build a package on your old site, deploy it on the new one with installer.php, and migrate any WordPress site by hand. No host lock-in, and no WordPress required on the destination.

How Duplicator migrates a WordPress site

Duplicator bundles a whole site into one thing it calls a package. A package is two files. One is the archive, which holds all your files plus the database. The other is installer.php, a standalone script that rebuilds the site once you open it in a browser. The installer carries everything it needs, so the destination never needs WordPress sitting there first. That one fact is why people reach for Duplicator on manual moves, and why it is the cleanest way I know to push a local build up to a live host (WordPress.org).

I have spent years moving WordPress sites for clients, and the thing nobody warns you about packaging tools is the size wall. They sing on a small site. Then you point one at something big and the build chokes. I felt that firsthand on Sportsnet.ca, where I was Lead Developer for the final stages of a move onto WordPress. Hundreds of sports articles, all the media that rides along with them, and a single archive that did not want to finish. That experience is woven through this whole walkthrough, because most of what trips people up with Duplicator is exactly the stuff a big site exposes.

A bit of housekeeping. Duplicator is a registered trademark of Snap Creek LLC, now part of the Awesome Motive family. This walkthrough sticks to the free version end to end. Build the package, upload it, run the installer, wire up the database, finalize. Do that and you have moved a site by hand, in full control of every step.

New to this? Read the complete WordPress migration guide first. Still weighing tools? The best WordPress migration plugins roundup shows where Duplicator slots in, and the All-in-One WP Migration guide covers the simpler dashboard-only route.

Before you start: what you need

This move pokes at files and a database directly. Have a few things on hand before you start.

• FTP/SFTP access to the destination host. An FTP client like FileZilla works, or the host’s file manager.
• A database on the destination. Most hosts spin one up through cPanel or their own control panel. You will need its name, username, password, and host.
• Enough server resources on the source to build the package. The free version does the work on your own server, so very large sites can time out.

Run a free pre-migration audit first. It sizes the site and flags broken links before any of this. And if the package build keeps dying on a big site, do not file that under nuisance. It is telling you something. The work has outgrown an on-server tool, and you want an off-server option instead. The plugin comparison covers those.

Step 1: Build the package on your old site

Think of the package as your whole site squeezed into one portable bundle.

1. On the source site, install and activate Duplicator from Plugins > Add New.
2. Go to Duplicator > Packages and click Create New.
3. Name the package. Use the filters here to drop files you do not need, like caches and oversized media, or to skip database tables.
4. Click Next. Duplicator runs a scan that checks your server for trouble before it builds anything. Large files, oversized tables, settings that could break the build. Clear any warnings it raises.
5. Click Build. Duplicator assembles the package and hands you two downloads.

The two files you get

The build leaves you with two downloads. The Archive is one file holding every site file and the full database. The Installer (installer.php) is the deploy script you run on the destination. Grab both. They have to travel together to the new host.

Why the scan step matters

Do not skip the scan. Seriously. It is the line between a clean deploy and a half-broken one. Most Duplicator failures trace back to three things the scan catches early. Files too big for the plugin to package comfortably. Database tables that are bloated or sitting on an odd collation. PHP memory and execution-time limits set too low to finish the build on your server. A warning is not a wall. It is a heads-up while you still have a working source site, which beats finding out after the deploy face-plants on the destination.

Package size is the quiet killer here, and I have wrestled it more than once. On the Sportsnet.ca move, the raw weight of hundreds of articles and their attached media is what made one clean archive so hard to produce. The build would crawl, hit a server limit, and die partway. I fought it by stripping out what did not need to travel and pushing the PHP limits up, and even then the slowest part of the whole job was just waiting for the package to finish. Push past a single big site and the math gets worse. When I worked on migrating Postmedia’s network of newspaper blogs, a one-shot package was never even on the table, because no single archive was going to swallow that much content across that many publications. Same takeaway at any size. Trim hard before you build. If the site is genuinely large, treat the build as the bottleneck and plan the timing around it rather than hoping it flies through.

Step 2: Upload both files to the destination

Both files go to the destination, in the directory where the site will live. That is usually public_html or a subfolder under it.

1. Connect to the destination host with your FTP client or open its file manager.
2. Navigate to the target directory, the document root where you want WordPress to run.
3. Make sure the directory is empty (or holds only a fresh, removable WordPress install). Duplicator deploys into this folder.
4. Upload the archive file and installer.php into that same directory.

Here is the mistake people make. They unzip the archive first. Don’t. The installer reads it as-is, so an already-extracted folder breaks the deploy.

Step 3: Create an empty database on the new host

The installer needs somewhere to drop your data, and that somewhere is a database you create. On most hosts it is a one-minute job in cPanel.

1. In cPanel, open MySQL Databases (or your host’s equivalent).
2. Create a new, empty database and note its exact name.
3. Create a database user with a strong password, and note both the username and password.
4. Add the user to the database and grant it All Privileges.

That is the four values the installer will ask for. Host, database name, username, password. On most shared hosts the host is just localhost.

Step 4: Run installer.php and deploy

Now the package turns into a live site.

1. In your browser, go to your-new-domain.com/installer.php (adjust the path if you uploaded to a subfolder).
2. The Duplicator installer loads and runs a set of validation checks. Accept the terms and continue once they pass.
3. In the Setup / database step, enter the credentials from Step 3. That is your Host (often localhost), the Database name, the User, and the Password.
4. Click Test Database to confirm the connection, then continue. The installer extracts the archive and imports your data into the new database.
5. It detects the new URL and path on its own, running a search-and-replace across the database so internal links resolve to the new domain.
6. When the deploy finishes, click Admin Login to get into the migrated site.

That is it. Your site is live on the new host with all content, media, themes, and plugins in place.

What the installer is doing behind the scenes

Knowing the order helps when something breaks. The installer runs three jobs in sequence. First it extracts the archive into the directory. Then it imports the database dump into the empty database you supplied. Last it rewrites the old site URL and file paths to the new domain across the whole database, reaching inside serialized data so plugin and theme settings keep working. If the deploy stalls, the step it died on points you straight at the cause. An extraction failure means file permissions or disk space. An import failure means the database credentials. A URL-replace warning means oddly structured serialized data, and that one you can finish cleaning up after you log in.

Step 5: Finalize and remove the installer files

Two steps stand between you and a finished move, and both matter for security. Pull the installer files off the server. Leaving installer.php sitting on a public host is a genuine risk, not a formality.

1. After you log in, Duplicator pops a prompt to remove the installation files. Click it.
2. Confirm the archive, installer.php, and any leftover Duplicator deploy files are gone from the directory. Check via FTP if you are not sure.
3. Go to Settings > Permalinks and click Save Changes to flush the rewrite rules.
4. Now click through the site. Homepage, a few posts, your forms, the checkout if it is a store. Make sure the thing actually works.

Duplicator free vs Pro: do you need to pay?

Short answer, probably not. Duplicator Lite runs a complete one-time migration for free. What you pay for is automation and scale, nothing more. The table lays out the split (Duplicator).

Moving one modestly sized site once? Lite is plenty. Migrate sites for a living, want cloud backups, or pushing something large? Pro earns its keep. There is also a ceiling where neither tier is the answer, and it is worth naming. A packaging plugin is the wrong tool the moment the package itself stops being something you can reliably build and move. I hit that hard line on the Postmedia newspaper blogs. Bundling that volume into one archive and shoving it across was never realistic, so the whole approach had to change before a single post moved. You feel it on smaller jobs too, just earlier on a big one. For very large or genuinely awkward sites, weigh an off-server tool like Migrate Guru in the plugin comparison, and be honest with yourself about when the job has simply outgrown what any plugin can do.

Common Duplicator problems and fixes

A handful of snags show up again and again. Here are the usual ones and how to clear them.

The package build fails or times out

Blame the on-server build. The free version runs on your box, so large sites blow past memory or execution limits mid-build. This is the failure I have fought most often on heavy sites, the Sportsnet.ca archive included, and the fix order rarely changes. Trim files in the package filters first. Then bump your PHP max_execution_time and memory_limit. If it still dies, stop bending the plugin and move to a tool that builds off-server.

installer.php shows a database connection error

Go back to the four credentials and read them again. Nine times out of ten it is a wrong database host, so try localhost or whatever specific host your provider lists. Then confirm the user is actually attached to the database with full privileges.

The site loads but links point to the old domain

A serialized value slipped past the search-and-replace. Re-run the installer’s URL update, or point a search-and-replace plugin at the new site to mop up the leftover references.

404s on every page except the homepage

Classic. The rewrite rules need a flush. Go to Settings > Permalinks and click Save Changes.

A free pre-migration audit up front catches a lot of this before it ever bites.

When to hand the migration off

What Duplicator hands you is full manual control. That suits developers, and it suits any move where you own the destination file system. Small to mid-size site, confident operator? This walkthrough is the whole job.

Manual control cuts both ways, though. Everything is now on you. Building the package, setting up the database, the URL rewrite, the DNS cutover, the QA afterward, the cleanup. One slip on a live site and you are looking at downtime. For a store, a site that feeds you leads, anything the business actually runs on, a managed WordPress migration handles the full sequence with a tested rollback, so a botched deploy never reaches a single visitor.

Straightforward move? Work the five steps above and you are done. Mission-critical? Have it handled for you, and kick off with a free pre-migration audit so you know exactly what you are carrying across.

Frequently asked questions

What is a Duplicator package?

It is your entire WordPress site boiled down to two files. One archive holds all your files and the database. One standalone installer.php script rebuilds the site on the destination. Move both together and you have migrated.

Do I need WordPress installed on the destination to use Duplicator?

No. The installer.php script is self-contained and deploys the whole site into an empty directory. That is exactly why Duplicator works for fresh hosts and local-to-live moves where dashboard-import plugins fall flat.

Is Duplicator free?

Yes. Duplicator Lite is free on WordPress.org and handles a complete manual migration. Duplicator Pro, from $49.50/year, piles on scheduled backups, cloud storage, server-to-server transfers, drag-and-drop installs, and multisite support.

How do I run the Duplicator installer?

Upload the archive and installer.php to the destination directory. Then visit your-domain.com/installer.php in a browser, enter the destination database credentials, test the connection, and follow the steps to deploy.

Why must I remove the installer files after migrating?

Because leaving installer.php on a public server is a security risk, and the migration is not considered complete until it is gone. Duplicator prompts you to delete the installer and archive files once you log in.

Why does Duplicator fail on large sites?

The free version builds the package on your own server, so large sites can slam into PHP memory or execution-time limits. Cut unneeded files, raise your PHP limits, or hand the job to an off-server tool like Migrate Guru for the really big ones.