Deciphera Retires CrushFTP Without a Cutover Weekend

Deciphera Pharmaceuticals is a biopharmaceutical company running clinical and pre-clinical research programs.

None of that science moves without data crossing the company boundary. Clinical development runs on outside partners: contract research organizations, labs, and specialty vendors that send and receive clinical and medical study data for the life of every trial. The layer that carries those files between Deciphera and its partners is core infrastructure. For years, that layer was a single on-premises SFTP server, and the server had a problem. Deciphera’s way out was to freeze new work on the legacy system and move each department together with its vendors to Files.com—without a cutover weekend.

An SFTP Server That Became a Working Repository

Deciphera ran CrushFTP as its managed file transfer platform, an on-premises SFTP server in front of Amazon S3 storage. It was built to be a transfer point. It became something else. Department after department began working directly out of it, until the transfer server had turned into a de facto working repository for much of the company, with external vendors holding access into the folders where departments kept live data.

“We’ve got a terrible situation there, where our SFTP has become a repository, like a working repository, for a lot of departments.”

The cost of that drift showed up everywhere the server touched. Every user, internal or external, was provisioned by hand, and with no single sign-on, the account list lived apart from the corporate directory. Nearly 1,400 accounts had accumulated on the server, more than three times the company’s headcount, and nobody could say with confidence who still needed access. The folder structure was just as hard to keep right. Paths were built on S3 buckets, with permissioning embedded in CrushFTP virtual file shares layered over them, so a typo baked into a bucket name propagated into every folder that referenced it, and undoing it meant recreating the tree. On top of all of it, the S3 access keys behind the platform had to be rotated by hand on a recurring schedule.

At a pharmaceutical company, a permission model nobody can confidently reason about is not a housekeeping problem.

“We have a lot of data on the platform that, if people who are not supposed to see it see it, could jeopardize the project.”

Too Embedded to Cut Over in One Weekend

The server survived because everything that made it bad also made it hard to remove. It was not a transfer endpoint that could be swapped behind the scenes. Departments did their daily work inside it, and their external vendors connected into it along access paths nobody had fully mapped. A synchronized cutover would have meant moving every department and every vendor at once, in the middle of live studies, and betting clinical data flows on getting all of it right in one weekend. The untangling was expected, and it was dreaded, so it kept not happening.

What ended the standoff was a modernization initiative with a specific shape. Deciphera did not need a better SFTP server; it needed to stop running one. The replacement had to be SaaS and locked down. User management had to be driven from the identity systems the company already ran, so file accounts stopped being a second population maintained by hand. Logging had to be deep enough to answer who touched what. Automation to and from S3 and other applications had to be native rather than scripted. And because a one-shot cutover was off the table, the platform had to run alongside CrushFTP for as long as the retirement took.

Deciphera selected Files.com to be that platform.

A Parallel Run, a Freeze Mandate, and Departmental Waves

The migration was designed around the constraint instead of against it. Files.com was stood up in parallel with CrushFTP, deliberately, with no cutover date driving the plan. A Files.com child site served as the test environment ahead of production, and validation began with the IT admin group alone, which built the first automations and configurations before any department moved.

The first real work was subtraction. Of the nearly 1,400 accounts that had accumulated on CrushFTP, the team identified roughly 375 that were actually active, internal and external together, and imported those. The dormant majority never made the trip.

Then came the mandate: anything new goes into Files.com. New projects, new vendors, and new folders all landed on the new platform from that point forward, which froze the legacy server’s growth. From there, the retirement ran as departmental waves. Each department moved together with the external vendors who held access to its folders, so no working relationship was ever split across two systems. Ahead of each wave, the team did the dependency discovery the server had always resisted, mapping the permissioning buried in virtual file shares and the vendor access paths one department at a time. Tom Young described the plan as a set of dominoes: the first were the slowest to tip, and each one makes the next easier.

The Data Stayed in S3 and the Users Stayed in the Directory

What made the waves affordable to run is what Files.com did not ask Deciphera to move. The platform became a governed front on infrastructure the company already trusted, rather than a new silo beside it.

Identity stayed where it was. Files.com authenticates users through SAML SSO via Okta, which federates in turn from Microsoft Entra and Active Directory. Users are managed from the identity source of record instead of being created by hand inside the file platform.

Storage stayed where it was. Amazon S3 remains the backend behind the folders, but Files.com connects to it using AWS STS with IAM role assumption, so there are no standing access keys to rotate. And because permissions on Files.com are granted to folders, users, and groups on the platform rather than derived from bucket paths, the structure is no longer welded to bucket names. The failure mode Deciphera lived with on CrushFTP, where one typo meant recreating a tree, does not exist in the new model.

The transfer plumbing moved onto the platform too. Files.com Automations run the scheduled jobs that copy files between locations and make outbound SFTP connections to partners. Every login, file operation, and settings change lands in the platform’s logs, meeting the in-depth logging requirement without Deciphera building anything to produce it.

A Legacy Server That Only Shrinks

With Files.com in production and the freeze mandate holding, Deciphera replaced a hand-administered server nobody wanted to touch with a platform run from its directory and its cloud accounts.

• Manual per-user provisioning is gone. A file account is now a consequence of the directory, not a task on someone’s list.
• Periodic S3 access-key rotation is gone. Authentication to Deciphera’s buckets runs on IAM role assumption, with no standing keys to manage.
• Folder structure is fixable. A mis-named folder is a rename on the platform, not a rebuild of every tree that referenced a bucket path.
• CrushFTP only shrinks. Everything new lands on Files.com, and each wave moves a department and its vendors off the old server together, so the legacy repository drains without a cutover ever being scheduled.

The immediate result of each wave is one more department off the server. The retirement is still underway, but the compounding result is what each wave leaves behind: the identity federation, the S3 connection, the automations, and the operating procedures built for the first departments carry every later one, which is why the dominoes fall faster as they go. A dreaded project became a repeatable pattern.

A Retirement Without a Cutover Weekend

The instinct with a system like this is that it has to come down before anything gets better: pick a weekend, move everyone, hold your breath. Deciphera’s experience is the correction to that instinct. By turning retirement into a repeatable departmental pattern, the company kept clinical study data flowing without wagering it on a single cutover. The server nobody wanted to touch now only gets smaller.