How to move files directly between two hosts

Moving a website from one hosting account to another usually means downloading everything to your own computer and then uploading it again to the new account — two long transfers instead of one, with your own internet connection as the bottleneck for both. Some FTP clients can skip that middle step and copy files directly from one server to the other, which is worth knowing about if you are moving a genuinely large site.

Gather the details for both accounts

You will need the host, username, password and port for both the old hosting account and the new one. Get both sets ready before you start, from each account's own control panel — do not reuse a set of details from anywhere other than the account they belong to.

Set up both connections in your FTP client

Most clients that support this — FileZilla included — let you open a second connection in a separate tab or window while the first stays connected. Connect to your old host in one tab and your new host in another, so that both remote file listings are visible side by side rather than one of them being your own computer's local files.

Transfer directly between the two

1. Gather the login details for both accounts

   Host, username, password and port for the old account, and the same four values for the new one.

2. Open both connections in the same client

   Connect to the old host in one tab or window, and the new host in another, so neither side is your local computer.

3. Drag files from one remote panel to the other

   Select the files or folders on the old host and drag them across to the equivalent location on the new host. The client relays the data between the two servers, which is typically much faster than the same transfer routed through a home internet connection, since server-to-server bandwidth is usually far higher than a typical residential connection.

4. Check the new site before removing the old one

   Once the transfer finishes, browse the new host's file listing to confirm everything arrived, spot-check a few files by size, and test the site if it is already reachable. Only cancel or remove the old hosting once you are confident everything needed has copied across successfully.

If your client does not support this

Not every FTP client offers a true server-to-server transfer, and even when it does, some hosting firewalls block one server from being told to connect directly to another for security reasons — in which case the transfer falls back to routing through your computer regardless of the setting. If that happens, the fallback is the traditional two-step approach: download everything from the old host to your computer first, confirm the download completed properly, then upload it to the new host. Slower, but reliable, and worth doing in a single large batch using a zip archive rather than many individual files — see uploading a very large file for making that second leg efficient.

Transferring while the old site is still live

It is normal to run a server-to-server transfer while the old hosting account is still serving live visitors, since copying files does not change or remove anything on the source. Avoid deleting anything from the old account until after you have switched your domain over to the new one and confirmed it is working correctly — keeping the old copy in place costs nothing and gives you a fallback if something on the new host needs a second look before visitors are pointed at it.

An alternative for accounts with shell access

If both accounts offer SSH access, a tool such as rsync run from the command line can be considerably faster and more reliable for a large site than any FTP-based method, and it can resume cleanly if interrupted rather than restarting from the beginning. This requires more technical comfort than dragging files in a client, and is covered in using rsync to deploy.

Common issues during a server-to-server transfer

• The transfer stalls or times out. Some hosting providers rate-limit or block direct server-to-server FTP as a security measure — falling back to downloading and re-uploading is the reliable workaround.
• File permissions differ after arrival. The new host may apply its own default permissions rather than preserving the old ones exactly. Check that folders are 755 and files are 644 once the transfer is done — see changing file permissions if anything needs correcting.
• Hidden files were not copied. Confirm "show hidden files" is switched on in both connections before starting, so dotfiles like .htaccess are included in the transfer.