1/14

02 Nov 2026

SAS to Databricks Migration: Can Lakebridge Convert SAS?

A SAS to Databricks migration rebuilds SAS programs, datasets, macros, schedules, and models as PySpark and Spark SQL notebooks, Delta tables in Unity Catalog, Lakeflow Jobs, and MLflow-tracked models. It is a re-implementation, not a lift-and-shift, because SAS processes one observation at a time on a single server, while Spark works on distributed sets with no implicit order. Databricks' Lakebridge added SAS support in v0.14.0 through Switch, its LLM-based converter, which is still experimental, and commercial converters offer more automation, but every converted program must be reconciled against SAS output. The quiet risks are semantic: SAS missing values, 1960-based dates, MERGE behavior, and trailing-blank string comparisons all differ from Spark.

SAS has powered analysis, data preparation, and regulatory reporting in banks, insurers, pharma, and healthcare for decades, and many of those estates now hold thousands of programs, nested macros, and nightly job flows. This page covers why teams move, how SAS concepts map to Databricks, how to convert DATA steps without changing results, what Lakebridge does for SAS today, and how to run both platforms side by side. For the services side, see our Databricks migration services overview, and for every legacy ETL tool at once, our ETL migration to Databricks article.

Quick Summary

SAS code is easy to read and hard to translate, because its row-by-row semantics hide assumptions that Spark does not share. Converters, including Lakebridge's experimental SAS support, speed up the repeatable majority, but missing values, dates, MERGE logic, and statistical procedures still need engineering and reconciliation. Inventory first, retire what nobody runs, and prove every output before cutover.

Key Takeaways

It is a re-implementation. DATA steps become DataFrame or SQL transformations, PROC SQL becomes Spark SQL, and macros become Python functions and job parameters.
Semantics matter more than syntax. SAS missing values, 1960-based dates, MERGE rules, and trailing-blank comparisons change results if translated literally.
Lakebridge now reaches SAS, with limits. Its Switch converter has a built-in SAS prompt, and it is experimental, LLM-generated, and provided as-is.
SAS can read Databricks during the move. SAS Viya connects through SAS/ACCESS Interface to Spark, so programs can migrate in waves.
Statistical procedures need documented reconciliation. Default options in PROCs and open-source libraries differ, especially in regulated work.
Prove every output. Reconcile against SAS through a full business cycle before decommissioning anything.

Why Teams Move from SAS to Databricks

Licensing and infrastructure cost. SAS licensing and the servers behind it are a large recurring expense for many estates, while Databricks bills consumption and compute that stops when jobs finish. Confirm your own SAS terms, because savings are not automatic and depend on governing usage.
Scale and batch windows. Distributed Spark compute processes volumes that strain single-server SAS environments, without manual tuning of work libraries and disk space.
Open skills. Python and SQL are widely taught, which eases hiring and reduces dependence on a shrinking pool of SAS programmers.
One platform for data and ML. Engineering, analytics, BI, and machine learning run on the same governed lakehouse, with MLflow tracking and registering models.
Governance. Unity Catalog brings permissions, lineage, and audit logging under one model instead of SAS metadata security beside a separate warehouse.
The trade-off. SAS has validated statistical procedures and a long record in regulated industries, so the goal is to preserve trusted results while changing the platform beneath them.
Databricks is not the only target. If your standards point elsewhere, see our Snowflake migration services and Microsoft Fabric migration services pages, and our comparison of Databricks vs Snowflake.

How SAS Concepts Map to Databricks

SAS	Databricks	Note
DATA step	PySpark DataFrame transformations or Spark SQL	Row-by-row logic becomes set-based operations
PROC SQL	Spark SQL (Databricks SQL)	Usually near-direct, with attention to SAS-specific functions and remerging
BY-groups, FIRST., LAST., and RETAIN	Window functions and grouped aggregations	Needs an explicit ordering
PROC MEANS, SUMMARY, FREQ, and SORT	groupBy aggregations, pivots, and orderBy	PROC SORT keeps ties in input order by default, and Spark does not
Macros and macro variables	Python functions, notebook widgets, and job parameters	Restructure nested macros instead of copying them
SAS datasets (.sas7bdat) and LIBNAME	Delta tables in Unity Catalog, as catalog.schema.table	Libraries map to catalogs and schemas
Formats and informats	Lookup tables, CASE expressions, and typed casts	Format catalogs need their own inventory
SAS/STAT, SAS/ETS, and Enterprise Miner models	Spark MLlib, scikit-learn, statsmodels, and MLflow	Defaults differ, so reconcile outputs
SAS/ACCESS engines and file imports	Lakehouse Federation, JDBC connectors, and Auto Loader	Connections inventoried per library
DI Studio and Enterprise Guide flows	Lakeflow Jobs and declarative pipelines	Dependencies rebuilt explicitly
SAS metadata security	Unity Catalog grants, row filters, and column masks	See our article on migrating row-level security
Schedules (LSF, Schedule Manager, cron)	Lakeflow Jobs schedules and triggers	Retries and alerts defined per task

