Milliman SkySail Replaces On-Prem SFTP With Files.com Without Rebuilding Its Amazon S3 Claims Pipeline

Milliman SkySail is the pharmacy benefit analytics practice of Milliman, one of the world's largest actuarial and consulting firms. SkySail ingests pharmacy claims data from across the pharmacy benefit industry, from pharmacy benefit managers and payers to pharmacies and brokers, and analyzes it for contract pricing, rebate performance, and guarantee management. The platform processes claims at up to one million per minute while keeping the ability to drill into any single claim, and the work is high-consequence: in one published engagement, SkySail's daily monitoring helped a major employer identify and recoup more than $30 million in pharmacy errors.

None of that analysis starts until the claims arrive. Every SkySail client relationship begins with files, pushed continuously from the client's own systems, and all of it is protected health information under HIPAA. Claims intake is the front door of the business. Files.com changed how the files arrive, not where they land, which is what let SkySail replace the transfer layer without touching the pipeline behind it.

Claims Intake Ran Through a Server the Team Wanted Gone

That front door was an on-premises SFTP server, surrounded by a set of legacy FTP systems carrying SkySail's other IT file processes. The server was infrastructure the team owned outright: hardware to run, software to patch, and a security posture to defend under HIPAA obligations, all for a system whose only job was receiving files. The legacy FTP systems scattered the rest of the exchange across separate platforms, each with its own accounts and its own upkeep.

The team had already decided to move away from the on-prem server. Yet every new pharmacy client still meant provisioning more of it: more credentials, more transfer volume, more weight on an architecture that was supposed to be on its way out.

A Production Pipeline Could Not Pause for Its Own Replacement

What kept the old server alive was that the intake was never casual file sharing. It was a production data pipeline. Automated systems at each client business pushed claims files on their own schedules, the files had to land in the correct per-client location, and they had to feed processing workflows wired into SkySail's own Amazon S3 environment. The largest clients delivered extracts of up to 4.5 GB on a monthly cadence. Every byte of it was PHI. A transfer layer that critical could not be switched off for a rebuild, so replacing it meant replacing it under load.

Growth made the status quo untenable. SkySail was steadily adding pharmacy clients, and each one added more to a platform the team wanted retired. The replacement had to do several specific things: speak the automated SFTP that clients' systems already used, give analysts on both sides a browser for ad hoc exchange, keep each client's intake separate under its own credentials, deliver every file into SkySail's own S3 buckets where the processing already lived, absorb multi-gigabyte files, and operate under HIPAA with a business associate agreement in place.

SkySail selected Files.com to be that transfer layer.

One Files.com Layer Between Every Client and SkySail's S3

Files.com became the single managed layer between SkySail's clients and its S3 processing environment, and nothing downstream had to move.

Each client connects under its own credentials, and the onboarding shape is consistent: a couple of automated system accounts that push files over SFTP, plus a handful of analyst users who work through the web interface. The automated accounts carry the daily claims flow, and analysts exchange ad hoc files on top of it. One client's intake never mixes with another's.

Using Files.com Automations with the S3 integration, every arriving file is routed into the corresponding client folder in SkySail's own buckets. The processing workflows wired to those buckets run exactly as they did before.

The client-facing surface runs under SkySail's own domain with two-factor authentication, and Files.com holds a HIPAA business associate agreement, so the compliance envelope around intake is maintained by the platform rather than patched onto a server by the team.

During the transition, the legacy FTP estate ran in parallel with Files.com. SkySail then consolidated its IT file processes onto the one environment.

Hundreds of Files a Day, and Client Onboarding That Repeats

With the Files.com pipeline in production, SkySail replaced an owned transfer server and a scattered FTP estate with one managed intake layer, running at the full scale of the business.

“We're ingesting hundreds of those files every day.”

• Hundreds of claims files arrive every day, the largest carrying 7 to 10 million records each, and every file lands in the right client folder in SkySail's S3 with no one handling it.
• The on-premises SFTP server is gone, and most of SkySail's IT processes now run through Files.com instead of separate legacy FTP systems.
• Onboarding a new pharmacy client is a repeating pattern rather than an integration project: SkySail creates the client's credentials and folder, and the client's systems start delivering into the same pipeline as everyone else's.
• The environment reaches beyond SkySail itself. Other Milliman practices send data into the same Files.com site, so cross-practice exchange runs under the same governance as client intake.

Intake Without a Server to Own

Today, a new pharmacy client no longer means provisioning more of a server the team was trying to retire. A high-volume, regulated data pipeline turned out not to need self-hosted transfer infrastructure at all: Files.com carries the intake, and SkySail's team carries the analytics.