A Go-to-Market Consultancy Moved Its Direct-Mail SFTP Exchange to Files.com and No Client Noticed

A B2B go-to-market consultancy provides strategy, data science, analytics, and marketing services to Fortune 500 and high-growth clients. Inside it sits a business that looks nothing like consulting. Its direct-mail data division processes direct-mail data for large mailers, turning raw USPS postal data into delivery insight: tracking mail in flight, flagging delays that put in-home timing at risk, and reconciling postage. Consulting runs on decks and models. The division runs on files. Client mail data streams in continuously, gets processed, and goes back out, day and night. For years, every one of those files passed through a single SFTP server the division ran itself. Its hostname and SSH host key were embedded in every client connection and automated sender, so replacing the server without breaking those connections would require preserving both.

Thousands of Files an Hour, With No Maintenance Window

The workload was bi-directional and continuous. Client files arrived over SFTP around the clock, thousands per hour, and were pulled down to local drives for processing. The processed results went back up for clients to retrieve. Because the volume never paused, the exchange had to run without interruption: an hour offline would mean thousands of files queued while the mail they tracked kept moving through the postal system.

The division carried that workload on infrastructure it maintained itself. The server was its own to patch and keep online, one of several separate FTP setups that had grown up across the company. Every user account was created by hand. A record of who had accessed what was assembled on request. As the client base and the volume grew, none of that administration was scaling with it.

Pinned in Place by a Hostname and a Host Key

What kept the server in place was not affection for it. Every client and every automated sender authenticated against the division's own SFTP hostname and its SSH host key. Replace the server the normal way and every one of those connections breaks at once: client software throws host-key warnings, unattended scripts stop dead, and the fix becomes a coordination project across every counterparty, timed against a workload with no maintenance window. The server stayed in place because replacing it looked riskier than keeping it.

So the replacement had a specification before it had a vendor. It had to absorb the volume continuously. It had to take over the existing hostname, present the existing host key, and accept the existing credentials, so that no client would need to change anything or even notice. It had to import the existing user base in bulk rather than account by account. And it had to expose everything to automation: provisioning, permissions, and activity history. The division selected Files.com to be that server.

A Cutover Built to Be Invisible

In 2019, the migration was designed so that nobody outside the division could detect it. Files.com's custom domain support let the division keep its own SFTP hostname, served from dedicated IP addresses. Files.com matched the existing server's SSH host key, so a client connecting to either the old server or the new one saw an identical server identity: same address, same key, same login. A one-time bulk import created the user accounts from a template.

The cutover itself was then a DNS change. The CNAME was repointed, traffic began landing on Files.com, and every login worked exactly as it had the day before. No client reconfigured a connection, no script threw a warning, and the self-hosted server came out of service.

Encryption by Rule, Audit by API

Retiring the server was the requirement. What the division built next was the reason an API-first platform mattered. The division's team wrote a PowerShell script against the Files.com behaviors API to apply GPG auto-encryption throughout the client folder tree and reconcile its folders on a schedule. The point was to leave no room for human error: however a folder gets created, the encryption setting is applied, and Files.com encrypts each file automatically the moment it arrives.

The same API took over the audit work that used to be manual. The site's full activity history is pulled automatically, so the record of who did what is collected as a matter of routine rather than assembled on request. A lifecycle rule deactivates dormant accounts, so access that stops being used stops existing.

API Traffic Grew Past Anything the Old Server Could Have Carried

With the cutover complete, the division traded a server it had to keep alive for an exchange that maintains itself, and the exchange has since grown into something the old server could not have carried.

• The self-hosted SFTP server was retired with zero client-side changes: no host-key warnings, no broken automation, no outreach campaign to every counterparty.
• Several hundred named client and vendor logins now run through the exchange, each fenced to its own folders.
• Daily API calls on the site grew many times over as new client integrations and data feeds were added, and the division absorbed that growth without standing up or scaling any infrastructure of its own.
• Encryption, audit collection, and account cleanup run as standing policy rather than as tasks someone remembers: files are encrypted on arrival, history is exported automatically, and dormant accounts shut themselves off.

The Invisible Cutover, Run Twice

After a later merger, the approach was tested a second time during a Files.com consolidation. The division kept its custom domain and dedicated IPs, so hundreds of client connections rode through the organizational change the same way they had ridden through the server replacement: unchanged.

What is different now is what the division operates. Before Files.com, running the exchange meant running a server: keeping a box alive under thousands of files an hour, creating accounts by hand, and reconstructing history whenever an audit asked. Since the move, the team's work has been the exchange itself, the client integrations, the data feeds, and the encryption policy, while Files.com carries the infrastructure underneath. For any company staring at an entrenched SFTP server with hundreds of external endpoints depending on it, the division's cutover is the counterexample to the migration project everyone dreads: keep the hostname, match the host key, and no client ever finds out the server changed.