A Higher-Education Software Publisher Retired Its In-House SFTP Server to Deliver Releases Through Files.com

A higher-education software publisher's financial aid management system is used by hundreds of colleges and universities to package awards, generate federal reports, and stay compliant as FAFSA and Pell Grant rules change.

The system is a thick-client application, installed locally at each institution and upgraded on each campus's own IT schedule. That one fact gives the publisher a second job. Every release, several times a year, has to be delivered to hundreds of campuses the organization does not control, on a calendar set by the federal financial aid cycle. For years, the publisher did that job on distribution infrastructure it built and operated itself.

A Federal Calendar, Hundreds of Campuses, and a Server the Publisher Ran Itself

Owning the in-house file-distribution and SFTP solution meant owning everything that came with it. The traffic pattern was the hard part. Releases ship on a scheduled cadence, and when one goes out, the entire customer base of hundreds of institutions contacts the site and downloads at once. The infrastructure sat quiet most of the year and then had to absorb its whole audience in a day.

The stakes on those days were federal. Releases carry compliance logic coded to federal and state requirements, including Federal Work Study reporting rules due each December. An institution that cannot pull a release is not merely inconvenienced. It is at risk of missing a federal deadline.

The audience made none of this easier. The people downloading are financial aid administrators rather than IT staff, at campuses of every size, including schools outside the US. Access had to map exactly to what each institution subscribed to, across dozens of entitlement tiers. And the channel ran in both directions: when remote troubleshooting was not enough, an institution had to send the publisher's support team a password-secured copy of its financial aid database.

The structural constraint underneath all of it is that the publisher controls neither campus IT nor campus schedules. Each institution coordinates internally to plan its own download and upgrade. So the distribution channel had to be self-service and always available, it had to make sense to a non-technical user, and it still had to enforce entitlements precisely while protecting some of the most sensitive data in higher education.

That is the specification the replacement had to meet: absorb full-base release days, enforce subscription entitlements without hand-managing more than a thousand accounts one at a time, present a portal that reads as the publisher rather than a vendor, keep SFTP available for staff who prefer it, take in PII-grade database uploads securely, and record who accessed what. The publisher selected Files.com to be that vehicle. The production cutover was timed just ahead of a scheduled release, with the user accounts moved onto the new site days before the entire base would log in at once. Every scheduled release since the 2019 cutover has shipped through Files.com.

One Branded Portal, Dozens of Entitlement Groups, and a Protected Path In

Files.com became the single customer-facing layer between the publisher and every institution running the system.

The front door is the publisher's own. The site runs on its own product-branded domain. A financial aid administrator following a download link sees the publisher, not a file transfer vendor. The web portal is the primary interface, and the same site answers over SFTP for institutions that script their transfers.

Entitlements are groups. Dozens of Files.com permission groups, modeled on the publisher's Active Directory structure, decide which release folders and support files each institution's users can reach. Enforcing a subscription level is group membership rather than per-user permissions work, and group memberships are audited every month against exported user lists.

The inbound path is governed the same way. When a support case needs the real thing, an institution uploads a password-secured copy of its financial aid database into a password-protected folder set aside for support. Password-protected, expiring share links handle one-off deliveries in the other direction. User access and activity tracking keeps the record of all of it, and Files.com extended that reporting after adopting the publisher's own suggestions.

A Distribution Layer the Publisher Only Has to Administer

With Files.com in production, the publisher replaced infrastructure it had to build and operate with a distribution layer it only has to administer.

The compounding result is what the publisher no longer does. Nobody runs distribution servers, renews certificates, or builds capacity for release-day surges. The day-to-day operation of a portal serving hundreds of institutions is administered by a single senior technical analyst.

Out of the File Server Business

Today, when a release is ready, the publisher pushes it to Files.com and notifies its institutions. A financial aid administrator at any of hundreds of campuses logs into a publisher-branded portal, on the schedule their own IT sets, and pulls the upgrade that keeps their school compliant with the federal calendar. When a campus needs deep support, its database comes in through a protected folder, on the record.

Before the cutover, being the publisher of on-prem software meant also being the operator of the infrastructure that delivered it. Seven years of release days later, that second job belongs to Files.com.