DI Studio flows overlap with other ETL tools, so our legacy systems to Databricks, Informatica to Databricks, and ETL pipeline automation with Python articles cover the neighboring patterns.

Converting DATA Steps Without Changing Results

A DATA step reads one observation at a time and carries state between rows through RETAIN, FIRST. and LAST. variables, and sequential MERGE. Spark has no implicit row order, so this logic is re-expressed with window functions partitioned and ordered by the BY variables, explicit joins, and grouped aggregations. Array processing and DO loops typically become column expressions, while PROC SQL usually converts almost directly. The same refactoring mindset applies as in our PL/SQL conversion article: a literal translation of procedural logic is slow or wrong, and the rewrite is where correctness and performance come from.

The conversion has three rules. First, state every ordering assumption that SAS got for free from sorted input. Second, decide each missing-value rule deliberately instead of inheriting Spark's NULL logic. Third, test the edge rows, such as the first and last observation in each group, because that is where RETAIN and FIRST. logic breaks.

Worked Example: RETAIN and BY-Groups in Spark

A DATA step that keeps a running total per customer and flags each customer's first and last transaction is typical SAS code. This is an illustrative example, not a client engagement.

SAS

proc sort data=work.txn;
  by cust_id txn_date txn_id;
run;

data work.txn_flags;
  set work.txn;
  by cust_id;
  retain running_total 0;
  if first.cust_id then running_total = 0;
  running_total + amount;
  is_first = first.cust_id;
  is_last  = last.cust_id;
run;

Databricks SQL

SELECT
  cust_id,
  txn_id,
  txn_date,
  amount,
  COALESCE(
    SUM(amount) OVER (
      PARTITION BY cust_id
      ORDER BY txn_date, txn_id
      ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ), 0) AS running_total,
  ROW_NUMBER() OVER (PARTITION BY cust_id ORDER BY txn_date, txn_id) = 1 AS is_first,
  ROW_NUMBER() OVER (PARTITION BY cust_id ORDER BY txn_date DESC, txn_id DESC) = 1 AS is_last
FROM silver.txn;

Two details matter. The SAS sum statement starts from 0 and ignores missing amounts, so a customer whose first amount is missing still shows a running total of 0, while a window SUM over only NULL values returns NULL, which is why the SQL wraps it in COALESCE. And PROC SORT keeps tied rows in their input order by default, while Spark does not, so if two rows can tie on date and transaction ID, carry an explicit sequence column into the ordering. Please test this example in a Databricks workspace before adapting it.

Where SAS and Spark Results Drift

SAS Behavior	What Changes on Databricks	Safeguard
Numeric missing values are smaller than any number and compare as a value	Spark NULL makes comparisons unknown, so filters, sorts, and joins change	Decide each rule, and add IS NULL handling or COALESCE where SAS behavior must hold
Special missing values such as .A to .Z	Spark has a single NULL	Keep the codes in a separate column if business rules use them
Dates count days, and datetimes count seconds, from January 1, 1960	Spark dates and timestamps use a different epoch	Convert explicitly, and test boundary dates and datetimes
Every number is stored as an 8-byte floating-point value	Mapped types can change precision and rounding	Map to DECIMAL or DOUBLE per column and reconcile totals
MERGE with BY on many-to-many keys does not create a Cartesian product	A SQL join does	Re-express the logic explicitly and test many-to-many keys
Character comparison pads the shorter value with trailing blanks	Spark compares strings exactly	Trim keys explicitly and test with real data
LAG and DIF queues update only when executed	Window lag() is evaluated for every row	Rebuild with an explicit window and compare, especially where LAG sits inside IF logic
PROC SORT keeps tied rows in input order by default	Spark gives no tie order without a rule	Carry an explicit sequence column
Formats and labels travel with datasets	They are not written to database tables by SAS/ACCESS	Keep formats as lookup tables and labels as column comments

