Pharma Is Not Leaving SAS Because It Stopped Working. It's Leaving Because Open Source Moves Faster.

For a long time, SAS was the safe choice in pharma.

It was familiar to teams, accepted in regulated workflows, and built into how clinical reporting got done. That logic made sense for years.

But the market has changed.

Novo Nordisk completed its first NDA submission using entirely R-based tooling in 2021. GSK had already been building toward open source for years and publicly doubled down on that direction in 2023. In 2024, Roche shared the industry's first end-to-end R-based drug submission. And in 2025, Johnson & Johnson publicly discussed a successful hybrid R and SAS FDA submission. At this point, this isn't a collection of isolated experiments. It's a signal.

And it's not a story about pharma chasing something new. It's a story about pharma responding to pressure from every direction: cost, speed, talent, flexibility, and the need to work in a more connected data environment.

The real question now isn't whether open source can be used in pharma. That question has already been answered. The real question is why more companies are making the move, what they're getting in return, and what separates a smart transition from a painful one.

SAS still has value. But the trade-offs are getting heavier.

SAS earned its place. It gave regulated teams structure, predictability, and a level of standardization that mattered. This isn't a story about SAS being useless. It's a story about its limitations becoming harder to accept.

The most visible issue is cost. Licensing is expensive, and in a tighter operating environment that matters. But cost is only part of the story. The bigger issue is that SAS is a closed system in a world that increasingly rewards flexibility. When teams need new capabilities, faster iteration, or better integration with the rest of the data stack, they're still working within someone else's roadmap. That creates friction, slows decisions, and limits what teams can build. It's not just a licensing problem. It's a control problem.

There's also a talent problem that companies can no longer brush aside. New statisticians, programmers, and data scientists are growing up in R and Python. That's what they learned. That's how they want to work. If your environment forces them into older tools and slower workflows, recruiting gets harder and retention does too.

SAS didn't suddenly become bad. The price of staying dependent on it has just gone up.

What companies are really buying when they move to open source

The open-source case is often reduced to savings. That's too small.

Yes, lower licensing costs matter. But that's not why this shift is important. What companies are really buying is capability.

Traditional SAS workflows are built around static outputs. More data usually means more reports, more files, more manual work, and more time spent getting from question to answer. That model becomes especially painful in clinical development, where teams need to revisit the same data from different angles and make decisions faster.

Open source changes the shape of the work.

With R and Shiny, teams can move from static reporting to interactive analysis. Instead of generating another output and waiting for the next cycle, they can explore the data live, filter populations, test assumptions, and get to the question behind the question much faster. Less friction between people and the data.

That difference shows up in real numbers. In one Appsilon project, GxP report generation for a biopharmaceutical company went from five weeks to five minutes, with 85% of document generation automated. In another, a clinical trial data app that had taken seven minutes to load was optimized down to 30 to 60 seconds. Those aren't cosmetic improvements. They change how teams work by shortening feedback loops and reducing waiting time.

And the value doesn't stop at clinical trials. The same open-source foundation can support work in discovery, manufacturing, and pharmacovigilance, helping teams integrate fragmented data, improve visibility across processes, and make faster decisions in data-heavy environments.

The compliance objection is real. But it's often asked the wrong way.

Every serious conversation about open source in pharma hits the same question: what about compliance?

It's a fair concern. But it's often framed as if proprietary software is compliant by default and open source is risky by default. FDA guidance is clear that the agency doesn't require any specific software for statistical analyses. What matters is that the software used is appropriately documented, reliable, and controlled. Governed versus unmanaged is the real distinction, not proprietary versus open.

That doesn't mean open source is effortless. Responsibility moves closer to the organization. Teams need documented validation approaches, controlled environments, versioning, access controls, testing, traceability, and clear ownership. Those aren't optional extras. They're the disciplines that make regulated work defensible, regardless of the stack.

This is also why the broader ecosystem matters. The R Validation Hub supports the adoption of R in biopharmaceutical regulatory settings. Pharmaverse is a connected network building curated open-source R packages for clinical reporting. The R Consortium Submissions Working Group is explicitly focused on improving practices for R-based regulatory submissions. That shared infrastructure is one reason this conversation has moved from opinion to practice.

The companies that do this well don't treat it like a software purchase

This is where many transitions go wrong.

A company decides to modernize. It picks R, stands up infrastructure, runs some training, and assumes the rest will happen naturally. Then six months later, adoption is uneven, people fall back to legacy processes, and leadership starts asking whether the effort was worth it.

Usually, the problem isn't the technology. A tool rollout isn't the same thing as a change program.

The teams that make this work start smaller and think more broadly. They choose a focused pilot with clear business value. They involve statisticians, engineering, quality, and business stakeholders early. They invest in workflow design, validation practices, and enablement, not just installation. That's consistent with how leading organizations describe their own journeys, including Novo Nordisk, GSK, and Johnson & Johnson.

They also accept something many companies try to avoid: for a period, both worlds will coexist. Clinical studies last years, and you can't switch methods midstream without introducing risk. In practice, responsible organizations often run parallel models for a while, continuing existing work where needed while building new capabilities for future studies. That's not a failure to commit. It's how real change works in regulated environments.

What's really changing in pharma

This shift is bigger than a move from SAS to R.

It's the industry moving away from static, vendor-locked workflows toward more flexible, connected, and scalable ways of working with data. Not using open source because it sounds modern, but building an environment that helps teams move faster, collaborate better, and create less friction between analysis, insight, and action.

That's why the companies moving first matter. They're showing that open source isn't just technically possible in pharma. It's operationally useful, strategically relevant, and increasingly hard to ignore.

That's also why we created this e-book. It covers the real reasons pharma teams are rethinking SAS, the myths that still slow open-source adoption, the practical value R and Shiny create across the drug development lifecycle, and what it takes to make the transition work in a regulated setting.

[Download the e-book: Clinical Data Analysis, Open Source in Pharma →]