SAS to R: Why R, and Where Your Migration Budget Should Go
This post is part of our SAS to R series:
- Part 1: Is SAS still used, and is it worth keeping?
- Part 2: Why R, and where your migration budget should go (this post)
- Part 3: coming soon
If you’re moving regulated analysis from SAS to R, two things are worth knowing up front. R is a choice you can defend: regulators don’t tell you which software to use, and R has already been through FDA review in public pilot submissions. And the language itself is the cheap part. Most of the cost and risk comes from six other places, and most of those are about planning, not programming.
Part one asked whether SAS is still worth keeping. This post covers why R, and where to put your budget and attention once you commit.
Why R is a defensible choice
Regulators ask for evidence, not a vendor
The FDA’s Statistical Software Clarifying Statement says the agency does not require any specific software for statistical analysis. It asks for the software to be documented in the submission, including version and build, and ICH E9, the international guideline on statistics in clinical trials, asks for documented testing.
The business implication is that the obligation stays the same whichever language you choose. What changes is who does the work. With SAS, much of the evidence arrives with the licence. With R, your organisation produces it.
There is public precedent to show your risk committee
The R Consortium’s R Submissions Working Group has taken R-based tables, figures, standard analysis datasets and an interactive app through FDA review in a series of public pilots, with the code and lessons published. That is not a guarantee for every submission, but it is the most useful thing you can put in front of a risk committee.
Hex stickers and pilot details: R Consortium R Submissions Working Group.
The clinical tooling already exists
Most of what a clinical SAS team does has a maintained R equivalent, much of it built by pharma companies working together in the pharmaverse. You are not funding the tooling, only the move.
One finding comes up repeatedly. A lot of “we have to keep SAS” turns out to mean “we have to produce SAS transport files”, the format regulators expect submitted data in. That format is a published specification, not a licence, and R writes it.
For your team: admiral and sdtm.oak build ADaM and SDTM datasets, mmrm reproduces SAS mixed models, and xportr and haven write and read v5 transport files.
What about Python?
For statistical analysis and regulated reporting, R is usually the closer match to the work SAS did. Python tends to be the better answer for machine learning engineering and production services. Many organisations run both, on shared infrastructure and review processes, so choosing R for statistics does not lock in the rest of the stack.
Where the cost and risk come from
Teams often budget a SAS to R migration as a code rewrite. The rewrite is the smallest of the seven layers below. The six above it are where timelines slip and budgets get cut.
1. The two systems will disagree, and both will be right
SAS and R make different default choices for the same statistical method. For example, they handle tied survival times differently. Run the same analysis in both and the numbers can differ in the last decimal places, with neither tool wrong.
The cost comes when nobody notices until validation, and nobody recorded which choice the analysis plan meant. The fix is cheap if you do it early: add the method choices to each analysis specification before conversion starts. That turns an open-ended rewrite into a bounded validation exercise.
For your team: the cross-industry CAMIS project documents these differences method by method, including survival analysis in R’s survival package and rounding.
2. Data does not mean quite the same thing
The two languages treat missing values and dates differently. A filter carried over from SAS can quietly drop rows in R, changing the denominator. The result is a table that is nearly right, which is harder to catch than one that is obviously wrong. Budget for checking the data, not just converting the code.
For your team: SAS sorts missing numerics below every value and has 28 kinds of missing, while R has one NA. Date origins also differ (1960 against 1970), which haven handles on import.
3. Your macro library holds rules nobody wrote down
As we covered in part one, a mature macro library holds business rules that exist nowhere else. A line-by-line conversion reproduces the code and loses the reasoning. Recovering that intent is analysis work, and it needs people who know the SAS estate. In mature estates it can be one of the longest parts of the migration, so plan for it explicitly.
4. Reproducibility becomes your responsibility
SAS gives you one vendor managing one product. R spreads that across R itself and the add-on packages (community-built libraries of functions) your analyses depend on. Being able to rerun an analysis years later is now something your team owns. The tooling is mature, and it should be mandatory from day one rather than added later.
For your team: pin dependencies with renv, serve packages from a dated snapshot with Posit Package Manager (which we wrote about alongside diffify), and containerise anything long-lived. In the UK public sector, the same idea goes by the name reproducible analytical pipelines.
5. Proving it works is a separate project
Getting the right answer and being able to prove you will keep getting it are different projects, and only the first one is fun. Budget them separately.
The R Validation Hub set out the widely used approach: assess each package by risk rather than validating everything to the same depth. That keeps the effort proportionate. We build on the same idea in Litmus, which scores packages at function level.
For your team: how the scoring works for validation and code quality, the shorter argument in Should I Use Your R Package?, unit testing with testthat, and validating Shiny apps in regulated environments.
6. Dual running is the cost that gets cut
For the whole parallel period you pay for both systems, both sets of people and both sets of sign-off. This is what de-risks the migration, and it is reliably the first thing trimmed when the budget tightens. Protect it.
Agree in advance how close the two sets of results need to be, and why. Then check automatically rather than by eye, so a difference shows up the day it appears.
For your team: diffdf was built for this comparison, and arsenal::comparedf and waldo cover adjacent cases. Run them in CI.
What to do before converting any code
- Inventory the macro library and the business rules inside it.
- Add method choices to every analysis specification.
- Decide your package validation approach.
- Budget dual running as a protected line.
Each of these is manageable once it has been named and written down. That is what an assessment produces before a single line of code is converted.
If you are planning a migration, get in touch. If your team is earlier than that, our Why Use R? course is written for people arriving from SAS and SPSS.
Frequently asked questions
Is R accepted by regulators?
The FDA does not require any specific software, provided the software used is documented with version and build and its testing is documented. The R Consortium’s pilots have taken R-based tables, figures, standard analysis datasets and an interactive app through FDA review.
Will R give exactly the same numbers as SAS?
Not by default, and that is normal. The two make different default choices for some methods, so results can differ slightly while both are correct. The fix is to state those choices in the analysis specification rather than hunt for a bug.
References
- US FDA, Statistical Software Clarifying Statement
- US FDA, Study Data Technical Conformance Guide
- R Consortium, R Submissions Working Group and 2026 plans and 2025 progress
- PHUSE, PSI, ASA and IASCT, CAMIS: Comparing Analysis Method Implementations in Software
- CAMIS, R versus SAS: Kaplan-Meier and Cox proportional hazards and R versus SAS rounding
- R Validation Hub, A Risk-based Approach for Assessing R Package Accuracy within a Validated Infrastructure
- The R Foundation, R: Regulatory Compliance and Validation Issues
- CRAN,
mmrmfor mixed models for repeated measures - CRAN,
admiralandsdtm.oakfor ADaM and SDTM builds - CRAN,
xportrfor writing v5 transport files