These are the differences behind outputs that look right and quietly are not, and the reason for column-level checks like those in our automated ETL testing with Python approach. The same set-based thinking appears in our comparison of traditional vs modern ETL.

Macros, Formats, and Statistical Procedures

Macros. Macros and macro variables become Python functions, notebook widgets, and job parameters. Deeply nested macros, dynamic code generation, and CALL EXECUTE need restructuring, not copying, and common macros are best consolidated into one tested Python library.
Formats. Formats and informats become lookup tables or CASE logic, and the format catalogs deserve their own inventory because reports often depend on them silently.
Descriptive procedures. PROC MEANS, FREQ, and SUMMARY map to Spark aggregations, though defaults such as variance definitions and missing-value handling need checking.
Statistical models. Regression, logistic, and forecasting models from SAS/STAT, SAS/ETS, or Enterprise Miner are rebuilt with Spark MLlib or libraries such as scikit-learn and statsmodels, tracked and registered in MLflow.
Equivalence. Default options, parameterization, and convergence settings can differ between packages, so models need documented reconciliation against the SAS originals, especially where model risk teams review results.

What Lakebridge Converts for SAS Today

Lakebridge is Databricks' free, open-source migration toolkit from Databricks Labs. Version 0.14.0 added SAS to the sources Switch can convert, and the pieces differ from the SQL stories:

Tool	What It Does for SAS	Status and Limits
Switch (LLM-based)	A built-in prompt converts SAS programs to PySpark notebooks	Experimental, and output is LLM-generated, so it needs review and reconciliation
Custom Switch prompts	YAML prompts extend Switch to patterns specific to your estate	Needs engineering effort and testing
BladeBridge and Morpheus	Deterministic converters for supported SQL dialects, with no built-in SAS DATA step support	Useful for SQL sources, not for SAS programs
Commercial SAS converters	Parser-driven tools from partners, often advertising automation and row-level parity	Treat claims as vendor claims, and ask for a proof of conversion on your own code
DataTerrain's approach	Parses SAS programs and macros, maps them through an intermediate schema, generates PySpark and Spark SQL, and reconciles outputs	Complex macros, BY-group logic, and statistical models still need review

Two practical points apply to Switch. It calls a model serving endpoint that you configure, by default a Claude model through Databricks' Foundation Model API, so review where your code is sent before running it on regulated programs. And all projects in the Databricks Labs GitHub account are provided as-is, with no service level agreements, so confirm support terms before building production timelines on it. Our Databricks migration services overview covers how tooling and services divide the work, and our SQL Server and SSIS, Oracle, and Teradata articles show how the same toolkit behaves on other sources.

Running SAS and Databricks Side by Side

SAS can read and write Databricks, so a migration does not need a big-bang cutover. According to SAS community library articles:

SAS Viya. It connects through SAS/ACCESS Interface to Spark, using LIBNAME with platform=databricks for the compute server and a data connector for CAS, with the Simba Databricks JDBC driver included in the deployment.
Unity Catalog. Catalog and schema are set through connection properties, so SAS programs can read governed Delta tables.
Authentication. SSO through Microsoft Entra ID is supported on Azure, and service principals are an alternative.
SAS 9.4. Older deployments have used the JDBC engine, so confirm what your version supports.
Caveat. SAS variable labels, formats, and lengths are not written to database tables.

In practice, converted programs can write Delta tables while unconverted SAS programs keep reading them, and downstream consumers never notice the switch. The same coexistence pattern appears in our Alteryx to Databricks article, and the wider platform context is in data platform migration to Databricks.

Moving SAS Datasets into Delta Tables

