Moving a WordPress site to a new host means copying the whole web root, often including a wp-content/uploads folder with thousands of small media files. This guide shows how to set up FileZilla Pro so the transfer is complete and reliable, how to check that every file arrived, and how to recover from dropped connections without starting over.
Before you start
- Back up the database separately. Your posts, pages, users and settings are stored in the WordPress database, not in the files. Export it from the old host (for example with phpMyAdmin or
mysqldump) and import it on the new host. FileZilla Pro moves the files; the database needs its own export and import. - Get your login details for both hosts: hostname, username, password (or SSH key) and the protocol each host supports.
- Make sure you have enough local disk space to hold a full copy of the site, since you will download it first and then upload it.
Step 1: Choose the right protocol
Use SFTP whenever the host supports it. It encrypts your login and your files, and it runs over a single connection, which makes it more stable than FTP on networks with firewalls.
If SFTP isn’t available, use FTP with Require explicit FTP over TLS (FTPS). Avoid plain FTP: it sends your password unencrypted.
If you use FTP or FTPS:
- Make sure Passive mode is selected in Settings > Connection > FTP.
- Turn on Send FTP keep-alive commands to prevent idle disconnects during long queues.
Add both hosts to the Site Manager (File > Site Manager) so you can switch between them quickly. If you haven’t done this before, see How to connect to your WordPress site with FileZilla Pro.
Step 2: Configure FileZilla Pro for thousands of small files
Open Settings (Edit > Settings on Windows and Linux, FileZilla Pro > Settings on macOS) and change the following:
| Setting | Where | Recommended value | Why |
|---|---|---|---|
| Maximum simultaneous transfers | Transfers | 3–4 | Many shared hosts limit connections per IP. Going over the limit causes refused logins or temporary IP bans. |
| Timeout | Connection | 60–120 seconds | Gives busy servers time to respond instead of dropping the connection. |
| Maximum number of retries | Connection | 5 | Recovers automatically from short network interruptions. |
| Default transfer type | Transfers > FTP: File Types | Binary | Keeps every file byte-for-byte identical, including PHP files and line endings. |
Then turn on two options from the menu bar:
- Transfer > Preserve timestamps of transferred files: keeps the original modification dates, which makes the comparison in Step 5 reliable.
- Server > Force showing hidden files: makes sure dotfiles such as
.htaccessand.user.iniare listed and transferred.
You can also limit connections for a single site in Site Manager > Transfer Settings > Limit number of simultaneous connections. This is useful if one host is stricter than the other.
Step 3: Download the site from the old host
- Connect to the old host from the Site Manager.
- In the local pane (left), open an empty folder for the site.
- In the remote pane (right), open the WordPress web root: the folder that contains
wp-config.php,wp-admin,wp-contentandwp-includes. - Select everything in the web root, then drag it to the local folder (or right-click and choose Download).
Keep an eye on the queue pane at the bottom of the window. The Queued files, Failed transfers and Successful transfers tabs show the progress of the job.
Step 4: Upload the site to the new host
- Connect to the new host from the Site Manager.
- In the remote pane, open the web root on the new host (your hosting provider can tell you which folder this is).
- In the local pane, open the folder you downloaded to.
- Select everything, then drag it to the remote pane (or right-click and choose Upload).
Once the upload is complete, set the file permissions on the new host as described in Step 7.
Step 5: Check that every file arrived
FileZilla Pro has two features that make checking a large transfer quick:
- Directory comparison (View > Directory comparison) compares the local and remote panes by file size or modification time and highlights files that are missing or different. Turn on Hide identical files so only the problems are shown.
- Synchronized browsing (View > Synchronized browsing) keeps both panes in the same relative folder as you navigate. This makes it easy to check deep folders such as
wp-content/uploads/2023/05.
Because comparison works between the local and remote panes, check in two steps:
- After downloading: connect to the old host and compare it with your local copy.
- After uploading: connect to the new host and compare it with your local copy.
At the end, the Failed transfers tab should be empty.
Tip: Directory comparison uses file size and timestamp, not checksums. For an extra check, if you have SSH access on both hosts, compare file counts with find . -type f | wc -l.
Step 6: Resume after interruptions
On a large job, a few files may fail because of timeouts or dropped connections. You don’t need to start over:
- Requeue failed files. Open the Failed transfers tab, select all files, right-click and choose Reset and requeue selected files. Then run the queue again with Transfer > Process Queue.
- Pick up where you left off. The queue is saved when you close FileZilla Pro and restored the next time you open it.
- Re-run a folder safely. If you transfer a whole folder again, set Settings > Transfers > File exists action to Overwrite if source newer or Overwrite if size differs. Only incomplete or changed files are transferred again.
Step 7: Set the right file permissions
Copying the files is not enough: they also need the right permissions, so that the web server can read and run them and WordPress can write where it needs to (for example, to wp-content/uploads when you add media or update plugins).
File permissions are not carried over in a transfer. Each file uploaded to the new host gets the server’s default permissions, which may differ from the ones on the old host. And if you downloaded the site to a Windows computer, the original permissions aren’t stored locally at all. So always check them on the new host after the upload.
To set permissions in FileZilla Pro:
- In the remote pane, right-click the web root folder and choose File permissions.
- Enter the numeric value for folders, select Recurse into subdirectories and choose Apply to directories only. Click OK.
- Repeat for files: enter the numeric value for files, select Recurse into subdirectories and choose Apply to files only.
- Set stricter permissions on sensitive files such as
wp-config.php.
The values most WordPress sites use are 755 for folders and 644 for files, but check with your hosting provider first: some servers require different values, and settings that are too open (such as 777) are a security risk and may even be blocked by the host.
Note: FTP and SFTP can change permissions, but not file ownership. Files you upload belong to the account you log in with. If WordPress still can’t write to its folders after you set the permissions, ask your hosting provider to check that the files are owned by the right user.
Frequently asked questions
Can FileZilla Pro transfer files directly from one server to another (FXP)?
No. FileZilla Pro doesn’t support FXP or direct remote-to-remote transfers, and FXP is disabled on most hosts for security reasons. Downloading and then uploading, as described in this guide, is the right approach.
Why is my transfer so slow when the site isn’t that big?
Every file has its own overhead, so thousands of small files take much longer than one large file of the same total size. If both hosts give you a control panel file manager or SSH access, you can compress the web root into a single archive on the old host, transfer that one file, and extract it on the new host. Then use Directory comparison to check the result.
Does FileZilla Pro move my WordPress database?
No. FileZilla Pro transfers files. Export the database from the old host and import it on the new one, then update wp-config.php with the new database details.
Should I increase the number of simultaneous transfers to go faster?
Only slightly. Three or four connections is usually the sweet spot. More connections can trigger the host’s connection limits and cause more failures, which slows the job down overall.