Medcom Moved 600 Client Logins to Files.com and Retired Its SFTP Servers

Medcom Benefit Solutions is a third-party administrator of employee benefits. Benefits brokers hire the company to run the work behind their clients' plans: COBRA administration, ACA reporting and forms, consumer-driven health plan processing, and the compliance obligations that surround all of it under ERISA, HIPAA, and IRS rules. Medcom has done this work for more than forty years, serving municipal, school, and commercial employers across the United States through its broker partners.

Every one of those services runs on files. Employer groups send enrollment files. Terminations have to reach the COBRA operation. Carriers send medical and dental cost changes. A TPA sits between hundreds of employer groups, their brokers, and the insurance carriers behind them, and its product is what it does with the files they exchange. Much of that data is protected health and enrollment information, so the exchange itself is a regulated surface that Medcom has to secure, and has to prove it secures, every time a client or auditor asks.

A Decade-Long Server Cycle and a Team of One

For years that exchange ran on Medcom's own hardware: an internal SFTP server and physical file servers the company owned and administered itself.

The visible cost was the hardware cycle. A server was held for about ten years, and each replacement meant another five-figure purchase and another decade of ownership for a box whose only job was moving client files.

The heavier cost was who carried it. Medcom's entire technical estate is run by one owner, CTO Bobby Randolph, with a small support team and offshore developers. Hundreds of external client logins, per-client folder permissions, and PGP key exchanges all had to be administered on infrastructure that same small team also had to patch and keep alive. The population never stopped growing, either: four to five new employer groups joined the exchange every month, each needing its own folder, its own scoped credentials, and often its own PGP configuration.

And because the files carry protected health data, Medcom's own clients and their outside auditors regularly asked how the file layer was secured. On a self-run server, producing that evidence was Medcom's job too.

The Cloud Migration That Couldn't Carry File Transfer

“I wanted to put it all into one place and move it to the cloud.”

The occasion came when Medcom moved its in-house .NET applications to Microsoft Azure. The natural assumption was that file transfer would land there too. It couldn't yet. An SFTP service with hundreds of isolated client folders, scoped credentials, and per-client PGP decryption is not something Azure hands you ready to run; rebuilding it there meant building and operating another system, and Medcom could not pause client file exchange while that happened.

Medcom's applications went to Azure, but the file exchange did not wait for Azure to be ready to carry it. The transfer layer would move to Files.com first and stand on its own.

Whatever took the server's place had to do what the server did, minus the ownership. It had to speak SFTP to hundreds of external clients using the credentials and tools they already had. It had to wall each employer group, broker, and carrier into its own folder. It had to decrypt encrypted vendor files automatically, per client, without anyone running a script. It had to carry a HIPAA business associate agreement and produce the audit evidence Medcom's clients ask for. And it had to be operable, day to day, by a team of essentially one.

Files.com was already inside Medcom's architecture as the file layer behind its own applications, and it met the whole list. Medcom made Files.com the SFTP hub for the entire client exchange.

A Folder, a Login, and a PGP Key for Every Client

On Files.com, the exchange stopped being a server and became a tenancy model. Each client, whether employer group, broker, or carrier, has its own folder and a login scoped to read and write in that folder and nowhere else. Clients drop enrollment files, termination files, and cost changes into their folders; Medcom picks them up and processes them. No client can see that any other client exists.

Standing the population up was one operation. Using Files.com's Bulk New User provisioning, Randolph created around 600 client accounts in a single pass, provisioned them in a disabled state, and switched them on group by group as each was ready to cut over. That staging let Medcom move a client population whose file exchange could not pause for a single day, with the Files.com CLI handling scripted management from there.

The per-client handling that used to be server administration became folder configuration. Files.com PGP auto-decrypt behaviors automatically decrypt and rename encrypted vendor files using each client's keys. File expiration rules purge sensitive files on schedule, so benefit data does not accumulate past its useful life. Medcom staff sign in through the company's Azure AD single sign-on, and Files.com's audit reports and standing HIPAA business associate agreement provide the evidence Medcom's clients and outside auditors request.

The End of the Server Cycle

With the exchange in production on Files.com, Medcom decommissioned the on-premises SFTP server and the file servers behind it. What used to be an infrastructure ownership problem is now administration a small team performs.

• The hardware cycle is over. There is no SFTP server to buy, patch, secure, or hold for a decade.
• Onboarding a new employer group is a folder, a scoped login, and, where the client requires it, a PGP key. The exchange absorbs four to five new groups a month as routine work, with no added load on infrastructure.
• When Medcom's clients ask to see the cloud vendor's SOC 2 report, and when its outside auditors run vendor security reviews on the file-exchange layer, Files.com's audit reports and the standing BAA are the evidence.
• When a client deletes or overwrites an open-enrollment file, Medcom restores it from Files.com's backups instead of asking the client to resend it.

The change lands on two fronts at once. The cost of running the exchange fell from owned hardware to configuration. And the risk moved: securing and evidencing a regulated file layer now rests on a platform audited for exactly that, rather than on a server one small team had to defend on its own.

File Transfer Stands on Its Own

Medcom's applications now run in Azure, while Files.com operates as the independent transfer layer for its clients, brokers, and carriers. File transfer no longer depends on Medcom owning the infrastructure underneath it—or on the application cloud being ready to carry it.