🟢
Updated recently
Last updated:

Quick Answer: SAS to cloud migration: A SAS migration succeeds when you treat it as four separate inventories — data, code, schedule, and outputs — and migrate them in that order. In practice the data is the easy part: SAS can export tables directly to Parquet, and Parquet on S3 is what the whole cloud data stack reads. The hard part is code: PROC calls and DATA steps have to be rewritten in Spark SQL and PySpark, procedure by procedure, with a validation harness that proves the numbers still reconcile. The expensive mistake is migrating code that nobody understands, or modernising the parts that were never the problem while leaving the scheduler and the reporting layer untouched.

Key takeaways

  • Treat it as four inventories — data, code, schedule, outputs — and migrate them in that order. The data is the easy part.
  • Export to Parquet first. Every later step is easier on Parquet than on a live table in the lakehouse.
  • Type conversion is where projects break. PERIOD, INTERVAL and MULTISET each need a deliberate rule, not a default.
  • Validate with control totals, not row counts. Row counts match while the data is wrong more often than people assume.
  • Keep the statistics, move the plumbing. Actuarial logic is domain knowledge worth keeping; data movement is where cloud economics help.

What this guide covers

  • Why SAS estates persist long after SAS stopped being a good idea
  • The four inventories that make up a SAS estate
  • A staged migration path from SAS export to a served cloud model
  • A procedure-by-procedure translation table from SAS to Spark SQL and PySpark
  • How to validate that the migrated numbers still tie out
  • The hybrid pattern that most regulated organisations actually land on
  • What this combination means for a career in India

The scenario: the renewal quote that forces the question

It usually starts with procurement. A SAS licence renewal arrives, the number has grown again, and someone asks the question that has been deferred for years: what are we actually paying for?

The answer is rarely “SAS”. It is a stack of things that arrived one at a time, each individually justified, now held together by a scheduler nobody fully understands:

  • Actuarial and reserving models written in PROC code by people who have left
  • A regulatory reporting layer that must produce identical numbers to what was filed last year
  • Hundreds of scheduled batch jobs running on a shared server, some of which are read by nobody
  • Hundreds of gigabytes of SAS datasets in libraries that only SAS can read directly
  • Excel outputs pasted into decks by people who learned SAS in an era when that was normal

The instinct is to plan a rewrite. The better plan is to work out what each piece actually does before deciding what happens to it, because a large share of SAS estates turn out to be mostly data movement and reporting — which is the easiest thing to migrate and the least interesting to rebuild.

Why SAS estates persist

It is worth being fair about this, because the honest reasons are the ones that make the migration hard:

The code is stable and tested. A SAS program that has produced the same regulatory output for nine years is not broken. It is undocumented, single-threaded, dependent on a mainframe-era scheduler and completely unportable — but it works, and it works identically every time.

The data is locked in. SAS datasets in libraries with formats, informats and indexed data sets are readable by SAS and painful for anything else. The SAS/ACCESS documentation shows the range of access paths SAS itself supports, and it is a good illustration of how much of the surrounding world has to be spoken to read a SAS table.

The procedures are deep. SAS’s PROC family covers statistics, forecasting, reporting and formats that would each be a build in another language. Where the statistical logic is genuinely valuable, rewriting it in Python is a project, not a port.

The people know it. In Indian banking, insurance and healthcare — industries with heavy regulatory reporting — SAS skills remain common on résumés, which keeps the demand for internal SAS support alive well after the technology stopped being strategic.

None of this makes migration a bad idea. It makes it an estimation problem, and estimation is what makes it fail.

The four inventories

Before choosing a target architecture, take four inventories. Most migration proposals start with the fourth and skip the rest.

1. Data

Which SAS libraries and datasets matter, how large are they, how often do they change, and who reads them? Include the outputs that were extracted to CSV or Excel by hand — those are the datasets, just stored on someone’s laptop.

2. Code

Every PROC call, DATA step, macro, format and informat, with a usage count. This is the inventory that determines the effort, and the one that is usually missing. A migration estimate built from line counts is fiction; a migration estimate built from a PROC histogram is a plan.

3. Schedule

The jobs, their dependencies, their windows, their retry behaviour and their downstream consumers. This is where the business impact hides, because a nightly regulatory job that fails silently is a compliance problem, not a performance problem.

4. Outputs

The reports, extracts and dashboards that leave the system. Every output format is a contract with someone outside the platform team — and contracts are the thing a migration breaks.

