SAS Migrations: Top 3 Lessons
Whales evolved from a common ancestor shared with the Hippopotamus. Evolution chose to keep vestigial legacy of this ancient ancestor’s hip bones. If this evolutionary biology strategy works in nature, could we also apply it as part of a SAS migration?
If you attended the Databricks hosted migrations event last month, you already know that my colleague Oleg Mikhov and I think that the “whale hips” analogy is worthy of serious consideration (see lesson #2). For everyone else, read on to learn about the top three lessons we discussed about migrating SAS environments to a modern analytics platform.
Lesson #1: Ride the waves and avoid bangs
Insurance companies are all about providing assurances and piece of mind. However, at one large insurance enterprise we recently worked with, the initial mood was one closer to trepidation and anxiety once they started to take an inventory of their SAS projects to be migrated. They counted more than 10,000 Enterprise Guide projects, which were constantly in flux as part of daily operations.
To help wrangle this migration and reduce project risk, the migration was split into progressive stages, which included individual waves of script and project migrations. This helped the team to see results quicker, while learning to be more efficient about subsequent stages.
Stages and waves might sound obvious as a good risk mitigating strategy, but the challenge is quickly identifying isolated groups of scripts and projects that are good candidates for migrating at the same time.
In previous engagements, we gathered information through interviews of end users and administrators. This proved to be highly time consuming, and often even end users didn’t have a complete picture of the environment’s utilization.
We learned that extracting the SAS metadata about the projects and scripts was a preferred approach. This allowed us to take a more detailed inventory of projects, and analyze them with tools like Excel to determine the best migration strategy.
T1A’s “Alchemist” visual analyzer (GetAlchemist.io)
More recently, SAS customers such as the aforementioned insurance company have been able to enjoy specialized visual analysis tools that produce a live and visually explorable view of SAS projects. A visual tool allows the team to identify “islands” of projects and their related data sources. When enabled, a “data lineage view” further simplifies migration wave candidate selection by highlighting common data sources.
Lesson #2: Coexistence
As our whale hips analogy suggests, sometimes it makes sense to maintain legacy systems in place (at least temporarily). For the whale, this meant minimizing, but not completely eliminating the legacy hip bones. For your analytics environment, there are two coexistence strategies that we have learned work for SAS clients: bi-directional data sharing, and integrated workflows.
The pair of architecture patterns allow existing SAS projects to continue to be executed without code conversion for a transitory period. Both options can help mitigate project migration risk by isolating the two bulkiest parts of the migration: (1) data migration (2) SAS code conversion.
The number one reason that SAS clients either of these coexistence architectures has nothing to do with technology or even project risk. Overwhelmingly, we’re asked to implement one of these architecture patterns because of the makeup of team structures and their skill sets; someone who has written SAS code for the majority of their career needs a steady glide path to transition to modern open source languages like Python.
Lesson #3: Code Conversion Strategies
Armed with automated SAS migration tools, we assumed that all clients looking to migrate off of SAS would be enthusiastic adopters. However, based on the recent experiences with a media company (top graphs below) and a European bank (bottom graphs below), automated code conversion is not always the preferred strategy.
Two SAS clients with two different approaches to SAS code conversion automation
Both SAS clients wanted to take the migration project as a unique opportunity to clean-up unused projects by retiring a significant amount of scripts. Where they differed is where and when they chose to apply automated code conversion. For the European bank, they saw value in rewriting the majority of projects in order to help build experience for team members with modern languages and platforms. Conversely, the media company was focused on using automation to reduce migration costs, while maintaining a small contingent of projects for manual re-writing.
Looking to learn more about the latest SAS Migration tools? Visit GetAlchemist.io to learn about more best practices, visualization tools and transpiler conversion tools that “understand” SAS code for higher-quality converted code.
