SAS 9.4 to Viya Migration: A CTO's Playbook

Every SAS 9.4 estate eventually faces the same conversation: vendor support timelines are moving toward Viya, the internal roadmap has a migration line item nobody wants to own, and the platform team is quietly hoping the problem waits another budget cycle. It doesn't get easier by waiting. It gets larger, because the code, the job dependencies, and the number of downstream consumers relying on SAS output all keep growing in the meantime.

This is the playbook we use before touching a single migration script. It's less about the target architecture (Viya's capabilities are well documented) and much more about sequencing, risk classification, and protecting business continuity through a transition that, done badly, can quietly break reports nobody notices are wrong until an audit does.

Start with an inventory, not an architecture diagram

The instinct on most migration programmes is to start designing the target state. Resist it. The first deliverable should be a complete inventory of every SAS job, macro, and stored process in the current environment, tagged against three questions:

• What business process depends on this job, and who owns it?
• What is the blast radius if this job breaks or produces a subtly wrong result?
• Does this job use syntax, procedures, or integrations that don't port cleanly to Viya?

On a decade-old SAS 9.4 estate, this inventory routinely surfaces jobs nobody currently on the team can explain: code with no documented owner, feeding a report someone in finance has quietly relied on for years. Finding these before migration is inconvenient. Finding them after is a production incident.

Classify before you migrate

Once the inventory exists, we sort it into three tiers, and each tier gets a different migration treatment rather than one uniform approach:

• Tier 1: Direct port. Standard SAS syntax with no legacy procedure dependencies. These migrate with automated conversion tooling and light validation.
• Tier 2: Rework required. Jobs using procedures or macros with no direct Viya equivalent. These need engineering time, not just conversion tooling, and should be scheduled early because they're where timelines usually slip.
• Tier 3: Re-architect. Jobs whose approach was shaped by SAS 9.4's constraints rather than genuine business logic. These are candidates to be rebuilt using Viya-native capability rather than ported as-is.

The migrations that fail on timeline almost always fail because Tier 2 and Tier 3 work was estimated at Tier 1 speed.

Protect continuity with parallel runs, not a cutover weekend

For any reporting function with regulatory or audit exposure (risk, AML, financial close), a single cutover weekend is the wrong risk model. We run the legacy and target environments in parallel, producing the same outputs side by side, for long enough that discrepancies surface and get root-caused before the legacy environment is switched off. It's slower on paper. It's dramatically faster in practice, because it removes the scenario where a wrong number reaches a regulator before anyone notices the migration introduced it.

Infrastructure decisions that are easy to get wrong

Viya 4's Kubernetes-native architecture is a genuine capability upgrade, but it changes the operational model enough that infrastructure teams used to SAS 9.4's Grid Manager approach need real ramp-up time, not a weekend of documentation. The decisions worth getting right early:

• Sizing for peak, not average. Kubernetes autoscaling helps, but SAS workloads at month-end or quarter-end close still need deliberate capacity planning. Don't assume autoscaling alone will absorb a 10x batch spike.
• SSO/IWA integration early, not at the end. Authentication integration issues are consistently the thing that delays a go-live date after everything else is ready.
• On-premise vs. cloud vs. hybrid changes licensing, HA design, and DR strategy: decide this before, not during, the technical build.

The migration is also an opportunity to retire technical debt, selectively

There's a temptation to use a platform migration as cover for a much broader modernisation effort: rebuilding reports, changing data models, consolidating business logic that's drifted out of sync across teams. Resist scope creep here as firmly as you resisted jumping straight to architecture. A migration with a fixed, well-understood scope succeeds. A migration that quietly becomes a full digital transformation programme usually doesn't hit its date, and the platform risk (unsupported SAS 9.4 in production) is the one that actually has a clock on it.

What a realistic timeline looks like

For a mid-to-large enterprise SAS 9.4 estate with regulatory reporting dependencies, a defensible timeline typically runs inventory and classification (4-8 weeks), Tier 1 migration and validation (running in parallel with Tier 2/3 planning), Tier 2/3 rework, and a parallel-run window sized to the reporting cycle that matters most, often a full quarter-end or year-end cycle for finance and risk workloads. Compressing this because a deadline looks aggressive on a slide is the single most common cause of migrations that go live and then spend the next two quarters fixing discrepancies in production.

The short version

Inventory before architecture. Classify before you estimate. Parallel-run before you cut over. And treat the timeline compression request from a steering committee as a risk to be managed, not a target to be hit at any cost. Every migration we've run that stayed disciplined on these four points has gone live without a reporting blackout, and more importantly, without a wrong number quietly reaching a regulator.