The Migration Toolkit: 3 Ways to Move SAS Formats to Viya

In Part 1, we diagnosed the “Split-Brain” condition affecting many SAS Viya environments: the architectural disconnect between the legacy Compute Server (which relies on disk-based catalogs) and the modern CAS engine (which demands in-memory libraries).

Diagnosing the problem is one thing; fixing it is another.

If you try to simply copy-paste your old .sas7bcat files from your SAS 9 server to your new Viya environment, you are likely in for a rude shock. Best case? They don’t load. Worst case? You get “mojibake“—garbled characters that turn your clean data into nonsense.

In Part 2, we are opening the migration toolkit. Here are the three specific techniques you need to move your formats safely into the modern era.

Trap #1: The Encoding Barrier (WLatin1 vs. UTF-8)

Before we even talk about CAS, we have to talk about physics.

Most legacy SAS 9 installations (especially on Windows) operate in WLatin1 encoding. SAS Viya is a UTF-8 native platform. This isn’t just a setting change; it’s a fundamental difference in how characters are stored.

A character like ‘é’ takes up 1 byte in WLatin1. In UTF-8, that same character requires 2 bytes.

If you physically copy a format catalog from Windows to Linux, the SAS kernel might read the header, but as soon as it hits a special character, the byte alignment shifts. The result is truncation or errors.

The Fix: The Transport Pattern (PROC CPORT)

Do not use operating system commands (like cp or scp) to move catalogs. You must use SAS’s internal transport mechanism to neutralise the encoding difference.

Step 1: On your SAS 9 Server (Source)
Export your catalog to a transport file.

libname myfmt "C:\sas\formats";
proc cport lib=myfmt file="C:\temp\formats.cpt";
run;

Step 2: On your SAS Viya Compute Server (Target)
Import the file. The PROC CIMPORT procedure automatically detects the encoding mismatch and expands the bytes (Transcoding) to create a valid UTF-8 catalog.

proc cimport lib=work file="/data/formats/formats.cpt";
run;

Trap #2: The CAS Incompatibility

Now you have a working catalog on your Compute Server. Great! But as we learned in Part 1, CAS cannot read it.

To get these formats into the high-speed analytics engine, you need to transform them. You have three main routes, depending on your operational style.

Route A: The Batch Bridge (PROC FMTC2ITM)

If you have massive legacy batch processes, this procedure is your best friend. FMTC2ITM (Format Catalog to Item Store) reads a standard catalog and packages it into an Item Store.

While CAS can’t read catalogs, it has been optimised to read Item Stores.

proc fmtc2itm catalog=work.formats store="/data/cas/formats.itemstore";
run;

Once created, this Item Store can be loaded into CAS using the cas.addFmtLib action. This is often the fastest way to “lift and shift” without rewriting code.

Route B: The Programmer’s Shortcut (CNTLOUT / CNTLIN)

If you prefer to stay within the comfort of standard SAS code, you can use the classic “Control Data Set” method. This is often the most intuitive method for developers who have been managing formats for years.

The Workflow:

1. Export your legacy catalog to a SAS dataset using CNTLOUT=.
2. Import that dataset directly into CAS using CNTLIN= combined with the CASFMTLIB= option.

/* Step 1: Unpack the catalog to a dataset */
proc format lib=work.formats cntlout=work.myfmt_data;
run;

/* Step 2: Load the dataset into CAS */
cas casauto;

proc format cntlin=work.myfmt_data casfmtlib="HR_Formats";
run;

This method essentially “replays” your format definitions directly into the CAS memory, bypassing the need for physical item store files.

Route C: The DevOps Way (The sas-viya CLI)

For the modern administrator, we recommend moving away from binary files entirely where possible. The SAS Viya Command Line Interface (CLI) allows you to manage formats as code or data.

This is the “Formats as Data” paradigm. Instead of maintaining a SAS program, you can maintain a simple CSV file of your codes and labels.

The Workflow:

1. Maintain a CSV file (codes.csv) in your Git repository.
2. Use the CLI to ingest it directly into CAS.

sas-viya cas format-libraries add-format csv \
  --server cas-shared-default \
  --format-library HumanResources \
  --source-path /data/formats/codes.csv

This method is superior for governance because your source of truth is a human-readable text file, not a locked binary.

What’s Next?

You now have the tools to move formats:

1. CPORT/CIMPORT to safely cross the encoding bridge.
2. FMTC2ITM or CNTLOUT/CNTLIN to load them into CAS.
3. CLI to modernise your workflow.

But running these commands manually every time a format changes is a recipe for disaster. In the final instalment of this series, we will bring it all together.

Coming up in Part 3: We will design the “Golden Standard” workflow – a Synchronised Dual-Target Deployment pipeline that uses CI/CD to update both Compute and CAS simultaneously, ensuring you never face the “split-brain” problem again.