The staged migration path

Stage 1 — Extract the data as Parquet, without changing any logic

This is the highest-value first step, and it is worth doing even if the migration stops there. SAS can write Parquet directly through its EXPORT procedure, and Parquet is the format every cloud analytics service reads natively.

/* Export a SAS library to Parquet, one file per year-partition */
proc export data=work.monthly_actuals outfile='s3://mybucket/sas_export/actuals/'
  outtable='monthly_actuals'
  dbms=parquet;
  label year=year month=month;
  where year >= 2015;
run;

For tables that need reading from SAS rather than writing out, SAS/ACCESS covers connecting SAS to external files and databases, including CSV, Excel and database sources.

Why Parquet and not CSV:

  • Columnar — Athena and Spark read only the columns a query references
  • Typed — no re-parsing, no type inference at query time
  • Compressed — materially smaller than the equivalent CSV
  • Native — Athena, Redshift Spectrum, EMR, Glue and Databricks all read it directly

Stage 2 — Catalogue it in the cloud

Point a Glue crawler at the exported prefix and the tables appear in the Glue Data Catalog with inferred schemas. The crawler documentation covers schema detection and the update policies that decide what happens when an upstream table changes shape.

If the SAS export includes SAS-specific types — dates stored as numeric, missing values as special sentinels — translate them at export time rather than in every downstream query. This is the single most common source of “the cloud numbers do not match SAS” bugs.

Stage 3 — Rewrite the code, procedure by procedure

The translation is mostly mechanical, and the table below covers the cases that make up most of the volume.

SAS construct Cloud equivalent Watch out for
PROC SQL Spark SQL / PySpark spark.sql SAS SQL dialect differences in date functions and null handling
PROC MEANS, PROC SUMMARY groupBy().agg() with the matching functions SAS N and MISSING semantics; count vs count of non-null
PROC FREQ groupBy().count() plus window functions for percentages Cross-tabulation shapes differently — check crosstab output carefully
PROC SORT + BY sortWithinPartitions() or a Window ordering SAS sorting with NOEQUALS/EQUALS has no direct equivalent
DATA step PySpark DataFrame operations The DATA step’s implicit retain and by-group processing have no one-to-one equivalent
MERGE statement join() on the key columns SAS MERGE matches on equality only and requires sorted inputs — a common source of double-counting
SAS macro Python function Macro variables become function arguments, not globals
FORMAT / INFORMAT Explicit casting in PySpark Currency, thousands separators and missing values need explicit handling
PROC FCMP Python function, packaged and tested User-defined formats and functions need real unit tests, not smoke tests
PROC REPORT BI tool, or aggregation in PySpark SAS’s dynamic report layout has no portable equivalent
PROC IMPORT / PROC EXPORT read_csv / write.parquet, or Glue ETL Encoding and delimiter handling differ

The MERGE case deserves a specific warning. In SAS, merging two datasets sorted by key produces one output row per matching key. A careless join() on the same data can produce a cartesian explosion that silently inflates every total downstream — and it will still reconcile at the row level if nobody checks the aggregate.

Stage 4 — Replace the scheduler

The SAS environment’s job scheduler becomes Airflow DAGs, or Step Functions where the workflow is simple. The Data Engineering Training programme covers Airflow DAG design, backfills and idempotency, and the AWS Data Engineering Training covers MWAA and Step Functions on AWS specifically.

The scheduling migration is where observability improves most. SAS job logs are famously opaque; an Airflow DAG with retry policy, backfill support and alerting is a genuine operational upgrade.

Stage 5 — Serve the results

Two paths, and they suit different consumers:

  • Amazon Athena for interactive SQL over the exported data. Cheap, serverless, and it reads the same Parquet files the pipeline writes. The Athena documentation covers query behaviour and the cost model is metered on bytes scanned.
  • Spark / Databricks when the serving logic needs Python, streaming or machine learning rather than SQL.

Stage 6 — Validate, then run in parallel

Do not switch over on faith. The validation harness that works:

  1. Row counts per table and per partition, old versus new
  2. Control totals — sums and counts of every numeric measure, compared with a tolerance that is agreed in advance and written down
  3. Spot-checked record-level diffs for a sample of keys, including the edge cases: nulls, zero-value rows, negative amounts, and late-arriving records
  4. A parallel run period where both systems produce the same output and the results are compared, not eyeballed
  5. A signed reconciliation memo per report, stating what was compared, the tolerance, and who signed it

