Learning Care Group Moves Off RoboFTP With Files.com, One Job at a Time

Learning Care Group is an early childhood education and care provider in the United States. It operates 1,070 schools under 11 brands, with approximately 20,000 employees.

A workforce that size, 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 as often as hourly, 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 more than 100 SSIS jobs and 15 to 20 vendor connections depending on it, Learning Care Group began retiring RoboFTP by standing up Files.com beside it and moving the estate job by job rather than attempting a big-bang cutover.

The Server Under Every Feed Had Stopped Getting Updates

The server was RoboFTP, running on an internal VM. Its vendor had shipped no updates since 2022, leaving the product effectively unsupported and end-of-life. More than one hundred scheduled SSIS jobs in SQL Server connected through it, on cadences from hourly to monthly, with the Oracle HR feed at the hourly end. In practice, unpatched and unmaintained software sat in the path of employee data and confidential vendor data around the clock, and had for years.

The infrastructure team maintained the VM itself. The product offered no single sign-on for administrators and no compliance attestation to hand a vendor during a security review. Its logging was so thin that the only way to work out what a folder was for, or who used it, was to inspect user access by hand, one account at a time.

Why an Unsupported Server Stayed in Production

The server survived that long because everything depended on it. Replacing it meant re-pointing more than a hundred production jobs owned by the data warehouse team, plus 15 to 20 vendor connections, roughly half of them vendors authenticating in and half Learning Care Group authenticating out. And the company had been burned once before: a vendor had refused to support a different SFTP product it ran at the time, so third-party compatibility was a live risk in any replacement, not a checkbox.

What ended the standoff was a structural decision rather than an incident. Learning Care Group decided to get out of self-hosting entirely.

“The driver is just security.”

That decision set the requirements. The replacement had to be a managed SFTP platform with no VM to maintain, running under Learning Care Group'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.

Learning Care Group 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 Learning Care Group's own domain rather than a vendor's. Because a past vendor had refused to support a previous SFTP replacement, 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 Learning Care Group 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 unsupported server.

The folder layout was rebuilt from scratch rather than lifted over. On the old server, a folder's purpose could only be reconstructed by inspecting who had access to it, so copying that structure would have copied the confusion. Starting fresh gave the team a layout it can actually read.

The security and identity configuration—single sign-on, SCIM, the custom domain, Sentinel forwarding, and geo-blocking—was scoped during onboarding in April 2025 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, Learning Care Group began moving file transfer off a server it hosted and patched itself and onto a managed platform its security team can see.

• Each employee feed or vendor exchange moved to Files.com comes off unsupported software and reduces the workload remaining on the self-hosted VM.
• File transfer activity streams into Microsoft Sentinel, so the SOC monitors the file layer alongside the rest of its Microsoft security data. On the old server, even a folder's purpose was a manual investigation; now activity is logged and lands in the tooling the SOC 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.

As the migration continued, the operational verdict was short.

“It’s very easy to use, and things have just worked, which has been great.”

Retiring a Server Without a Cutover Weekend

The lesson that travels is the shape of the migration. Learning Care Group 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.