SAS has been a central component of the analytics infrastructure in many organizations for years. However, rising license costs, the shift toward cloud infrastructure, and the need for greater flexibility and future readiness are prompting many companies to re-evaluate their SAS environment.
Alternatives such as programming languages (e.g., Python, R) and modern cloud data platforms (e.g., Databricks, Microsoft Fabric) are moving into focus—depending on the target architecture and strategic direction.
At the same time, migration is complex: in addition to technical challenges, organizations must consider processes, data quality, regulatory requirements, and acceptance by business users.
This article presents ten common mistakes from real-world projects—and how to avoid them. The recommendations are based on our experience from more than 6,000 person-days in SAS migration initiatives, especially in regulated industries such as pharma, insurance, and manufacturing.
Without a well-defined target state, migration efforts often stall or go in circles. "Moving away from SAS" is not a strategy. There needs to be a clear answer to the question: what should the new system deliver—for which user groups, under what technical and business conditions?
Best Practice: Develop the target architecture together with IT, business departments, and the enterprise architecture team—ideally within a structured assessment process.
SAS often contains implicit workarounds, manual data manipulation, and hidden dependencies. These become visible during migration and can cause major challenges.
Best Practice: Process quality starts with data quality—automated, reproducible, and transparent. Metadata and data flows should also be documented.
SAS migration is not just a technical project. If business departments are only brought in for testing or sign-off, this can lead to low acceptance, frustration, and inefficient workarounds in the new system.
Best Practice: Involve business users from the very beginning through showcases, interviews, and co-creation workshops. Focus on their goals and processes.
Switching to new tools requires new skills. Without structured enablement, many potentials remain untapped.
Best Practice: Develop a training concept early: role-based, practical, and designed for sustainable knowledge transfer.
Simply translating SAS code to another language or platform rarely leads to real improvements. Legacy complexity is often carried over unchanged.
Best Practice: Use migration as an opportunity for modernization: streamline processes, introduce standards, and establish self-service analytics.
Some companies migrate their existing SAS workloads directly to the cloud—e.g., SAS Viya on Azure or AWS—expecting quick value without major changes. But the move to SAS Viya is not a classic lift & shift. While SAS programs may technically migrate, the new architecture requires a different mindset—especially regarding infrastructure, interfaces, and integration.
SAS Viya introduces an entirely new architectural concept. Local file systems, shell commands, or direct integrations with external systems (e.g., SharePoint, email servers, network drives) often need to be rethought and re-implemented.
Those trying to replicate the SAS 9 environment one-to-one in the cloud risk being unable to fully map critical processes—or having to accept functional limitations.
Best Practice: Don’t treat the migration as just an infrastructure project, but as strategic refactoring. Analyze dependencies early, identify functionalities that work differently in Viya, and determine which features may no longer be available. Leveraging the cloud platform’s possibilities can enhance performance, enable flexible scaling, and optimize costs in the long run.
Cloud migration is not automatic success—it’s a chance for sustainable modernization.
Many projects begin before it is clear which technologies they are migrating to. This leads to inconsistent architecture decisions, increased implementation effort, and uncertainty within the team.
A common mistake is to decide during the migration whether to use Python scripts, a low-code platform like Dataiku, or an analytical data platform like Snowflake.
Best Practice: Make the platform decision consciously and early—not in the middle of the project. Differentiate between:
Key questions:
The platform decision shapes architecture, skills, governance, and future flexibility—and should therefore be made strategically, not based on individual tool preferences.
SAS programs are often deeply nested, contain complex business logic, and have grown historically—often with little documentation. Still, test strategies are frequently neglected when replatforming or migrating to SAS Viya.
This poses risks: without proper testing, it’s hard to detect re-implementation errors, which delays productive use of the new system.
In many SAS projects, no formal testing has been established before. That makes it even more important to plan testing early—even if it means additional effort upfront.
Best Practice: Define and document a test strategy from the start. Include:
Even when migration is technically successful, its value often remains invisible—especially to decision-makers and end users.
Best Practice: Communicate what has improved: lower costs, faster insights, automated processes, increased ownership by business teams.
Many migration projects fail in the long term because internal knowledge isn’t built. That makes future changes slow and expensive.
Best Practice: Based on numerous client projects—especially in regulated industries—a structured approach has proven effective. It aligns with the practices outlined in our Best Practice Guide.
Migrating from SAS is not an end in itself—it’s an opportunity to rethink your analytics landscape. Those who know the common mistakes can avoid them and generate real added value.
