Introduction

A hosting migration can move the site and even preserve FTP logins while FTPS transfers start failing on directory listings, uploads, or downloads. That usually means the control connection works, but the new server cannot establish the encrypted data channel correctly.

Treat this as a passive-data and firewall problem instead of a generic credential issue. Start by confirming whether authentication succeeds and then focus on the passive port range, advertised host settings, and TLS-aware FTP server behavior on the destination host.

Symptoms

  • FTPS login succeeds, but uploads or downloads fail after migration
  • Directory listings hang or time out on the new host
  • The FTP client reports a data connection or passive mode error
  • Plain login works while encrypted transfers fail intermittently
  • Only some networks or FTP clients are affected after the move
  • The issue started immediately after moving the site to a new server or hosting provider

Common Causes

  • The passive port range on the new FTP server is not open in the firewall
  • The FTP service advertises the wrong external hostname or IP after migration
  • NAT or provider firewall rules were not updated for encrypted FTP traffic
  • The FTP daemon’s TLS configuration changed during the move
  • A control panel restore recreated accounts but not the related FTP service settings
  • The destination server handles FTPS differently from the previous host

Step-by-Step Fix

  1. Confirm that the FTP account can authenticate and establish the control connection on the destination server, because a successful login narrows the issue to the FTPS data path instead of credentials.
  2. Test whether the failure happens on listing, upload, download, or all three actions, because that shows whether the data connection is failing broadly or only on a specific transfer flow.
  3. Review the passive port range configured on the new FTP server, because FTPS commonly breaks after migration when the server opens a data port range that the firewall does not allow.
  4. Verify that the destination firewall and hosting-provider network rules allow the configured passive ports externally, because the FTP daemon can advertise valid data ports that are still unreachable from the internet.
  5. Check which external hostname or IP the FTP service advertises to clients, because a migrated server that still announces the old address will fail to complete the FTPS data connection.
  6. Review the FTP daemon’s TLS and FTPS settings for changes introduced during the migration, because encryption mode differences between the old and new host can break data-channel negotiation even when login works.
  7. Test with one known-good FTPS client using passive mode and a clean session after each change, because cached address and TLS assumptions in the client can hide whether the server-side fix worked.
  8. Compare behavior from two external networks if the issue is intermittent, because provider firewalls, NAT behavior, or middleboxes can expose a passive-port problem only from certain paths.
  9. Record the final passive port range, external address, and FTPS mode used on the new server, because these settings are easy to miss during future hosting migrations.