Get the data out. Export datasets to Parquet or CSV from SAS, or read .sas7bdat files with a Python library, then load them as Delta tables, and always compare the loaded values against the originals.
Map libraries. Each LIBNAME becomes a catalog and schema in Unity Catalog, organized into bronze, silver, and gold layers.
Trim character fields. SAS stores character variables at a fixed length, so padded values need trimming before they are used as keys.
Convert dates deliberately. Translate 1960-based dates and datetimes explicitly, and test the boundaries.
Choose numeric types per column. Use DECIMAL for money and DOUBLE for measurements that were floating point in SAS.
Keep the metadata. Preserve formats as lookup tables and labels as column comments, because Databricks tables do not carry them automatically.

A Phased SAS to Databricks Migration Plan

Phase	What Happens	Exit Criterion
Inventory	Catalog programs, macros, libraries, datasets, DI Studio jobs, Enterprise Guide projects, and schedules, using automated parsing of code and logs on large estates	A scored inventory with dependencies
Rationalization	Retire unused, duplicate, and one-off programs	An approved, smaller scope
Target design	Plan workspaces, catalogs, compute policies, networking, and a medallion layout	A signed-off design
Pilot	Convert a sample spanning simple, macro-heavy, and statistical programs, with a proof of conversion	A measured conversion rate and reconciled output
Data and code conversion	Load datasets into Delta tables, and convert DATA steps, PROC SQL, and macros in waves	Converted code passing tests
Models and orchestration	Rebuild statistical models in MLflow, and recreate job flows as Lakeflow Jobs	Models reconciled and schedules running
Parallel run and validation	Run SAS and Databricks side by side through a full reporting cycle, and reconcile row by row and aggregate by aggregate	Signed-off parity
Cutover and decommission	Repoint consumers, retire SAS workloads, and release licenses	No remaining SAS dependency

For sequencing across waves, see our key checklist for BI modernization, data warehouse to Databricks migration article, and cloud migration to Databricks article. Reports built on SAS output follow the data, and our reports conversion service covers that layer.

Best Practices for a Low-Risk Migration

Start from a complete inventory, and rationalize before you convert.
Refactor, do not transliterate. Rewrite procedural SAS logic as set-based Spark code instead of mimicking the DATA step loop.
Decide missing-value rules first, and write them down, because they touch every filter and join.
Build a shared function library. Convert common macros once into tested Python utilities.
Adopt a medallion layout so SAS intermediate datasets become governed, reusable tables.
Govern with Unity Catalog from day one, and keep data security compliance requirements in view.
Reconcile automatically on row counts, aggregates, and model outputs for every migrated workload.
Plan enablement. SAS programmers need training in Python, Spark, and notebook development to own the new platform.
Right-size compute with job clusters, serverless compute, and cluster policies so cost tracks usage.

Frequently Asked Questions

How do you migrate SAS to Databricks?

Inventory and rationalize the SAS estate, load datasets into Delta tables, convert DATA steps, PROC SQL, and macros into PySpark and Spark SQL, rebuild models and schedules, and reconcile every output against SAS during a parallel run before cutover.

Can Lakebridge convert SAS code?

Partly. Lakebridge v0.14.0 added a built-in SAS prompt to Switch, its LLM-based converter, which turns SAS programs into PySpark, but Switch is experimental, its output needs review, and Databricks Labs projects are provided as-is.

What happens to SAS DATA steps and macros?

DATA steps become PySpark DataFrame transformations or Spark SQL, with RETAIN, FIRST., LAST., and MERGE re-expressed as window functions and joins. Macros become Python functions, notebook widgets, and job parameters, best consolidated into a shared library.

Why do SAS and Spark results differ?

SAS treats missing values as the smallest number, counts dates from 1960, pads strings in comparisons, and processes rows in order, while Spark uses NULL logic, a different date epoch, exact string comparison, and no implicit order, so each rule must be handled deliberately.

Can SAS and Databricks run together during the migration?

Yes. SAS Viya reads and writes Databricks through SAS/ACCESS Interface to Spark, including Unity Catalog and SSO on Azure, so converted programs can write Delta tables while unconverted SAS programs keep reading them.

Scope Your SAS Migration with DataTerrain

Moving a SAS estate is easy to start and hard to finish, because the effort hides in nested macros, order-dependent DATA steps, and statistical results that must still match. DataTerrain brings 17+ years and 400+ clients in data and reporting modernization, with automated discovery, conversion support, and figure-for-figure validation against SAS output. Start with our ETL Solutions or the wider Databricks migration services page.

Talk to our migration team

Contents