Introduction

A hosting migration can move FTP accounts and files successfully while FTPS passive connections still fail because the server advertises the old public IP. Authentication may work and the control connection may open, but directory listings, uploads, or downloads fail when the passive data channel still points clients to the previous server.

Treat this as a passive-address problem instead of a generic credential problem. Start by checking which public IP the destination FTP service advertises in passive mode, because the migrated server can be correct in every other way while still handing clients the wrong data endpoint.

Symptoms

  • FTPS login works, but directory listing or file transfer fails after migration
  • Clients connect, then hang when opening the data channel
  • Passive mode still references the old server IP
  • Some networks or FTP clients fail more often than others
  • The new host is live, but FTPS data connections behave as if the old server is still involved
  • The issue began after hosting migration, NAT change, or server move

Common Causes

  • The FTP service still advertises the old passive IP address
  • NAT or firewall rules were updated on the new host, but the FTP passive setting was not
  • The control panel restore copied account data without rebuilding passive-mode networking
  • The passive port range is correct, but the announced public IP still points to legacy infrastructure
  • A reverse proxy, firewall, or edge device still rewrites passive responses incorrectly
  • The migration validated login only and missed passive data-channel behavior

Step-by-Step Fix

  1. Test an FTPS session and capture the passive connection details so you can see which IP and port the server actually advertises, because transfer failures are often caused by the announced data endpoint rather than the login itself.
  2. Check the FTP service or hosting control panel configuration for the passive-mode public IP, because migrations commonly move accounts without updating the value the server returns to clients.
  3. Compare the advertised passive IP with the intended public address of the new server, because even a correct passive port range will fail if the client is told to connect to the retired host.
  4. Verify NAT, firewall, and edge-device mappings for the passive port range, because a corrected passive IP still needs to point at ports that are reachable on the new platform.
  5. Confirm whether any reverse proxy, firewall appliance, or upstream NAT device rewrites FTP control traffic, because that layer can keep inserting the old public IP after the server itself was fixed.
  6. Update the passive IP to the correct destination and retest with a clean FTPS client session, because saved session data can hide whether the server is still advertising legacy details.
  7. Compare results across more than one client and network after the change, because passive-mode failures often reveal themselves differently depending on NAT behavior and client defaults.
  8. Check server logs while testing the passive data channel, because matching the log entries with the advertised endpoint helps confirm whether the old IP reference is fully gone.
  9. Document the final passive IP, passive port range, and any NAT dependencies after recovery, because FTPS passive settings are easy to miss during future hosting migrations.