Checklist: replace an on-premises SFTP server

Who this is for

You run an SFTP server on a machine in the office, in a rack at a colocation site, or on a cloud VM nobody has touched in years. It still works, which is the problem. This checklist, Checklist: replace an on-premises SFTP server, is for the IT lead, operations manager, or developer who inherited that box and has been asked to retire it. At most small and mid sized companies that person also covers help desk, backups, and the finance system.

It assumes the server moves real files for real people: partners dropping order files, customers picking up reports, internal batch jobs passing data between systems. The software matters less than you think. It could be Serv-U, Cerberus FTP Server, FileZilla Server, CompleteFTP, or plain OpenSSH with a folder and a handful of accounts.

This is not about moving a general purpose file server, and it is not about SharePoint or OneDrive. It covers the parts that make SFTP hard to replace: accounts, keys, host keys, firewall rules, scheduled scripts, and the audit trail that a customer or an auditor may ask for later.

Before you begin

Get a date in writing. Any date. A server that is going away at some point never goes away, because nobody in the business will spend a week hunting the scripts that talk to it. A named cutover month changes that conversation fast.

Build an inventory before you shop for a replacement. Export the account list, each home directory path, and the authorized_keys file for every account. Pull the connection log and list every client IP that has connected in the last few months. That log is the most honest record of who depends on the server, and it will contradict what people tell you.

Then look for the automation. Search application config files, cron jobs, Windows scheduled tasks, and code repositories for sftp, scp, ssh, the hostname, and the port number. Expect to find hard coded passwords in scripts written years ago by someone who has since left.

Decide the target shape before you go deeper. There are three common ones: a managed file transfer service from a cloud provider, an SFTP server you run on cloud infrastructure with your own controls, or a SaaS file transfer product with a browser interface for business users. Each shifts work between you and the vendor, and each changes the checklist below.

The checklist

Work the list in order. The first items are about knowing what you have, the middle ones about designing the replacement, and the last ones about the switch itself. Jumping straight to the cutover is how partners end up with failed transfers on a Monday morning.

Treat each item as evidence, not a box to tick in a hurry. If you cannot name the human owner of a key fingerprint or a firewall rule, that item is not finished. Stop and find the name.

Keep the output in one shared document that the business can read, not in a ticket thread only three engineers can see.

• Export every account, its home directory, and its last login date, then flag or disable any account with no activity in the past 90 days.
• List every authorized public key per account and match each fingerprint to a named person or system before you copy anything.
• Record the current server host key fingerprints and plan how clients that pin them will receive the new ones.
• Map every inbound path: firewall rules, NAT entries, DNS names, and any client that connects by IP address instead of by name.
• Trace every outbound flow, including scripts on application servers, batch jobs, and partners that pull files from you.
• Measure real data volume and file sizes per flow across a full month, including month end close, so storage and transfer limits are sized correctly.
• Write down the folder structure, permissions, and the quarantine and error folders that people rely on but never documented.
• Check whether any flow depends on features you would lose, such as encryption at rest, automatic renaming on receipt, or post transfer scripts.
• Choose how authentication will work in the target and confirm each external partner can support it, including older clients with limited cipher and key exchange options.
• Set up the target with a separate account per integration instead of one shared login, so a single leaked credential cannot reach every folder.
• Run a parallel period where both servers accept the same files, and compare file checksums rather than file counts.
• Write a rollback plan that names a firm date after which the old server is powered off, not just left running for now.
• Update the runbook, the on call notes, and the partner contact list before the cutover, not after it.

What good looks like

Every file flow has a named owner, a schedule, and a documented source and destination. When a transfer fails at night, one person knows who to call, and it is not the person who set up the original server.

Logs from the new setup land in your central log store, and you can answer who uploaded a given file and when without logging into the transfer host. Access reviews happen on a schedule, and stale accounts get disabled instead of sitting active for years.

The old machine is powered off. Its DNS names are retired or repointed, and the firewall rules that exposed it are removed. Leaving it running just in case leaves the original risk exactly where it was.

Partners notice almost nothing, which is the point. Their client configs change once, their transfers keep succeeding, and the support tickets stay quiet.

What to do next

If your inventory is thin, spend one week on it before you talk to vendors. A clean list of accounts, flows, and client contacts makes every quote sharper and every demo shorter.

When you compare options, compare on effort, not only on features. Ask how host keys are rotated, where logs live, how accounts are added and removed, and what happens when a partner needs a new login on short notice.

Cloudverg offers a Discovery and roadmap sprint at a fixed price of $9,500 over two weeks, which ends with a target architecture, a phased plan, and a fixed quote for phase one. It fits teams that have the inventory but need it turned into a decision. It is one option among several, and an internal design session or a vendor trial may be enough.

Whatever you pick, put the cutover date on the calendar, tell the partners, and set the switch off date for the old server on the same day.

Frequently asked questions