WordPress.org announced Reprint on November 13, 2026: a free, open-source tool that copies a WordPress site’s files and database straight to another server. If your migration plugin keeps timing out while it builds a giant archive on a slow shared host, this is worth a look.
The old host never builds a full-site archive. A small plugin on the source serves the files and database over HTTPS, and a command-line client on the new server pulls them. Interrupted copies resume, and if you pass a new site address, it rewrites the old URLs, including the ones in serialized data.
I am following the official Move to another host guide here, with the server parts filled in.
Check what each server needs
The source site only needs an administrator account. You do not need SSH on the old host. The Reprint plugin works on WordPress 4.7 or newer with PHP 5.6.20 or newer.
The destination needs command-line PHP 7.4 or newer, an empty database, and control over its web server configuration.
As of 2026-11-14 the plugin is at version 0.11.8 and was published at the end of October. It is new software, so I would not delete a single backup because of it. Keep your usual backup routine until it has a longer track record.
Step 1. Back up the source site
Reprint only reads from the source, but the move ends with a DNS switch and you want a rollback point that does not depend on any tool. Take a normal file and database backup first. If your backup plugin hangs on the database, export it with WP-CLI as shown in Backup stuck on the database.
Step 2. Create an empty database on the new host
Reprint imports into a database that already exists and is empty. Use a new user and password here. The guide says not to reuse the old host’s database credentials.
mysql -u root -p
CREATE DATABASE site_database CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site_user'@'127.0.0.1' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON site_database.* TO 'site_user'@'127.0.0.1';
FLUSH PRIVILEGES;Each statement should answer with Query OK. The user needs rights to create, change and drop tables, because the import can replace existing tables.
On a control panel you do this in the GUI instead. In OpenPanel it is MySQL > Databases > New database, where names can use letters, numbers and underscores. In cPanel it is the MySQL Databases page or the Database Wizard. Both panels also let you pick the PHP version per domain, which is a good moment to match the source or go newer. Keep in mind that the host guide assumes you control the web server config, so on panel hosting check where your domain’s document root lives before Step 5.
Step 3. Download the client on the new server
curl -fL https://plugins.svn.wordpress.org/reprint/downloads/reprint.phar -o reprint.phar
php reprint.phar --versionThe second command should print the client version. If it fails, check php -v first, since the client needs PHP 7.4 or newer on the command line, then go through the troubleshooting page in the Reprint handbook.
Step 4. Generate a key and authorize it on the old site
On the source site, go to Plugins > Add New Plugin, install and activate Reprint. Activating it does not start anything. Then create a key on the new server:
php reprint.phar keygen https://source.example \
--state-dir=/srv/reprint-state --out=/srv/reprint-key.pemThe client prints a Migration Token. In the old site’s admin, open Tools > Reprint Server, find Authorize a client to copy this site, paste the token into the Migration Token field and click Authorize client.
Keep reprint-key.pem and the state folder private. The state folder holds credentials.
Step 5. Pull the site into place
This is the command from the host guide. Replace both addresses and the database details with your own:
php reprint.phar pull https://source.example \
--private-key-path=/srv/reprint-key.pem \
--state-dir=/srv/reprint-state --fs-root=/srv/reprint-files \
--flatten-to=/srv/site \
--target-engine=mysql --target-host=127.0.0.1 \
--target-user=site_user --target-pass=YOUR_DATABASE_PASSWORD \
--target-db=site_database --new-site-url=https://destination.example \
--runtime=none --start-runtime=noneThe downloaded files land in /srv/reprint-files. /srv/site links to them and is the one folder your web server serves. The two none flags skip Reprint’s built-in development server, because nginx or Apache will serve the site.
💡 Do not delete /srv/reprint-files after the copy. The guide is explicit that removing it breaks the site in /srv/site.
If the connection drops, run exactly the same command again. It resumes from the last saved point instead of starting over.
Step 6. Point the web server at the copy and test it
A minimal nginx server block for the new site looks like this:
server {
listen 80;
server_name destination.example;
root /srv/site;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
}Change the socket path to your PHP-FPM version, run nginx -t (it should report that the syntax is ok and the test is successful) and reload nginx. Add SSL before going live. If PHP-FPM restricts paths with open_basedir, allow /srv/reprint-files as well, since the site folder points into it.
If the domain stays the same, test before DNS changes by pointing it at the new IP in your own hosts file:
203.0.113.10 destination.exampleThen check what the Reprint guide checks: the home page opens, internal links stay on the copy, images load and /wp-admin/ lets you sign in. Other ways to preview are in accessing WordPress using a temporary server URL.
Step 7. Do the final pull and switch DNS
The source keeps serving visitors during a copy, so new orders, comments and posts keep arriving. When the test copy looks right, pause changes on the old site, run the same pull once more, and only then point the domain at the new server.
That last pull is not a merge. The database is imported again and replaces whatever you changed on the destination, so do not fix content on the new server between the test and the final pull. File copies are incremental, so the second run is faster.
Reprint does not touch DNS and does not delete the source. Leave the old site running for a few days as your rollback.
Step 8. Revoke access on the old site
Once the move is done, remove the Migration Token under Tools > Reprint Server. Deactivating the plugin keeps its settings. Deleting it through WordPress removes the stored settings and credentials, which is what I would do on a site you are leaving anyway.
When the pull stops with an error
The client reports error codes, and the troubleshooting page has a fix for each. The ones I expect to see most on shared hosting:
AUTH_UNKNOWN_KEY: the key was never authorized. Paste the token under Tools > Reprint Server again.AUTH_HEADERS_STRIPPED: the host drops custom HTTP headers before they reach WordPress. Only the host can change that.CLOUDFLARE_CHALLENGEorWORDFENCE_BLOCKED: a firewall stopped the client. Reprint cannot solve a Cloudflare browser challenge, so allow the Reprint API address for the duration of the move.REDIRECT: use the exact address the message names, with the right scheme andwwwform.SERVER_ERROR: look in the source site’s PHP error log.
Do not delete the state folder as a first step. It is what lets the next run resume.
A few limitations from the handbook are worth knowing before you start. Files PHP cannot read because of open_basedir are reported and left out. MySQL 5.5 works as a source but not as a destination. Caches, logs and backup archives are skipped on purpose. Mail, payment and scheduled job settings in the copied database still point at the live accounts, which matters if you pull a copy for staging instead of a move.
TL;DR: Install Reprint on the old site, run keygen on the new server and authorize the token under Tools > Reprint Server, then pull into an empty database with --flatten-to and point nginx at that folder. Test through your hosts file, do one final pull with the old site paused, switch DNS and revoke the token. If you are also changing the domain by hand later, my domain change guide covers the other ways.
