items

Is SAS Still Used, and Is It Worth Keeping?

Author: Gigi Kenneth

Published: August 5, 2026

tags: r, sas, validation, litmus

SAS is almost 50 years old. It predates the web, and it predates most of the open source tools data teams reach for today. While old, it is not obsolete. SAS remains central to clinical research, banking, insurance and other regulated industries, and those organisations do not keep it because it is new. They keep it because it is trusted, governed and built into critical processes.

So its age is beside the point. What matters is whether your organisation would benefit from open source for critical processes and whether it can be trusted. Some teams are already moving off it, and the useful question today is: Can regulated industries trust open source, and which of your workloads should adopt it?

Why SAS lasted

Software survives when organisations trust it, and that matters most where mistakes are expensive.

Clinical research is a clear example. The US FDA defines the formats it accepts for electronic study data, and those standards include SAS transport files alongside CDISC data models. The FDA does not require sponsors to run their analysis in SAS; the requirement applies to the format used to submit data. But submission standards shape working practices. Over time, organisations have built SAS-based processes around these requirements, including standard outputs, controlled datasets, audit trails and reproducible analysis. The FDA also asks sponsors to provide the software programs used for certain efficacy analyses, so reviewers can reproduce the results. In that setting, reproducibility sits at the heart of the process.

Banking and insurance follow the same pattern. Credit risk models and regulatory reports must be explained, tested and defended, and SAS became established because it supported reliable, governed workflows. That is why SAS lasted: it works in environments where trust matters more than novelty.

Why organisations keep SAS too long

Some organisations have strong reasons to keep SAS. Others keep it because replacing it looks harder than maintaining it.

Years of logic sit inside the code

A mature SAS system contains more than programs. It contains macros, formats, reporting rules and business decisions built up over decades. Some of those rules only exist in the code, the people who wrote them may have left, and the documentation may be incomplete. This creates grown logic: systems built gradually by different people, without one clear design.

Changing the system feels risky because nobody fully understands it. But leaving it unchanged increases the risk over time, as the system becomes more deeply embedded and fewer people retain the knowledge needed to maintain or replace it.

SAS is only a component

SAS is often connected to reporting pipelines, validation processes, internal tools and downstream systems, so removing one part can affect the rest. Banking teams have described cases where legacy systems are closely tied to daily operations, and replacing them requires more than rewriting code. It requires understanding how the whole process works.

Risks - Skills are getting harder to maintain

Organisations need people who understand the existing SAS system, and they also need people who can design and validate its replacement. These are often the same people. That creates a difficult position: the team needs specialist knowledge to maintain SAS and the same knowledge to move away from it. Waiting has been classed as the safest option by some, but waiting increases the knowledge gap and increases the risk.

The vast majority of UK Universities haven’t taught SAS to undergraduate statistics students in over fifteen years!

Migration to open source is a full-stack problem that needs a full-stack solution

R and Python can perform the analysis, modelling and reporting that regulated organisations need. The main risk in a SAS to R migration lies in the process around the language; R itself is rarely the problem.

Regulated teams must prove that the new process works, and similar results are not enough. Outputs may need to match at row, value and format level, and teams must retain evidence showing how each comparison was completed. Undocumented macros create another risk: a macro may hold an important business rule that exists nowhere else, and a direct conversion can reproduce the code while losing the reasoning behind it. Migration means rebuilding the process itself, not simply translating code line by line.

A proven method for introducing open source: phased migration

Replacing the full SAS system at once creates unnecessary risk. A safer migration runs the old and new systems in parallel, so teams can compare outputs, test business rules, automate regression checks, document differences, maintain a rollback route, and validate each stage before release.

This takes longer than converting the code, but it produces a system the organisation can trust. A successful SAS to R migration is phased, governed and validated, with correctness and auditability built in from the start.

Is SAS worth keeping?

Sometimes SAS still has a clear role in regulated environments, supporting established processes, submission standards and governance models. But not every SAS workload is essential. Some remain because they are critical, and others remain because nobody has reviewed them.

Occasionally, the answer is both SAS and open source, not a choice between the two. Teams can use R or Python for new analysis, modelling and visualisation while keeping SAS for existing governance, reporting or submission processes, which lets organisations modernise without introducing unnecessary risk.

The first step is assessment. Before moving anything, identify which workloads are regulator-facing, which processes contain undocumented logic, which systems depend on SAS outputs, which workloads can move now, and what evidence will be required to validate the change. That gives the organisation a clear migration path.

How Jumping Rivers helps you achieve Open Source

We strategise for teams and systems from SAS to full implementation to R, treating migration as a controlled transformation rather than a code conversion exercise. That means understanding the existing system, identifying risk, validating outputs and moving workloads in stages.

If your organisation is deciding which SAS workloads to keep and which to move, get in touch. If you are still assessing whether R is the right choice, our Why Use R? course is designed for teams moving from SAS and SPSS. And if your organisation already uses R, Litmus provides audit-ready risk assessments for open source packages at package and function level.

Migration helps you adopt R. Validation helps you trust it.

Frequently asked questions

Is SAS still used in 2026?

Yes. SAS remains widely used in pharmaceutical research, banking, insurance and other regulated industries. Its value comes from governance, auditability and its place within established workflows.

Does the FDA require SAS?

No. The FDA accepts SAS transport files as a submission format, but this does not require sponsors to perform their analysis in SAS. These standards have, however, influenced the tools and processes used for clinical submissions.

Can R replace SAS in clinical trials?

Yes, in many workflows. The main challenge is validation: teams must show that R outputs are reproducible, correct and suitable for regulatory review. Many organisations use SAS and R together during the transition.

What are the main risks of migrating from SAS to R?

The main risks include undocumented business rules, incomplete knowledge of existing systems, differences between old and new outputs, and replacing too much at once. A phased migration with parallel testing and formal validation reduces these risks.

Can SAS and R be used together?

Yes. R can support new analysis, modelling and visualisation while SAS continues to support existing reporting, governance or submission processes. For many organisations, this is the safest route to modernisation.

References

Jumping Rivers Logo

You might also like

Introducing Litmus Dashboard

The Litmusverse is a suite of R tools that automates the risk assessment, scoring, and reporting of R packages—supporting compliance in regulated environments. Built for use across CRAN, Bioconductor, and internal repos, it helps teams streamline package approval and maintain a production-ready R ecosystem.

R Package Quality: Validation and beyond!

Not all R packages are clearly “good” or “risky”, most fall somewhere in between. This post introduces a scoring framework to help users assess package quality, based on documentation, code, maintenance, and popularity. We also share key principles to ensure the scores are useful, fair, and adaptable to different contexts.

R Package Quality: Package Popularity

The popularity of an R package can be measured using package downloads and reverse dependencies. While these measures clearly have issues, they do provide a good indication of the package health. This post looks at these measures in more detail.