BookmarkSubscribeRSS Feed
haidarh29
Calcite | Level 5

Hi everyone,

 

I’m currently working on a SAS DI migration project from  SAS to Azure. The environment contains around 590 SAS DI jobs, which are used to create about 55 datamarts.

 

The challenge is that I have only read access to the SAS environment — no data access.

 

I’d like to ask for suggestions on the best approach to handle this kind of project:

  1.   Should I go through each job individually to identify impact analysis logic, dependencies, and mappings, then document         everything manually in Excel?  
  2. Or is there any better or more automated approach to extract and analyze SAS DI job logic and dependencies efficiently?
  3. What are the best practices or steps to follow for SAS DI to Azure migration.

Any guidance, tools, or practical tips from your experience would be greatly appreciated.

 

3 REPLIES 3
Patrick
Opal | Level 21

What do you mean by SAS to Azure? To which SAS version are you migrating to?
If this is about a SAS9.4 to SAS Viya migration then use SAS Content Assessment.

haidarh29
Calcite | Level 5

Actually, this is not a SAS 9.4 to SAS Viya migration.
We are migrating a SAS 9.4 on-prem DI environment to Azure where future ETL processes will be developed using Azure-based tools.

Since I have only read access (no data access), I wanted to ask:

 

Is there any automation or tool-based approach to extract job dependencies and logic from SAS DI?

Or any recommended way to directly move or replicate SAS DI jobs into Azure using migration utilities or frameworks?

Any insights or experiences on large-scale SAS DI to Azure migration would be really helpful.

Patrick
Opal | Level 21

"We are migrating a SAS 9.4 on-prem DI environment to Azure where future ETL processes will be developed using Azure-based tools"

So are you initially migrating from a on-prem SAS 9.4 to an Azure cloud based SAS 9.4 or is this from start about replacing SAS 9.4 with something else like Databricks?

 

A SAS 9.4 on-prem to SAS 9.4 Azure migration is certainly very doable and there are SAS provided tools & scripts that can support such a migration.

 

A replacement of SAS 9.4 is a totally different story and will require much more planning. If you search a bit then you'll find 3rd party providers who offer automation tools. I don't know though how much their claims match reality.

With the rapid growth of AI there might be tools in the not so far future which will make such migration much easier. Right now it's from what I know still a labour intensive and costly exercise that will require very good planning and the right people for it not to fail.

 

job dependencies

You should be able to derive this from the scheduler used. Or you could also use the information which output table from one job get used as input tables by another job. With DIS AND if the tables got actually registered in SAS metadata that's something you could work out scripted via SAS Metadata queries.

 

and logic from SAS DI

Well: DIS is used to define jobs but it's the DIS generated SAS code that actually gets executed. And it's not uncommon that not all DIS steps are fully metadata driven but are just using manually created SAS code in first place. You would need to analyse both the SAS DIS metadata and the generated SAS code to fully derive the logic - and that requires good SAS skills to do efficiently.

Catch up on SAS Innovate 2026

Nearly 200 sessions are now available on demand with the SAS Innovate Digital Pass.

Explore Now →
How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 3 replies
  • 1466 views
  • 0 likes
  • 2 in conversation