SNHU Replaced Its Home-Grown SFTP Server and Scaled Files.com to 100 Connections With the Same Two Administrators

Southern New Hampshire University is one of the largest nonprofit online universities in the United States. Alongside its residential campus in Manchester, New Hampshire, it serves more than 200,000 online students across the country.

An institution that size 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.

SNHU ultimately replaced its home-grown server feed by feed, growing Files.com from 14 to roughly 100 connections while the same two primary administrators kept student-data flows running.

The Server the University Built Itself

For years, that layer was a Linux SFTP server SNHU 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 SNHU 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. A two-person 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, SNHU 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 two people, which meant automation in place of scripts rather than a new home for the scripts.

SNHU 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

SNHU 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.

“We had to replace our old SFTP server, and that is where the majority of the growth came from in the last year: replacing all of those jobs that were still valid and moving them over into your platform.”

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: SNHU 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.

From 14 Connections to 100, With the Same Two People

With the migration in production, SNHU 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 went from 14 outbound connections and no on-premises agents to roughly 100 connections and 15 agents.
• New vendor integrations now go live at roughly one per month. Each one is a connection and a sync built on an established pattern, not a new script on a server.
• Two primary administrators run the entire deployment, backed by five colleagues who can support it from documentation. Headcount did not move while the platform grew sevenfold.

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

“This is our primary SFTP tool, so anything that has to do with SFTP goes through Files.com first and foremost.”

Before, a new data feed at SNHU 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 a two-person team operate an integration hub for a 200,000-student university.