SAS Lift-and-Shift Migration: SAS on Azure¶

Audience: SAS Administrators, Platform Engineers, Infrastructure Architects Purpose: Deploy SAS Viya or SAS Grid on Azure infrastructure without modifying SAS programs. This guide covers SAS Viya on AKS, SAS Grid on Azure VMs, certified VM sizes, storage configuration, performance tuning, and integration with Microsoft Fabric.

1. Overview¶

A lift-and-shift migration moves SAS workloads from on-premises infrastructure to Azure without rewriting SAS programs. SAS programs, macros, format catalogs, and data all move intact. The value is in eliminating data-center risk, gaining cloud elasticity, and positioning for future incremental migration to Azure-native analytics.

Two primary deployment models:

2. SAS Viya on AKS deployment¶

2.1 Architecture¶

flowchart TB
    subgraph AKS["Azure Kubernetes Service"]
        subgraph CAS["CAS (Cloud Analytic Services)"]
            CAS_CTRL[CAS Controller]
            CAS_WORK[CAS Workers x N]
        end
        subgraph COMPUTE["SAS Compute"]
            SAS_PROG[SAS Programming Runtime]
            SAS_BATCH[SAS Batch Server]
            SAS_CONNECT[SAS/CONNECT]
        end
        subgraph WEB["Web Tier"]
            SAS_STUDIO[SAS Studio]
            SAS_VA[SAS Visual Analytics]
            SAS_DRIVE[SAS Drive]
        end
        subgraph INFRA["Infrastructure"]
            SAS_CONSUL[Consul]
            SAS_RABBIT[RabbitMQ]
            SAS_CACHE[Redis]
        end
    end

    subgraph STORAGE["Persistent Storage"]
        ANF[Azure NetApp Files]
        ADLS[ADLS Gen2]
        PG[(Azure Database for PostgreSQL)]
    end

    subgraph FABRIC["Microsoft Fabric"]
        ONELAKE[OneLake Lakehouses]
    end

    CAS_CTRL --> ANF
    CAS_WORK --> ANF
    SAS_PROG --> ANF
    CAS_CTRL --> ADLS
    PG --> SAS_CONSUL
    CAS_CTRL --> ONELAKE

    style FABRIC fill:#e6f3ff

2.2 Prerequisites¶

• SAS Viya license: SAS Viya 4.x with Cloud-Native Architecture (CNA) deployment entitlement
• SAS software order: Download SAS Viya deployment assets from my.sas.com
• Azure subscription: Azure Government (for federal) or Azure Commercial
• Container registry: Azure Container Registry (ACR) for SAS container images
• DNS: Private DNS zone for internal service resolution
• Certificates: TLS certificates for SAS web applications

2.3 Certified Azure VM sizes¶

SAS certifies specific Azure VM families for Viya workloads:

AKS cluster sizing (medium deployment, 50--100 users):

2.4 Storage configuration¶

Azure NetApp Files (ANF) is the recommended shared storage for SAS Viya:

ADLS Gen2 for integration with Fabric and long-term data storage:

# Storage account configuration
storage_accounts:
    - name: sasstorage{env}
      sku: Standard_LRS
      kind: StorageV2
      hierarchical_namespace: true
      containers:
          - name: sasdata
            access: private
          - name: sasbackup
            access: private
          - name: saswork
            access: private

Azure Database for PostgreSQL Flexible Server for SAS Infrastructure Data Server:

2.5 Network configuration¶

# Virtual network design for SAS Viya on AKS
vnet:
    name: vnet-sas-{env}
    address_space: 10.100.0.0/16
    subnets:
        - name: snet-aks-system
          cidr: 10.100.0.0/22 # 1,024 IPs for system pods
        - name: snet-aks-cas
          cidr: 10.100.4.0/22 # 1,024 IPs for CAS pods
        - name: snet-aks-compute
          cidr: 10.100.8.0/22 # 1,024 IPs for compute pods
        - name: snet-anf
          cidr: 10.100.16.0/24 # ANF delegated subnet
        - name: snet-postgres
          cidr: 10.100.17.0/24 # PostgreSQL delegated subnet
        - name: snet-pe
          cidr: 10.100.18.0/24 # Private endpoints (ADLS, ACR, KV)

2.6 SAS Deployment Operator¶

SAS Viya 4.x deploys via the SAS Deployment Operator on Kubernetes:

# 1. Create AKS cluster
az aks create \
  --resource-group rg-sas-prod \
  --name aks-sas-prod \
  --kubernetes-version 1.28 \
  --network-plugin azure \
  --network-policy calico \
  --vnet-subnet-id /subscriptions/.../snet-aks-system \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --enable-managed-identity \
  --enable-workload-identity \
  --attach-acr acrsasprod

# 2. Add node pools
az aks nodepool add \
  --resource-group rg-sas-prod \
  --cluster-name aks-sas-prod \
  --name cas \
  --node-count 1 \
  --node-vm-size Standard_E32ds_v5 \
  --vnet-subnet-id /subscriptions/.../snet-aks-cas \
  --labels workload.sas.com/class=cas \
  --node-taints workload.sas.com/class=cas:NoSchedule

az aks nodepool add \
  --resource-group rg-sas-prod \
  --cluster-name aks-sas-prod \
  --name compute \
  --node-count 2 \
  --max-count 10 \
  --node-vm-size Standard_D16ds_v5 \
  --vnet-subnet-id /subscriptions/.../snet-aks-compute \
  --enable-cluster-autoscaler \
  --labels workload.sas.com/class=compute \
  --node-taints workload.sas.com/class=compute:NoSchedule

