Most results for this search are tools that produce Python from SAS source, and several of them do that job well. This page starts one step earlier — with whether the move is right for your codebase at all, what the output costs to verify, and what to do when the answer turns out to be no.
There are four routes out of a SAS codebase, not two: hand it to an automated tool, rewrite it by hand, run the SAS programs as they are on something that is not SAS, or leave it alone. Which one is right turns almost entirely on two questions — how much code there is, and whether anyone has to reproduce the output it produced before. Everything below is what each route costs.
Python is the better destination more often than a page like this one usually admits. Four conditions make it clear-cut: the codebase is small enough for one person to read in a week, the team already writes Python day to day, the analysis is being rebuilt anyway, and nothing downstream requires the new numbers to match the old ones exactly. When all four hold, a rewrite is cheaper than any compatibility layer, and what you end up with is code your team can maintain without carrying a second language.
Every option here is the right answer for somebody. None of them is without cost, and the expensive part is never the syntax.
Web tools, vendor services and large language models take .sas source and return Python, usually mapping DATA steps onto pandas and the common procedures onto statsmodels or scikit-learn. For a few hundred lines of straightforward data manipulation that is a genuine shortcut, and it gives you a readable starting point in minutes. The bill arrives later: every line of the output needs a person who knows both languages to read it.
Someone reads the SAS program, works out what it was meant to do, and writes that in Python. It is slower to start and it is the only route that ends with code shaped like Python rather than like SAS wearing a Python coat. Teams that are happy with Python two years later mostly got there this way, usually keeping the old program running alongside until the numbers agreed.
The route the comparison pages skip. Jenner is a clean-room implementation of the SAS 9.4 language written in Rust: it reads SAS7BDAT files directly and executes .sas source as it stands, so there is no generated code to review and no second language for the team to carry. What it does not do is cover the whole SAS language, and the coverage is published procedure by procedure so you can check yours before you depend on it.
Doing nothing is a real decision and often the correct one. If the code is stable, the environment it runs in is not going away this year, and nobody is asking for a change, the migration you do not do has the best return of anything on this page. Revisit it when a platform move, an audit, or a hiring problem forces the question.
The failure mode of an automated conversion is not a syntax error; those surface the first time the code runs. It is the silent numerical difference. SAS pads character values with trailing blanks and Python does not, SAS counts dates from 1 January 1960 while pandas counts from 1 January 1970, and a DATA step MERGE does not behave like a pandas merge when the key repeats on both sides. None of that raises anything. It produces a number that is nearly right, which is the worst kind of wrong. So the real price of a conversion is a line-by-line read by someone fluent in both languages, plus a stretch of running old and new side by side on the same input until the outputs agree — and that price scales with how much code there is, not how clever it is.
Your code, your data, and the logs side by side. That is the comparison that decides this, and it is the one nobody else can run for you.
Start Free Trial