For regulated reporting, the memo is not bureaucracy. It is the artefact that lets you answer “why does this number still match last year’s filing” three years later.

The cost story, honestly

Two structural differences, no vendor price claims needed:

SAS licensing scales with capacity you reserve. Core-based licensing means paying for a fixed processing capacity whether the nightly batch runs for twenty minutes or twenty hours. The cost profile is flat and predictable, and the bill grows when you add capacity for a periodic heavy run.

Cloud consumption scales with work done. A pipeline that runs for twenty minutes costs a fraction of one that runs for twenty hours, and the number is a line item you can measure rather than a licence you negotiated.

The honest caveat is that a cloud migration adds engineering cost — someone has to own the orchestration, the data quality and the cost tags. For an estate that has quietly grown to a large annual licence, that cost is usually recovered within a year or two. For a small estate with a modest renewal, it may never be. The decision is arithmetic, and the arithmetic needs the four inventories from earlier, not a benchmark.

Our Cloud Infrastructure Cost Benchmark 2026 covers cost per workload by service class and FinOps adoption across estates — the methodology for making that comparison defensible.

The hybrid pattern that actually works

Most organisations do not end up fully migrated, and that is usually the right outcome.

Layer Stays on SAS Moves to cloud
Complex actuarial and statistical models Yes —
Regulatory report formatting and submission artefacts Yes, initially —
Raw data landing and history — Yes
Data movement and transformation for reporting — Yes
Exploratory analysis and ad-hoc SQL — Yes
Consumption and dashboards — Yes
Scheduled orchestration — Yes

The pattern is: keep the part of the system that encodes genuine statistical expertise, and move the part that encodes data plumbing. The plumbing is where cloud economics and modern tooling help; the statistics are where the domain knowledge lives, and rewriting them adds risk without much benefit.

A well-run hybrid still needs the migration mechanics — Parquet exports, a catalogue, an orchestration layer, a validation harness — so this is not a way to avoid the work. It is a way to avoid the work that has no payoff.

What this means for a career in India

The combination is more valuable than either half.

SAS skills remain genuinely marketable in banking, insurance and healthcare in India, and SAS certification still carries weight — SAS’s certification programme covers the professional tracks, and the SAS Certified Programming training at SkilBrill covers the base programming path with SAS training in Chennai.

But the interesting position — and the one that gets hired fastest — is the engineer who can read SAS code, translate it into Spark SQL and PySpark, and design the lakehouse it lands in. That person is useful on day one of a migration, and their skills do not expire when the migration does.

The SAS Certified Programming course covers the base programming path in 12 weeks and 72 hours across eight modules, including the two-step data step and proc step model that this article’s translation table is built on. The AWS Data Engineering Training covers the destination side — S3, Glue, Redshift, Athena, Kinesis and orchestration — over the same 12-week structure. For the full platform-neutral picture, the Data Engineering Training spans 16 weeks and 96 hours across SQL, Python, Spark, Airflow, Kafka, Delta Lake, dbt and CI/CD.

Pay bands for the destination roles are in the AWS Data Engineering Salary Report 2026.

How to read these numbers

No pricing figures are quoted in this article, because SAS commercial terms are not public and cloud pricing varies by region and agreement. The structural comparison — reserved capacity versus metered consumption — is a property of the licensing models, not a price claim. Benchmark figures from our own reports are published with methodology and reproducible scripts.

Key terms

Term What it means in practice
SAS library A named collection of datasets under a directory structure, with formats and metadata attached.
DATA step The SAS language construct that reads, transforms and writes observations.
PROC step A procedure invoked for a specific task — statistics, sorting, reporting, exporting.
SAS/ACCESS The interface that lets SAS read and write external files and databases.
PROC FCMP User-defined functions in SAS, and the thing most likely to need a real rewrite.
Parquet The columnar file format the cloud stack reads natively, and the target for SAS exports.
Control total An agreed aggregate used to prove that a migrated figure matches the original.
Parallel run period A window where old and new systems both produce output for comparison.
Reconciliation memo The written record of what was compared, the tolerance and the sign-off.

Frequently asked questions

Is SAS being phased out?

