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.
- A Duplicator package is two files — an archive holding your full site and database, and a standalone installer.php script — and the destination does not need WordPress pre-installed to use it.
- Run the pre-build scan and clear every warning before clicking Build; it catches oversized files, bloated tables, and PHP limit problems while you still have a working source site to fall back on.
- Never unzip the archive before uploading — the installer reads the compressed file as-is, and an already-extracted folder breaks the deploy.
- After the installer runs, delete installer.php and the archive from the server immediately; leaving installer.php on a public host is a genuine security risk, not a formality.
- The free version builds the package on your own server, so large sites can hit PHP memory or execution-time limits mid-build — trim unneeded files first, raise PHP limits second, and switch to an off-server tool like Migrate Guru if it still fails.
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 large content-heavy migrations onto WordPress. Hundreds of 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.
- On the source site, install and activate Duplicator from Plugins > Add New.
- Go to Duplicator > Packages and click Create New.
- Name the package. Use the filters here to drop files you do not need, like caches and oversized media, or to skip database tables.
- 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.
- 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 a big content migration, the raw weight of hundreds of articles and their attached media is what makes one clean archive so hard to produce. The build crawls, hits a server limit, and dies partway. Stripping out what does not need to travel and pushing the PHP limits up gets you through it, and even then the slowest part of the whole job is just waiting for the package to finish. Push past a single big site and the math gets worse. On a network of legacy blogs consolidating onto one platform, a one-shot package is never even on the table, because no single archive is going to swallow that much content across that many titles. 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.
- Connect to the destination host with your FTP client or open its file manager.
- Navigate to the target directory, the document root where you want WordPress to run.
- Make sure the directory is empty (or holds only a fresh, removable WordPress install). Duplicator deploys into this folder.
- Upload the archive file and
installer.phpinto 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.
- In cPanel, open MySQL Databases (or your host’s equivalent).
- Create a new, empty database and note its exact name.
- Create a database user with a strong password, and note both the username and password.
- 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.
- In your browser, go to your-new-domain.com/installer.php (adjust the path if you uploaded to a subfolder).
- The Duplicator installer loads and runs a set of validation checks. Accept the terms and continue once they pass.
- 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. - Click Test Database to confirm the connection, then continue. The installer extracts the archive and imports your data into the new database.
- 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.
- 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.
- After you log in, Duplicator pops a prompt to remove the installation files. Click it.
- Confirm the archive,
installer.php, and any leftover Duplicator deploy files are gone from the directory. Check via FTP if you are not sure. - Go to Settings > Permalinks and click Save Changes to flush the rewrite rules.
- 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).
| Capability | Duplicator Lite (free) | Duplicator Pro (from $49.50/yr) |
|---|---|---|
| Manual package build & migrate | Yes | Yes |
| Scheduled / automated backups | No | Yes |
| Cloud storage (Dropbox, Drive, S3) | No | Yes |
| Server-to-server transfer (no FTP) | No | Yes |
| Drag-and-drop install | No | Yes |
| Multisite support | No | Yes |
| Large-site reliability | Can time out | Stronger |
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. That is exactly the hard line a network of legacy blogs consolidating onto one platform runs into. Bundling that volume into one archive and shoving it across was never realistic, so the whole approach has to change before a single post moves. 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 content sites, 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
Is your site costing you customers?
Enter your website and get a free 60-second performance, SEO & accessibility report.
~60 seconds · No login