An Early Childhood Education Provider Moves Off Its Self-Hosted SFTP Server With Files.com, One Job at a Time

A US early childhood education and care provider operates more than a thousand schools under several brands.

A workforce of tens of thousands, spread across a thousand-plus schools, generates constant machine-to-machine data movement. Oracle Cloud HR holds the employee record. A SQL Server data warehouse ingests it for reporting. Azure and Entra ID carry identity, with Microsoft Sentinel as the SIEM the company's security operations center watches. Between those systems, and between the company and the outside vendors it exchanges confidential data with, information moves as files over SFTP. Employee CSVs leave Oracle HR throughout the day, the warehouse picks them up and loads them, and vendors drop files in and collect files out.

All of that traffic crossed a single system: an SFTP server the company hosted itself.

With over a hundred SSIS jobs and more than a dozen vendor connections depending on it, the company began retiring RoboFTP by standing up Files.com beside it and moving the estate job by job rather than attempting a big-bang cutover.

One Self-Hosted Server Under Every Feed

The server was RoboFTP, running on an internal VM the infrastructure team maintained itself. More than one hundred scheduled SSIS jobs in SQL Server connected through it, along with more than a dozen vendor connections. The company wanted that traffic on a managed platform its security team could see, with no VM of its own in the path.

The product offered no single sign-on for administrators and no compliance attestation to hand a vendor during a security review. The team wanted both, along with activity logs its SOC could read in the tooling it already watches.

A Hundred Jobs and Every Vendor Hanging Off One Server

Everything depended on the server. Replacing it meant re-pointing more than a hundred production jobs owned by the data warehouse team, plus every vendor connection, roughly half of them vendors authenticating in and half the company authenticating out. And third-party compatibility was a live requirement in any replacement, not a checkbox: vendors connect with their own SFTP clients, and each one had to work against the new endpoint.

The decision that set the direction was structural. The company decided to get out of self-hosting entirely.

That decision set the requirements. The replacement had to be a managed SFTP platform with no VM to maintain, running under the company's own domain. Administrators had to sign in through Entra ID rather than another set of local passwords. It had to carry a SOC 2 attestation the team could show vendors during onboarding, and its logs had to stream into Sentinel, where the SOC already works. Above all, vendor SFTP clients had to be proven to connect before the migration began, not after.

The company selected Files.com to be that platform.

SFTP for Vendors, Entra ID Inside, Sentinel Watching

Files.com became the managed SFTP endpoint for the internal ETL jobs and external vendor exchanges moved onto it.

On the vendor side, nothing about how partners connect had to change. Vendors connect over SFTP with SSH key authentication, against an endpoint that carries the company's own domain rather than a vendor's. The team verified vendor client connectivity up front, before committing any production job to the move.

On the internal side, administration follows the directory. Administrators sign in through Entra ID single sign-on, and Files.com SCIM provisioning creates, updates, and deactivates their accounts from Entra itself. Nobody manages administrator accounts by hand, and a departure in the directory ends access to the file platform at the same time.

The security controls replicate what the rest of the estate already enforces. Files.com forwards its activity logs into Microsoft Sentinel, joining the identity and Azure data the SOC already monitors there. Country-level geo-blocking on the Files.com site mirrors the country list the company maintains at its network edge. And Files.com Expectations define which files must arrive, where, and by when, with Event Channels routing an alert the moment an expected feed is missing or late.

Job by Job, With No Hard Cutover

The data warehouse team owns the SSIS jobs, so it owns the pace of the migration. Easier jobs were handpicked first and walked across one at a time, each updated, tested, and re-pointed at Files.com. There was no synchronized cutover weekend. Both endpoints run while the estate drains, and every job that moves is permanently off the self-hosted server.

The folder layout was rebuilt from scratch rather than lifted over, so the team started with a structure it designed for the platform rather than one it inherited. Starting fresh gave the team a layout it can read at a glance.

The security and identity configuration (single sign-on, SCIM, the custom domain, Sentinel forwarding, and geo-blocking) was scoped during onboarding and is now in production, so every job arrives on a platform that is already governed.

Out of Self-Hosting and Into the SOC's Line of Sight

With Files.com in production, the company began moving file transfer off a server it hosted and maintained itself and onto a managed platform its security team can see.

• Each employee feed or vendor exchange moved to Files.com comes off the self-hosted VM and brings the day the server can be switched off closer.
• File transfer activity streams into Microsoft Sentinel, so the SOC monitors the file layer alongside the rest of its Microsoft security data, in the tooling it already watches.
• Vendor onboarding starts from a SOC 2 attestation instead of questions about a self-hosted VM, which has made bringing new vendors on straightforward.
• A vendor feed that fails to arrive on schedule raises an alert through Expectations and Event Channels, instead of surfacing later as a broken downstream job.

The result that compounds is the pattern itself. Each SSIS job that moves follows a path the team has already walked, and each new vendor is a folder, an SFTP credential, and an SSH key on a platform that already answers the security questionnaire.

Retiring a Server Without a Cutover Weekend

The lesson that travels is the shape of the migration. The company did not schedule a cutover for a server with a hundred jobs and every one of its vendor connections hanging off it. It stood Files.com up beside the old server, proved that vendors could connect, and let the estate drain one job at a time. A legacy SFTP server that deep in the business does not demand a big-bang migration. It demands a destination that is ready before the first job arrives.