# 3. Install cert-manager (required by SAS)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.0/cert-manager.yaml

# 4. Install SAS Deployment Operator
kubectl apply -f sas-bases/overlays/deploy-operator/

2.7 Performance tuning¶

3. SAS Grid on Azure VMs¶

For organizations running SAS 9.4 that are not ready for SAS Viya:

3.1 VM sizing¶

3.2 Storage layout¶

4. SAS on Fabric integration¶

The December 2025 SAS on Fabric integration enables SAS Viya to read and write directly to Fabric OneLake lakehouses.

4.1 Configuration¶

/* Configure SAS to read/write Fabric lakehouses */
/* Requires SAS Viya 2025.12+ with Fabric connector */

/* Read from Fabric lakehouse */
libname fabric_lh sasfabric
  workspace="analytics-prod"
  lakehouse="sales_lakehouse"
  authentication=entra_id;

/* Use Fabric lakehouse tables in SAS programs */
proc means data=fabric_lh.fact_sales n mean sum;
  class region product_category;
  var revenue quantity;
run;

/* Write results back to Fabric lakehouse */
data fabric_lh.sales_summary;
  set work.summary_output;
run;

4.2 Architecture with Fabric¶

flowchart LR
    subgraph SAS["SAS Viya on AKS"]
        SAS_PROG[SAS Programs]
        SAS_CAS[CAS Engine]
    end

    subgraph FABRIC["Microsoft Fabric"]
        ONELAKE[OneLake]
        LH[Lakehouse Tables]
        PBI[Power BI Reports]
        NOTEBOOKS[Fabric Notebooks]
    end

    subgraph AML["Azure ML"]
        MLFLOW[MLflow Registry]
        ENDPOINTS[Managed Endpoints]
    end

    SAS_PROG --> |Read/Write via connector| ONELAKE
    SAS_CAS --> |Load from| ONELAKE
    ONELAKE --> LH
    LH --> PBI
    LH --> NOTEBOOKS
    NOTEBOOKS --> MLFLOW
    MLFLOW --> ENDPOINTS

    style FABRIC fill:#e6f3ff

4.3 Data flow patterns¶

5. Migration steps (lift-and-shift)¶

Phase 1: Assessment (2 weeks)¶

1. Inventory SAS servers: CPU, memory, storage, OS version
2. Catalog SAS software: products, hot fixes, custom configurations
3. Map storage: SAS data libraries, format catalogs, macro libraries, autoexec files
4. Identify external dependencies: database connections, file shares, FTP endpoints
5. Document scheduling: Platform LSF jobs, cron jobs, SAS Management Console schedules

Phase 2: Azure infrastructure (2--3 weeks)¶

1. Deploy Azure networking (VNet, subnets, NSGs, private endpoints)
2. Deploy AKS cluster (for Viya) or Azure VMs (for SAS 9.4)
3. Deploy Azure NetApp Files volumes
4. Deploy Azure Database for PostgreSQL (for Viya)
5. Deploy Azure Container Registry (for Viya)
6. Configure Entra ID integration (LDAP or SAML)

Phase 3: SAS deployment (2--3 weeks)¶

1. Build SAS Viya container images in ACR (or install SAS 9.4 on VMs)
2. Deploy SAS using the SAS Deployment Operator (or SAS Deployment Wizard)
3. Configure SAS to use ANF storage
4. Configure SAS to use Azure PostgreSQL
5. Apply SAS hot fixes and updates

Phase 4: Data migration (1--3 weeks)¶

1. Copy SAS datasets (SAS7BDAT) to ANF volumes using AzCopy or rsync
2. Copy SAS format catalogs and macro libraries
3. Copy autoexec.sas, sasv9.cfg, and custom configuration files
4. Validate file permissions and ownership

Phase 5: Validation (2 weeks)¶

1. Run SAS program regression test suite
2. Compare output between on-premises and Azure
3. Performance benchmark (see Benchmarks)
4. User acceptance testing
5. Load testing with concurrent users

Phase 6: Cutover (1 week)¶

1. Final data sync (delta)
2. DNS cutover (point SAS URLs to Azure)
3. Update client configurations (SAS Enterprise Guide, SAS Studio URLs)
4. Disable on-premises SAS servers
5. Monitor for 48 hours

6. Federal considerations¶

6.1 SAS Viya on Azure Government¶

As of January 2026, SAS Viya is available on Azure Government with FedRAMP High authorization:

6.2 Deployment regions¶

7. Cost estimation (lift-and-shift)¶

For a medium deployment (50--100 users, 20 TB SAS data):

Key savings vs on-premises: Eliminates data-center costs (\(150K--\)300K/year for hardware, power, cooling, space). Net savings of \(0--\)150K/year depending on current infrastructure costs. The strategic value is in positioning for future Azure-native migration and gaining cloud elasticity.

8. Next steps after lift-and-shift¶

Once SAS is running on Azure, the organization is positioned for incremental migration:

1. Connect SAS to Fabric --- Use SAS on Fabric connector to share data between SAS and Azure-native services
2. Deploy Power BI --- Replace SAS Visual Analytics with Power BI (lowest-risk first step)
3. Deploy ADF + dbt --- Replace SAS Data Integration Studio
4. Pilot Python analytics --- Convert 5--10 SAS programs to validate the approach
5. Reduce SAS licensing --- As capabilities move to Azure-native, reduce SAS product licenses

See Analytics Migration, Data Management Migration, and Reporting Migration for the next phases.

Maintainers: csa-inabox core team Last updated: 2026-04-30