Introduction

A hosting migration can move files and FTP accounts successfully while an FTP client still opens the old server because the saved bookmark points there. Teams often assume the migration failed when the real issue is narrower: FileZilla, Cyberduck, WinSCP, or another FTP client is reusing an old hostname, saved IP, or inherited connection profile that never got updated after cutover.

Treat this as a saved-client-target problem instead of a general FTP outage. Start by checking the exact host value stored in the FTP client bookmark, because a migrated server can be healthy while users keep reconnecting to the legacy machine through an outdated saved profile.

Symptoms

  • FTP keeps opening the old server after hosting migration
  • Users see the old hostname, certificate, or directory structure in their FTP client
  • One manually entered connection works, but the saved bookmark keeps landing on the previous host
  • The website is already live on the new server, but file access still appears to hit legacy infrastructure
  • Different team members reach different servers depending on which saved profile they use
  • The problem started after server replacement, account transfer, or hostname cutover

Common Causes

  • The FTP client bookmark still stores the old hostname or IP address
  • The saved profile references a branded server name that still resolves to the old machine
  • Users kept an old site-manager entry and assumed it would follow the migration automatically
  • DNS behind the saved FTP hostname was not updated when the website moved
  • The old server still answers on the FTP service and makes the stale bookmark look valid
  • Migration testing used a fresh connection while daily users kept reusing old client profiles

Step-by-Step Fix

  1. Open the failing FTP bookmark and record the exact hostname, IP, port, and protocol it uses, because you need to verify what the client is actually trying to reach before changing server settings.
  2. Compare the saved host value with the intended new FTP endpoint, because many migrations fail only inside old site-manager entries rather than on the server itself.
  3. Check DNS for the saved FTP hostname if the bookmark uses a name instead of a raw IP, because the website and the FTP service do not always move behind the same hostname during hosting cutovers.
  4. Test a brand-new manual FTP connection to the intended new server, because that separates a broken bookmark from a wider FTP or credential problem.
  5. Review whether the old server is still publicly answering on the saved host and port, because a reachable legacy endpoint can mislead users into thinking the migration never completed.
  6. Update or recreate the saved FTP profile with the correct destination, then reconnect from a clean client session, because some FTP tools keep reusing cached connection details even after partial edits.
  7. Compare one updated bookmark with any shared team bookmarks or exported site-manager files, because outdated connection profiles often spread across multiple administrators.
  8. Confirm the login now lands on the expected new directory structure and not just a familiar username prompt, because the real fix is authenticated access to the destination host.
  9. Document the final FTP hostname, port, and shared bookmark source after recovery, because saved connection profiles are easy to miss during future hosting migrations.