In vielen Unternehmen ist SAS seit Jahren ein zentraler Bestandteil der Analytics-Infrastruktur. Doch steigende Lizenzkosten, die zunehmende Infrastruktur in der Cloud sowie der Wunsch nach mehr Flexibilität und Zukunftsfähigkeit führen dazu, dass viele Organisationen ihre SAS-Umgebung hinterfragen. Dabei rücken Alternativen wie Programmiersprachen (z. B. Python, R) oder moderne Cloud-Datenplattformen (z. B. Databricks, MS Fabric) in den Fokus – je nach Zielbild und strategischer Ausrichtung.
Zugleich ist die Migration komplex: Neben den technischen Herausforderungen müssen auch Prozesse, Datenqualität, regulatorische Anforderungen und die Akzeptanz durch Fachbereiche berücksichtigt werden. In diesem Artikel zeigen wir zehn typische Fehler aus der Praxis – und wie man sie vermeiden kann. Grundlage sind unsere Erfahrungen mit mehr als 6000 geleisteten Personentagen in verschiedenen SAS-Migrationsprojekten. Insbesondere in regulierten Branchen wie Pharma, Versicherungen und Industrie.
Ohne ein definiertes Zielbild verläuft eine Migration oft im Kreis. "Weg von SAS" ist keine Strategie. Es braucht eine klare Antwort auf die Frage: Was soll das neue System können – für welche Nutzergruppen, unter welchen technischen und fachlichen Rahmenbedingungen?
Best Practice: Zielbild gemeinsam mit IT, Fachbereich und Architekturteam entwickeln. Idealerweise in einem strukturierten Assessment-Prozess.
In SAS schlummern oft implizite Workarounds, manuelle Datenmanipulationen und Abhängigkeiten. Diese werden beim Wechsel in das neue System sichtbar – und können zu massiven Herausforderungen bei der Migration führen.
Best Practice: Prozessqualität beginnt bei der Datenqualität – automatisiert, reproduzierbar und transparent. Auch Metadaten und Datenflüsse sollten dokumentiert werden.
Eine SAS-Migration ist kein rein technisches Projekt. Wer Fachbereiche erst bei Tests oder Abnahmen einbindet, riskiert Akzeptanzprobleme, Frust und ineffiziente Workarounds im neuen System.
Best Practice: Fachbereiche von Beginn an integrieren: Showcases, Interviews, Co-Creation-Workshops. Dabei besonders auf deren Ziele und Prozesse achten.
Die Umstellung auf neue Tools erfordert neue Skills. Ohne strukturiertes Enablement bleiben viele Potenziale ungenutzt.
Best Practice: Frühzeitig ein Trainingskonzept erarbeiten: rollenbasiert, praxisnah und mit nachhaltigem Wissenstransfer.
Die bloße Übersetzung von SAS-Code in eine andere Programmiersprache oder Plattform führt selten zu echten Verbesserungen. Oft werden Altlasten und Komplexität einfach mitgeschleppt.
Best Practice: Die Migration als Modernisierungschance nutzen: Prozesse verschlanken, Standards einführen und Self-Service-Analytics etablieren.
Einige Unternehmen migrieren ihre bestehenden SAS-Workloads direkt in die Cloud – beispielsweise nach SAS Viya on Azure oder AWS – und hoffen auf schnellen Mehrwert ohne größere Änderungen. Doch der Umstieg auf SAS Viya ist kein klassisches Lift & Shift. Denn: Auch wenn sich die SAS-Programme technisch migrieren lassen, erfordert die neue Architektur ein Umdenken – insbesondere im Hinblick auf Infrastruktur, Schnittstellen und Systemintegration.
SAS Viya bringt ein völlig neues Architekturkonzept mit sich. Lokale Dateisysteme, Shell-Kommandos oder direkte Anbindungen an Fremdsysteme (z. B. SharePoint, E-Mailserver, Netzlaufwerke) müssen in der neuen Umgebung oft neu gedacht und implementiert werden. Wer versucht, die gewohnte SAS 9-Welt unverändert in die Cloud zu übertragen, läuft Gefahr, kritische Prozesse nicht vollständig abbilden zu können – oder funktionale Einschränkungen in Kauf nehmen zu müssen.
Migration nicht als reines Infrastrukturprojekt betrachten, sondern als strategisches Refactoring. Frühzeitig analysieren, welche Abhängigkeiten bestehen, welche Funktionen in Viya anders gelöst werden müssen – und welche Features eventuell ganz entfallen. Wer sich aktiv mit den Möglichkeiten der Cloud-Plattform auseinandersetzt, kann Performance steigern, Skalierung flexibel gestalten und langfristig Kosten optimieren.
Es gilt: Cloud-Migration ist kein Selbstläufer, sondern eine Chance für nachhaltige Modernisierung.
In vielen Projekten wird mit der Migration begonnen, bevor klar ist, auf welche Zieltechnologie migriert werden soll. Das führt zu inkonsistenten Architekturentscheidungen, Mehraufwand bei der Umsetzung und Unsicherheit im Team.
Ein häufiger Fehler ist, dass man erst im Laufe der Migration entscheidet, ob beispielsweise Python-Skripte genutzt, eine Low-Code Plattform wie Dataiku eingesetzt oder eine analytische Datenplattform wie Snowflake angebunden werden soll.
Best Practice: Treffen Sie die Plattformentscheidung bewusst und frühzeitig – nicht im Projektverlauf. Dabei sollte unterschieden werden zwischen:
Entscheidende Kriterien:
Die Plattformwahl prägt Architektur, Skill-Bedarf, Governance und Zukunftsfähigkeit. Sie sollte daher nicht dem Zufall oder Tool-Favoriten Einzelner überlassen werden – sondern strategisch abgestimmt erfolgen.
SAS-Programme sind häufig verschachtelt, enthalten komplexe Geschäftslogik und sind historisch gewachsen – dokumentiert sind sie oft nur unzureichend. Dennoch wird beim Replatforming oder bei der Migration nach SAS Viya das Thema Teststrategie häufig vernachlässigt. Das birgt Risiken: Ohne saubere Tests lassen sich Re-Implementierungsfehler nur schwer erkennen – und der produktive Einsatz neuer Umgebungen verzögert sich unnötig.
Hinzu kommt: In vielen SAS-Projekten existieren bislang gar keine etablierten Tests. Gerade deshalb ist es entscheidend, eine Teststrategie frühzeitig im Migrationsprojekt mitzudenken – auch wenn das zunächst Mehraufwand bedeutet.
Best Practice: Teststrategie von Anfang an definieren und dokumentieren. Dazu gehören:
Selbst wenn die Migration technisch gelingt, bleibt der Nutzen oft unsichtbar – vor allem für Entscheider und Endanwender.
Best Practice: Kommunizieren Sie, was sich verbessert hat: z. B. niedrigere Kosten, schnellere Insights, automatisierte Prozesse, mehr Eigenverantwortung der Fachbereiche.
Viele Migrationsprojekte scheitern langfristig daran, dass internes Wissen nicht aufgebaut wird. Das macht Folgeänderungen teuer und langsam.
Best Practice: Auf Basis zahlreicher Kundenprojekte – insbesondere in regulierten Branchen – hat sich eine strukturierte Herangehensweise etabliert, die auch dem Vorgehen in unserem Best Practice Guide entspricht.
Die Migration von SAS ist kein Selbstzweck, sondern eine Gelegenheit, die Analytics-Landschaft neu zu denken. Wer typische Fehler kennt, kann sie vermeiden und echten Mehrwert schaffen.
Mehr erfahren?
In unserem kostenlosen Best Practice Guide zur SAS-Migration finden Sie vertiefende Infos, Projektbeispiele und konkrete Tipps zur Umsetzung.