File Transfer Server Migration

Replacing an existing SFTP, FTP, or managed file transfer server means moving the exchanges that depend on it. IT needs to account for partner connections, staff access, application jobs, and files still awaiting collection. Files.com can provide the new endpoint while files move into native storage or remain on connected storage.

A data import, a client connecting to the new endpoint, and an application accepting a delivery are separate milestones. Plan the migration around complete exchanges so the old server can be retired with those dependencies accounted for.

Map the Exchanges Before Moving Them

For each active exchange, record who sends and collects files, the client or scheduled job they use, and the person responsible for changes. Recent server activity helps distinguish live connections from obsolete accounts, but include infrequent jobs and partners before deciding an unused account can be omitted.

Capture the connection hostname or fixed IP, protocol and port, trusted server key or certificate, username and authentication method, client-visible paths, and required operations. Include filename conventions, replacement and deletion behavior, schedules and time zones, retention, and the receiving application's acknowledgment. These determine what must stay compatible and what needs a coordinated change.

Treat server-side scripts and application processing as separate dependencies. Importing a folder does not recreate a job that transforms its files, sends them elsewhere, or deletes them after an application accepts them. Decide whether that work remains in an existing application or iPaaS platform, or becomes a Files.com Automation or Sync.

Choose Where the Files Will Live

Use native storage when Files.com should hold the working files. A Sync or the CLI can import existing content; Migration Assistance describes supported import methods and available assistance.

Use a Remote Server Mount when the files should remain on an existing cloud service or server. The Agent can connect on-premises storage. This changes the access endpoint without requiring a separate working copy, but the underlying storage and connection remain operational dependencies. If the Agent runs on the machine you intend to retire, move that dependency before shutting it down.

During a staged migration, avoid having two processes consume, replace, or delete the same files unintentionally. Assign one active processor to each exchange, even when both endpoints can reach its storage. For copied storage, define how changes made after the initial import reach the new location. Sync's name-and-size comparison does not establish identical contents; review same-name corrections and deletions explicitly.

Recreate Identity, Paths, and Access

Bulk User Import can create accounts with SSH public keys, Group or Partner assignments, and folder permissions. It can preserve passwords when the source supplies a supported password hash. If usable credentials cannot be imported, arrange new credentials with the client owner before cutover. Import results can include partially configured users, so verify the resulting access as well as account creation.

Choose username scope before importing names that must remain unchanged. Site-scoped usernames require the site's dedicated endpoint. Give machine accounts the authentication and protocol access their clients support; a browser login by an administrator does not validate an unattended SFTP job.

Map the old client's paths to the new folder tree. For example, a client expecting /incoming can continue to use that path when its root maps to Partners/Acme and the actual folder is Partners/Acme/incoming. File System Layouts and FTP/SFTP Folder Settings explain how to choose that view. The protocol-specific SFTP Client Root Folders setting must be enabled when using an FTP/SFTP Client Root Folder for SFTP.

Root and home folder settings do not grant access. Apply Files.com folder permissions for listing, reading, uploading, replacing, renaming, and deleting as required. Existing Unix permission displays do not reproduce those grants. Test accounts that should be excluded from the exchange as well as the accounts that should succeed.

Prepare the Endpoint Identity

If you control the existing hostname's DNS, a Custom Domain can retain that address. Configure the domain on Files.com and use its displayed CNAME target. Clients using a fixed IP need the new dedicated addresses; keeping the hostname does not preserve the old IP or update a partner's network allowlist.

A hostname change affects every client using that address. If exchanges need independent cutovers, arrange separate verified endpoints or individual client changes. Otherwise, prepare all dependencies on the shared hostname for the same handoff.

For SFTP, the server's host key is distinct from the user's SSH key. Importing a supported existing host private key can preserve the server identity clients already trust; custom host keys require dedicated IP addresses. If the old private key is unavailable or a new identity is intended, distribute the new fingerprint through the agreed verification process and update client trust before cutover. Do not disable host-key checking to bypass a mismatch.

For FTPS and other certificate-based connections, coordinate the hostname, certificate trust, ports, and network rules with the client owners. Verify the actual client configuration against the supported protocol rather than assuming every old server setting carries over.

Validate and Cut Over by Exchange

Use an isolated folder and agreed sample files with the actual client, account, and intended endpoint. Exercise the operations the job performs, including replacement or cleanup. Confirm the client's path view, file contents at the receiving location, and the application's acceptance. For a mounted destination with Buffered Uploads, verify onward delivery separately from upload receipt.

Follow Production Validation & Change Control for missing input, unavailable destinations, partial completion, and repeated delivery. Compare the old and new job's selection and scheduling rules; two jobs enabled together can deliver or process the same input twice.

At the agreed handoff, stop the old processor for that exchange, reconcile pending files and changes since the import, and enable the new process. Coordinate DNS or client configuration changes with the responsible owners. Verify a controlled first production exchange and its receiving result before moving the next dependency.

Agree which endpoint accepts new submissions during the handoff and how files arriving at either endpoint are reconciled. Keep unprocessed inputs available until their delivery and application results are established.

Retire the Old Service with a Recovery Plan

Keep the previous configuration and required data recoverable until the agreed acceptance criteria are met. Define who can pause the new flow, where newly received files are preserved, and how files already delivered or consumed will be reconciled if service returns to the old endpoint. Reverting DNS or a schedule does not undo those actions.

Retire the old server after its remaining accounts, jobs, storage connections, and infrequent exchanges have been accounted for. Remove obsolete credentials and connections, retain required records under your policy, and assign ongoing ownership for credentials, changes, failed delivery, and application rejection. Managed File Transfer develops the operating model for recurring automated feeds.