SAS in Federal Government: Migration Guide¶

Audience: Federal CIOs, CDOs, Agency Analytics Directors, CISO/ISSO Purpose: Federal-specific guidance for migrating SAS analytics workloads to Azure, including agency-specific considerations, FedRAMP compliance, SAS Viya on Azure Gov, and regulatory requirements for statistical agencies.

1. SAS in the federal landscape¶

SAS is more deeply embedded in the US federal government than in any other sector. The investment spans decades and touches the most critical statistical and analytical operations in government:

1.1 Agency SAS usage map¶

1.2 Federal SAS spending estimate¶

2. SAS Viya on Azure Government¶

2.1 Authorization status (January 2026)¶

SAS Viya achieved FedRAMP High authorization on Azure Government in January 2026. This is a joint authorization --- SAS Viya running on Azure Government infrastructure inherits Azure Government's FedRAMP High P-ATO and adds SAS-specific controls.

2.2 Deployment regions¶

2.3 Network architecture for Azure Gov¶

flowchart TB
    subgraph GOV["Azure Government Boundary (FedRAMP High)"]
        subgraph VNET["Agency VNet"]
            AKS[SAS Viya on AKS]
            ANF[Azure NetApp Files]
            PG[(PostgreSQL)]
        end
        subgraph FABRIC["Fabric (Gov)"]
            ONELAKE[OneLake]
            PBI[Power BI]
        end
        subgraph ML["Azure ML"]
            AML[Azure ML Workspace]
            MLFLOW[MLflow]
        end
        subgraph GOV_SVC["Governance"]
            PURVIEW[Purview]
            ENTRA[Entra ID]
            KV[Key Vault]
        end
    end

    AKS --> |SAS on Fabric| ONELAKE
    AKS --> ANF
    AKS --> PG
    ONELAKE --> PBI
    ONELAKE --> AML
    AKS --> ENTRA
    AKS --> KV

3. Compliance requirements by agency type¶

3.1 Statistical agencies (Census, BLS, BEA, NCHS, NASS)¶

Statistical agencies have the most complex migration requirements due to Title 13/26 confidentiality requirements and the need for statistical disclosure limitation.

Recommendation for statistical agencies: Hybrid approach. Keep SAS for Title 13/26 production systems during a 3--5 year transition. Build new capabilities on Azure. Migrate reporting and exploratory analysis first.

3.2 Regulatory agencies (FDA, SEC, CFPB)¶

Recommendation for regulatory agencies: Maintain SAS for active FDA/SEC submissions. Build new analytical capabilities on Azure ML. Plan SAS phase-out over 3--5 years as R pharmaverse matures and FDA acceptance broadens.

3.3 Defense and intelligence (DoD, VA, DHS)¶

Recommendation for DoD: Deploy SAS Viya on Azure Gov for unclassified analytics (IL4/IL5). Build new capabilities on Azure ML + Fabric. Classified analytics remain on-premises or on dedicated classified cloud.

3.4 Health agencies (HHS, CDC, VA, NIH)¶

Recommendation for health agencies: Migrate reporting (SAS VA to Power BI) and data management (SAS DI to ADF/dbt) first. Retain SAS for clinical trial analysis. Deploy csa-inabox with HIPAA controls from examples/tribal-health/ as a reference.

4. FISMA requirements for analytics platforms¶

Every federal analytics platform must be covered by a System Security Plan (SSP) under FISMA. When migrating from SAS to Azure, the analytics platform boundary changes:

4.1 System boundary changes¶

4.2 ATO timeline considerations¶

Recommendation: Start the ATO conversation early (Phase 0 of migration). Engage the ISSO and authorizing official before technical deployment begins. Azure Gov's FedRAMP High P-ATO significantly reduces the control assessment burden.

5. Procurement guidance¶

5.1 SAS contract transition¶

Federal SAS contracts are typically structured as:

• Enterprise Agreement (EA): Multi-year (3--5 year) agreements with annual payments
• GSA Schedule 70: Per-product licensing through GSA
• SEWP V: Available through SEWP contracts
• Blanket Purchase Agreement (BPA): Agency-specific BPAs with SAS resellers

Key actions for contract transition:

1. Review termination clauses. Most SAS EAs require 12--24 months notice for non-renewal
2. Negotiate step-down pricing. As products are replaced, request reduced licensing for remaining products
3. Avoid auto-renewal traps. SAS EAs often auto-renew unless explicitly terminated within the notice window
4. Document usage data. SAS license audits can result in true-up charges; document actual usage to negotiate down
5. Consider maintenance-only. Some agencies can drop to maintenance-only (no new features) at 20--25% of license cost during migration

5.2 Azure procurement vehicles¶

5.3 Budget planning¶

6. Agency-specific migration playbooks¶

6.1 Statistical agency playbook (Census, BLS, BEA pattern)¶

6.2 Regulatory agency playbook (FDA, SEC pattern)¶

6.3 Defense agency playbook (DoD, DHS pattern)¶

7. Risk management¶

7.1 Migration risks specific to federal¶

7.2 Rollback plan¶

If migration fails or is paused:

1. SAS Viya on Azure remains operational --- programs continue running unchanged
2. Data in Fabric lakehouses accessible to both SAS and Python --- no data loss
3. SAS licensing can be reinstated --- contact SAS account team for relicensing
4. Azure consumption can be scaled down --- pause Fabric capacity, stop Azure ML compute
5. Python notebooks preserved in Git --- no code loss; resume migration when ready

8. Federal success patterns¶

8.1 What works¶

• Start with Power BI --- lowest risk, highest visibility, builds organizational confidence
• Involve statisticians early --- they are the domain experts; their buy-in is essential
• Run dual systems for 3--6 months --- prove Python output matches SAS before decommissioning
• Use SAS on Fabric bridge --- unifies data layer; allows incremental migration
• Budget for reskilling --- 4--8 weeks of Python training per SAS programmer; invest in the workforce

8.2 What fails¶

• Big-bang migration --- trying to convert all SAS programs simultaneously; too much risk
• Skipping validation --- comparing only a few outputs; errors discovered in production
• Ignoring survey/clinical specialists --- their requirements are real and non-negotiable
• Underestimating SAS macro complexity --- decades of macro libraries; each one must be analyzed
• Forgetting ATO --- technical migration succeeds but cannot go to production without authority to operate

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