Lessons Learned: How to Avoid Mistakes During a SAS Migration

Without a clearly defined target vision, a migration often goes in circles. “Moving away from SAS” is not a strategy. A clear answer is needed to the question: What should the new system be capable of—for which user groups, and under what technical and business conditions?

Best Practice: Develop the target vision collaboratively with IT, the business unit, and the architecture team. Ideally, this should be done through a structured assessment process.

SAS often contains hidden implicit workarounds, manual data manipulations, and dependencies. These become apparent when switching to the new system—and can lead to significant challenges during migration.

Best Practice: Process quality starts with data quality—automated, reproducible, and transparent. Metadata and data flows should also be documented.

A SAS migration is not purely a technical project. If you don’t involve business units until the testing or acceptance phases, you risk acceptance issues, frustration, and inefficient workarounds in the new system.

Best Practice: Integrate business units from the very beginning through showcases, interviews, and co-creation workshops. Pay particular attention to their goals and processes.

The transition to new tools requires new skills. Without structured enablement, much of this potential remains untapped.

Best Practice: Develop a training plan early on—one that is role-based, practical, and ensures lasting knowledge transfer.

Simply translating SAS code into another programming language or platform rarely leads to real improvements. Often, legacy issues and complexity are simply carried over.

Best Practice: Use the migration as an opportunity for modernization: streamline processes, introduce standards, and establish self-service analytics.

Some companies are migrating their existing SAS workloads directly to the cloud—for example, to SAS Viya on Azure or AWS—hoping to realize quick value without major changes. However, the transition to SAS Viya is not a classic “lift-and-shift” process. Even though the SAS programs can technically be migrated, the new architecture requires a shift in thinking—particularly with regard to infrastructure, interfaces, and system integration.

SAS Viya introduces a completely new architectural concept. Local file systems, shell commands, or direct connections to third-party systems (e.g., SharePoint, email servers, network drives) often need to be reimagined and implemented in the new environment. Anyone who attempts to transfer the familiar SAS 9 environment to the cloud unchanged runs the risk of being unable to fully map critical processes—or of having to accept functional limitations.

Best Practice: Do not view migration as a purely infrastructure project, but rather as strategic refactoring. Analyze early on which dependencies exist, which functions must be implemented differently in Viya—and which features may need to be omitted entirely. Those who actively explore the possibilities of the cloud platform can boost performance, scale flexibly, and optimize costs in the long term.

The bottom line is this: Cloud migration is not a sure thing, but rather an opportunity for sustainable modernization.

In many projects, the migration process begins before it is clear which target technology the migration should be based on. This leads to inconsistent architectural decisions, additional work during implementation, and uncertainty within the team.

A common mistake is waiting until the migration is underway to decide whether, for example, to use Python scripts, implement a low-code platform like Dataiku, or integrate an analytical data platform like Snowflake.

Best Practice: Make the platform decision deliberately and early on—not as the project progresses. When doing so, distinguish between:

• Programming languages (e.g., Python, R): important for data scientists and developers; flexible, but requiring more effort for onboarding
• Low-/no-code platforms (e.g., Dataiku): offer drag-and-drop approaches, standardization, and governance features; ideal for business users
• Data platforms (e.g., MS Fabric, Databricks): offer storage, compute, and data integration, often serving as a central backend for analytics
• ETL/ELT tools: relevant for data pipelines and transformation

Key criteria:

• Who are the primary users? (Data science, business units, IT?)
• What compliance and governance requirements exist?
• How complex are the workflows that need to be migrated?
• How much training is required?
• Which tools are already established within the company?

The choice of platform shapes the architecture, skill requirements, governance, and future-readiness. It should therefore not be left to chance or based on individual preferences for specific tools—but rather be made through strategic alignment.

SAS programs are often nested, contain complex business logic, and have evolved over time—and they are frequently inadequately documented. Nevertheless, the issue of test strategy is frequently neglected during replatforming or migration to SAS Viya. This poses risks: Without thorough testing, reimplementation errors are difficult to detect—and the production deployment of new environments is unnecessarily delayed.

Furthermore, many SAS projects have not even established any testing procedures to date. This is precisely why it is crucial to incorporate a testing strategy early on in the migration project—even if this initially means additional effort.

Best Practice: Define and document the testing strategy from the very beginning. This includes:

• Unit tests for key functional modules
• Regression tests to ensure consistent results
• Automated comparison tests of output data
• Clear acceptance criteria, e.g.:
• Runtime ≤ X minutes
• Deviations permitted only from the 4th decimal place onward
• Completeness of the output (e.g., same number of lines, identical keys)
• Documented validation strategy, particularly in regulated industries

Even if the migration is technically successful, the benefits often remain invisible—especially to decision-makers and end users.

Best Practice: Communicate what has improved—for example, lower costs, faster insights, automated processes, and greater autonomy for business units.

Many migration projects ultimately fail because internal expertise is not built up. This makes subsequent changes costly and time-consuming.

Best Practice: Based on numerous customer projects—particularly in regulated industries—a structured approach has been established that is consistent with the methodology outlined in our Best Practice Guide.

Migrating from SAS isn't an end in itself, but rather an opportunity to rethink the analytics landscape. By understanding common pitfalls, you can avoid them and create real value.

Want to learn more?

In our free Best Practice Guide to SAS Migration, you’ll find in-depth information, project examples, and concrete tips for implementation.

Click here for our practical guides