Targets
Warehouses
Runtimes
Before migration
After migration
DATA step and macros parsed structurally. Emitted as Spark jobs on EMR or Glue, landing on S3. MWAA replaces the SAS scheduler.
Deterministic parsers read the SAS estate and emit native AWS code, not SAS on an EC2 instance.
SAS programs → SAS2PY parser → Spark + S3 + Glue
SAS2PY Parser
Deterministic parse
AI where it helps
MigryX AI handles the logic parsers cannot resolve alone, and every change it makes goes through the same parity checks. It runs on a model you approve, air-gapped if your estate requires it.
The license follows you. The overnight window follows you. We emit Spark that reads S3.
Parsed schemas become Glue tables. Lineage is a catalog, not a comment.
MWAA or Step Functions take the schedule. The 36-node Grid is gone.
A SAS libname plus a DATA step filter, emitted as Spark reading a Glue table on S3.
/* SAS */ libname dw 'sasdata'; data gold; set dw.txn; if amount > 1000; run;
# libname → Glue / S3
gold = (
spark.table("dw.txn")
.filter("amount > 1000")
)
gold.write.format("delta").save("s3://lake/gold")
The SAS library is a catalog entry. The filter is a DataFrame predicate.
| SAS | AWS | Notes |
|---|---|---|
| DATA step | PySpark on EMR / Glue | Set-based |
| PROC SQL | Spark SQL / Athena | Same joins |
| SAS dataset | S3 + Iceberg / Delta | Object storage |
| SAS Grid | MWAA / Step Functions | Scheduler |
| Macro | Expanded then emitted | No leftover SAS |
SAS output compared to AWS output: row by row, column by column. Differences flagged before sign-off.
See how Data Matching works →28 regulated enterprises, including six global systemically important banks, have modernized with MigryX. Customer names are shared under NDA in a demo, with reference calls on request.
See all engagements →