Not as quickly as the vendor consolidation narratives suggest. SAS remains entrenched in regulated industries, and SAS Viya continues to be actively developed. What has changed is the direction of travel: cloud-native, open-table-format tooling has taken over the data platform layer, and new analytics work rarely starts on SAS. For a career, the read is that SAS skills remain employable in specific industries while new roles default to Spark, SQL and cloud services.

How long does a SAS to cloud migration take?

The honest answer is that it depends entirely on the code inventory, and that most published timelines are wrong because they were built before the PROC histogram existed. The data layer can move in weeks once the export path is established. The code layer scales with the number of distinct procedures and their complexity — the ones carrying real statistical logic take longest. The schedule and reporting layers are where the surprises live, because that is where the external contracts are.

Can SAS write directly to S3?

Yes. SAS’s EXPORT procedure writes Parquet and other formats directly to a cloud bucket path, and SAS/ACCESS covers reading and writing external data more broadly. The practical detail worth getting right at export time is type translation — dates stored numerically, missing-value sentinels and currency formats are the usual source of mismatches later.

Do we have to rewrite the SAS code?

Code that is data movement can often be replaced wholesale by a standard pipeline pattern. Code that carries genuine statistical or actuarial logic usually is worth keeping. The productive question is not “can we rewrite it” but “does this code represent domain knowledge we want to keep, or plumbing we want to remove” — and answering it per procedure is what turns a rewrite into a migration.

How do we prove the migrated numbers are correct?

Control totals with an agreed tolerance, checked per table and per report, plus a parallel run period with record-level spot checks on edge cases — nulls, zeros, negatives and late-arriving records. For anything that feeds a regulatory filing, write the reconciliation memo and get it signed. A migration that cannot prove its numbers is not finished.

Is it worth keeping SAS for actuarial work?

Usually yes. Actuarial models are a small number of procedures carrying a great deal of validated domain logic, and rewriting them adds risk while adding little. The parts worth moving are the data movement, the scheduling and the consumption layer around them.

What should a learner do with this?

Learn both halves in sequence rather than in parallel. SAS programming first, because the translation table only makes sense if you can read the source; then Spark SQL and PySpark, because the destination is where the demand is. The SAS certification course and the AWS Data Engineering course are structured to be taken in that order.

Where to take this next

Migration work is a data engineering job with a specific shape: inventory, translation, validation. Engineers who have done it once are in demand wherever legacy estates exist — which in India means banking, insurance and healthcare.

Start with the source language in the SAS Certified Programming course, then build the destination skills in the AWS Data Engineering Training and, if you want the platform-neutral version, the Data Engineering Training programme. All three run in classroom, live online and hybrid modes from Thoraipakkam, Chennai, with placement support across 200+ hiring partners.

References

Related Articles

Databricks Performance Optimization: Z-Ordering, Liquid Clustering and Stored Procedures

Databricks performance optimization: Databricks performance work is mostly table maintenance, not query tuning. Z-Ordering and liquid clustering both work by co-locating similar rows into the same files so that Delta can skip entire files using per-file statistics — which means the benefit depends entirely on file size, and the maintenance commands (OPTIMIZE, VACUUM) have real costs that should be scheduled deliberately. Stored procedures in Unity Catalog help on a different axis: they turn a sequence of steps into one callable unit, which removes repeated setup work and makes pipelines easier to govern.

Read more →

Azure Databricks vs AWS Databricks: Which Cloud Should You Choose?

Azure Databricks vs AWS Databricks: The two are the same platform. The Delta Lake format, the Spark runtime, Unity Catalog, the SQL warehouses, the notebook environment and the job scheduler are identical — what differs is the cloud perimeter around them: where the data sits, how events arrive, which identity and governance services you integrate with, and how your organisation already buys cloud. So the choice is rarely about Databricks capability. It is about which cloud your organisation has already committed to, which team owns the data, and whether a cross-cloud requirement already exists that would force the answer.

Read more →

Teradata to Databricks Migration: A Step-by-Step Guide

Teradata to Databricks migration: A Teradata to Databricks migration succeeds when you treat it as four separate workstreams — inventory, extraction, conversion and validation — rather than as a port. The data moves first and moves easily: Teradata tables extract to Parquet chunks in parallel and land in a Delta landing zone within days. The hard parts are the two things nobody budgets for: splitting high-volume tables into parallel extractable chunks without hammering the source, and proving the migrated numbers still tie out. Migrate one domain at a time, in parallel with the existing system, and cut over only after control totals match.

Read more →
SkilBrill Logo
Written by
· 16 min read