A University Replaced Its Home-Grown SFTP Server and Scaled Files.com Feed by Feed Without Adding Administrators

A US nonprofit university serves a national online student body alongside its residential campus.

An institution built that way runs on student data, and student data does not sit still. Enrollment records go to the vendor that handles student banking and refunds. Transcripts arrive from a national exchange and get staged for processing. Housing payment files move into the housing system. Report structures generated from the central student data repository go out as CSV feeds to whichever campus system needs which fields. Every one of those movements is a file transfer. For a university whose model is national and online, the layer that moves those files is not plumbing. It is how the institution's systems talk to each other.

The university ultimately replaced its home-grown server feed by feed, growing its Files.com connections many times over while the same administrators kept student-data flows running.

The Server the University Built Itself

For years, that layer was a Linux SFTP server the university had built and maintained in-house, surrounded by PowerShell scripts, assorted job-automation tooling, and manual steps. Every transfer job was bespoke: built by hand, re-homed by hand, and understood by whoever built it.

The cost showed up where it mattered most. Student financial files went out on recurring schedules. A monthly enrollment file carrying tens of thousands of records went to the university's banking vendor by hand: an administrator opened FileZilla and sent it manually, every month. Financial cadences that students depended on rode on hand-built infrastructure and individual memory.

The team carrying all of it was small. Application administration at the university runs on two primary administrators whose responsibilities also cover a range of other campus applications. And the server could not simply be swapped out. External vendors and internal systems depended on the exact feeds it produced, so every valid job had to be identified individually and re-created without interrupting the feed it served. There was no one-weekend cutover available.

What the Replacement Had to Do

As the number of vendor and system integrations grew, one bespoke job per feed stopped being survivable. The application team could not keep scaling integrations on a foundation where every new feed meant a new script on a server they also had to maintain. In 2020, the university set out to replace the home-grown solution.

The replacement had specific work to do. It had to speak SFTP to vendors exactly as the old server did, so nobody outside the university changed anything. It had to reach on-premises servers that would never be exposed to the internet. It had to connect to Azure Blob Storage, the university's archival tier. And it had to be operable at scale by the same administrators, which meant automation in place of scripts rather than a new home for the scripts.

The university selected Files.com to be that layer: the university's primary SFTP platform, and the governed transfer hub between its central data repository, its internal applications, its on-premises servers, Azure storage, and its external vendors.

A Year of Running Old and New in Parallel

The university staged the move deliberately. Non-production connections came first, across dev, test, and stage, so every process could be proven before it touched production. Then, over roughly a year, the team re-created the legacy server's valid jobs on Files.com one by one while the old server kept running against the same feeds. No vendor or campus system lost its data during changeover, and new integration requests were onboarded onto Files.com at the same time.

Three capabilities made the platform able to stand in everywhere the old machinery had been.

First, Files.com could reach protected internal systems without exposing them to inbound internet traffic. Files.com Agents connect outbound from on-premises servers, while Azure Blob Storage is mounted as a Files.com Remote Server. External vendors continue to connect over SFTP without changing how they exchange files with the university.

Second, automation took over the work the scripts and hand-sends used to do. Files.com Remote Server syncs and Move File Automations carry recurring feeds on schedule, routing a file to multiple destinations when it has to land in more than one place. The monthly enrollment file that used to leave through FileZilla now goes out as an automated monthly SFTP sync, with nobody sending anything by hand.

Third, the whole exchange is governed. Access is scoped to exactly two populations: university administrators, and external vendors logging in to perform a transfer. Sign-in runs through Azure OAuth single sign-on with MFA enforced at the identity provider, and every action lands in an immutable audit log.

Connections Multiplied, With the Same Team

With the migration in production, the university had replaced bespoke, hand-maintained transfer jobs with a repeatable integration pattern, and the results show in how fast the platform grew.

• In about eighteen months, the deployment grew from a small set of outbound connections and no on-premises agents to many times that number, with agents now deployed on premises.
• New vendor integrations now go live routinely. Each one is a connection and a sync built on an established pattern, not a new script on a server.
• The same administrators run the entire deployment, backed by colleagues who can support it from documentation. Headcount did not move while the platform grew many times over.

The immediate result was getting the university's financial feeds off hand-built infrastructure and eliminating the manual send entirely. The compounding result is larger. Growth now lands on connections and automations instead of on people. When a new campus project surfaces a new system that needs data, the answer is a connection on the platform, not a build, and the pattern for it already exists.

A Standard Pattern for Every New Feed

Before, a new data feed at the university meant a new job: someone built it, someone remembered it, and files that students' refunds and enrollments depended on rode on that memory. Today a new feed is a request the application administration team fills inside a standard pattern on Files.com, visible in one audit log alongside everything else the university moves.

That standard pattern lets the application team operate an integration hub for a university with a national online student body.