Dr. Joachim WeinbrechtVon Dr. Joachim Weinbrecht, Geschäftsführer W+W Consulting·Aktualisiert am

Das Wichtigste in Kürze12 Min. Lesezeit

Regressionstests SAP: Welcher Änderungsanlass welchen Testumfang braucht, wie Sie ein schlankes Test-Set aufbauen und automatisieren. Jetzt lesen.

Inhalt dieses Beitrags
  1. Warum Regressionstests nach dem Go-Live zur Daueraufgabe werden
  2. Welcher Änderungsanlass welchen Regressionstest-Umfang braucht
  3. So bauen Sie ein schlankes, risikobasiertes Regressionstest-Set auf
  4. Manuell oder automatisiert: was sich im Mittelstand rechnet
  5. Change Impact Analysis: nur testen, was wirklich betroffen ist
  6. Kontinuierliches Testen in S/4HANA Cloud: Public, Private und RISE
  7. Verantwortlichkeiten: Key User, Testkoordinator, Partner
  8. Typische Fehler bei Regressionstests im SAP-Betrieb
  9. Kennzahlen, die Regressionstests steuerbar machen
  10. So unterstützt W+W
  11. Fazit: Regressionstests als Betriebsprozess etablieren, nicht als Projekt
  12. Quellen
  13. Häufige Fragen zu Regressionstests in SAP

Regressionstests in SAP S/4HANA prüfen nach jeder Änderung, ob bereits funktionierende Geschäftsprozesse weiterhin korrekt laufen: nach Release-Upgrades, Feature und Support Packages, Transporten und in der Cloud nach jedem halbjährlichen Upgrade. Für den Mittelstand heißt das nicht „bei jeder Änderung alles testen“, sondern ein schlankes, risikobasiertes Regressionstest-Set kritischer End-to-End-Prozesse aufzubauen, es mit stabilen Testdaten zu versorgen, laufend zu pflegen und dort zu automatisieren, wo es sich mehrfach auszahlt.

Viele Unternehmen testen vor dem Go-Live mit großem Aufwand und hören danach praktisch auf. Das rächt sich spätestens beim ersten größeren Update: Eine Preisfindung rechnet plötzlich anders, ein Ausgangsformular bricht ab, eine Schnittstelle zum Lagerverwaltungssystem verliert Felder. Dieser Beitrag behandelt Regressionstests als Daueraufgabe im Betrieb. Wie Sie Tests im Einführungsprojekt organisieren, beschreibt unser Beitrag zum SAP-Testmanagement im S/4HANA-Projekt.

Warum Regressionstests nach dem Go-Live zur Daueraufgabe werden

Ein S/4HANA-System ist nach dem Go-Live nie fertig. Änderungen kommen aus drei Richtungen:

  • Von SAP: neue Releases, Feature Package Stacks, Support Package Stacks, SAP-Hinweise, gesetzliche Änderungen und in der Public Cloud die regelmäßigen Upgrades und Hotfix Collections.
  • Aus dem eigenen Haus: Customizing-Transporte, Eigenentwicklungen, neue Formulare, Berechtigungsänderungen, geänderte Stammdatenlogik.
  • Aus der Umgebung: Updates an Erweiterungen auf der SAP BTP, an Drittsystemen wie MES, WMS oder E-Commerce, an Schnittstellen und Middleware.

Jede dieser Änderungen kann Prozesse treffen, die niemand bewusst angefasst hat. Genau das ist der Zweck eines Regressionstests: nicht die neue Funktion prüfen, sondern sicherstellen, dass das Bestehende nicht kaputtgegangen ist.

Der Takt in der Public Cloud

Laut SAP erhält SAP S/4HANA Cloud Public Edition zwei große Upgrades pro Jahr, im Februar und im August (Releases wie 2602 und 2608). Zusätzlich spielt SAP alle zwei Wochen im Wartungsfenster am Wochenende Hotfix Collections ein, im Wechsel mit Continuous Feature Delivery, also neuen Funktionen zwischen den Releases. In einer Drei-System-Landschaft wird zuerst das Testsystem aktualisiert, Entwicklung und Produktion folgen etwa drei Wochen später. SAP empfiehlt in seinen FAQ zum Upgrade der Public Edition ausdrücklich, unmittelbar nach dem Upgrade des Testsystems einen Regressionstest durchzuführen, und nennt ein Zeitfenster von zwei bis vier Wochen. Den Termin bestimmt SAP, nicht Sie. Wer kein fertiges Regressionstest-Set hat, testet unter Zeitdruck oder gar nicht.

Der Takt in Private Cloud und On-Premise

In SAP S/4HANA Cloud Private Edition, bei RISE with SAP und On-Premise steuern Sie den Zeitpunkt selbst, aber nicht die Notwendigkeit. Laut Release-Strategie von SAP bringt ein neues Release Änderungen am Datenmodell, eine neue ABAP-Plattform und einen neuen Kernel mit und erfordert gründliche Tests. Neue Funktionen kommen dazwischen über Feature Package Stacks, Korrekturen über Support Package Stacks. SAP empfiehlt, Support Package Stacks mindestens einmal jährlich einzuspielen. Wer das aus Angst vor dem Testaufwand aufschiebt, sammelt technische Schulden und macht das nächste Upgrade größer, nicht kleiner.

Welcher Änderungsanlass welchen Regressionstest-Umfang braucht

Der häufigste Fehler im Betrieb ist ein Einheitsumfang: Entweder wird jede Änderung mit dem Komplettpaket getestet, was niemand durchhält, oder gar nicht. Sinnvoll ist eine feste Zuordnung von Änderungsanlass zu Testumfang, die mit der Fachseite einmal vereinbart und dann konsequent angewendet wird.

Änderungsanlass Regressionstest-Umfang Empfohlener Automatisierungsgrad Typischer Takt
Release-Upgrade (Private Cloud, RISE, On-Premise) Vollständiges Regressionstest-Set aller kritischen End-to-End-Prozesse, Schnittstellen, Eigenentwicklungen, Formulare und Berechtigungen Hoch, ergänzt um manuelle Fachtests für Sonderfälle Alle paar Jahre, als eigenes Projekt
Halbjährliches Upgrade (Public Cloud) Kern-Set kritischer Prozesse plus alle Erweiterungen und Integrationen, priorisiert nach Release-Analyse Hoch, sonst ist das Fenster von zwei bis vier Wochen kaum zu halten Zweimal jährlich
Feature Package Stack oder Support Package Stack Kern-Set plus die Bereiche, die laut Change Impact Analysis betroffen sind Mittel bis hoch Ein- bis zweimal jährlich
Hotfix Collection, Continuous Feature Delivery (Public Cloud) Smoke-Test der wichtigsten Prozesse: Auftrag, Lieferung, Faktura, Bestellung, Wareneingang, Zahlung Vollautomatisch, ohne Automatisierung nicht wirtschaftlich Alle zwei Wochen
Transport mit Customizing oder Eigenentwicklung Funktionstest der Änderung plus Regression der berührten Prozesse laut Impact-Analyse Gezielt, aus dem bestehenden Set ausgewählt Laufend, gebündelt je Transport-Release
Einzelner SAP-Hinweis Betroffene Funktion und unmittelbar angrenzende Prozessschritte Meist manuell Bei Bedarf
Änderung an Schnittstelle, Drittsystem oder BTP-Erweiterung Integrationsregression der betroffenen End-to-End-Prozesse über Systemgrenzen hinweg Mittel, Daten- und Nachrichtenprüfung automatisieren Laufend
Datenbank-, Kernel- oder Infrastrukturänderung Technischer Smoke-Test, Hintergrundjobs, Ausgabe, Performance-Stichproben Hoch Nach Wartungsplan

So bauen Sie ein schlankes, risikobasiertes Regressionstest-Set auf

Das Ziel ist kein Testkatalog mit 1.500 Fällen, den niemand pflegt. Das Ziel ist ein Set, das die geschäftskritischen Abläufe zuverlässig absichert und in einem Upgrade-Fenster tatsächlich durchläuft. Nach unserer Erfahrung genügen im Mittelstand dafür häufig wenige Dutzend gut geschnittene End-to-End-Szenarien.

1. Business-Prozess-Inventar erstellen

Ausgangspunkt ist eine Liste der Prozesse, die im System tatsächlich laufen, nicht der Prozesse aus dem Fachkonzept von vor drei Jahren. Gute Quellen sind die Prozesslandkarte, Nutzungsstatistiken aus dem System, die Liste der Eigenentwicklungen und Schnittstellen sowie die Erfahrung der Key User. Jeder Prozess erhält einen Verantwortlichen aus der Fachseite.

2. Kritikalität bewerten

Bewerten Sie jeden Prozess nach zwei Achsen: Schaden bei Ausfall (Umsatz, Lieferfähigkeit, Compliance, Monatsabschluss) und Änderungswahrscheinlichkeit (Eigenentwicklungen, Schnittstellen, viel Customizing, Häufigkeit von SAP-Änderungen in diesem Bereich). Prozesse mit hohem Schaden gehören immer ins Kern-Set, unabhängig davon, wie stabil sie bisher waren. Die Methodik dahinter erläutern wir ausführlich im Beitrag Risk-based Testing in SAP-Projekten.

3. Testfälle als End-to-End-Szenarien schneiden

Regressionstests sollten Geschäftsvorfälle abbilden, nicht Transaktionen. „Kundenauftrag mit Sonderpreis bis Zahlungseingang“ deckt Preisfindung, Verfügbarkeitsprüfung, Lieferung, Faktura, Ausgabe und Buchhaltung in einem Lauf ab. Ergänzen Sie jedes Szenario um eindeutige Prüfpunkte: Welcher Preis, welche Buchung, welches Dokument muss am Ende stehen? Ein Test ohne Soll-Ergebnis ist eine Klickübung.

4. Testdatenmanagement von Anfang an mitdenken

Die meisten Regressionstests scheitern nicht an der Software, sondern an den Daten: Material gesperrt, Kunde ohne Kreditlimit, Periode geschlossen, Bestand verbraucht. Testdatenmanagement gehört deshalb in jedes Regressionstest-Konzept:

  • Definieren Sie je Szenario einen festen Satz an Stammdaten, die ausschließlich für Tests verwendet werden.
  • Sorgen Sie für Verbrauchsdaten, die sich selbst auffüllen, etwa durch vorgeschaltete Testschritte, die Bestand buchen oder Aufträge anlegen.
  • Klären Sie, wann das Testsystem aus der Produktion kopiert wird und was das für Ihre Testdaten bedeutet.
  • Anonymisieren Sie personenbezogene Daten in kopierten Systemen, die DSGVO gilt auch im Testsystem.

5. Testfall-Wartung als festen Prozess verankern

Ein Regressionstest-Set veraltet mit jeder Änderung, die es absichern soll. Legen Sie fest, dass kein Change Request abgenommen wird, bevor die betroffenen Testfälle aktualisiert sind. Planen Sie nach jedem Upgrade eine kurze Nachbereitung: Welche Tests haben falschen Alarm geschlagen, welche Fehler sind trotzdem in die Produktion gelangt, welche Szenarien fehlen?

Manuell oder automatisiert: was sich im Mittelstand rechnet

Automatisierung lohnt sich, wenn ein Test oft wiederholt wird, stabil abläuft und sein Ergebnis eindeutig prüfbar ist. Genau das trifft auf Regressionstests zu. Manuell bleiben sollten Tests, die Fachurteil verlangen, selten laufen oder sich ständig ändern. Für den Mittelstand bewährt sich eine einfache Regel: Das Kern-Set wird automatisiert, Sonderfälle und neue Funktionen testen Key User manuell. Mehr zu Aufwand und Vorgehen lesen Sie in unserem Beitrag zur SAP-Testautomatisierung.

Die Werkzeuglandschaft hat sich in den letzten Jahren deutlich bewegt. Stand November 2026:

  • Test Automation Tool für SAP S/4HANA Cloud Public Edition: Laut SAP kostenfrei, mit vorausgelieferten automatisierten Testfällen für die SAP-Best-Practice-Prozesse und integrierbar in SAP Cloud ALM. Für Public-Cloud-Kunden ist es der naheliegende Startpunkt, Testdaten müssen Sie anpassen.
  • SAP Cloud ALM mit Tricentis: SAP Cloud ALM bringt laut SAP keine eigene Automatisierungs-Engine mit. Stattdessen lässt sich aus dem Cloud-ALM-Tenant ein Tricentis-Tenant bereitstellen („Tricentis Test Automation for SAP integrated with SAP Cloud ALM“), der browserbasierte SAP-Anwendungen und SAP GUI automatisiert. Testpläne, Ausführung und Defects bleiben in Cloud ALM, wo Sie auch wiederverwendbare Regressionstestpläne anlegen können.
  • Tricentis Tosca: Die eigenständige, modellbasierte Automatisierungsplattform von Tricentis für SAP- und Nicht-SAP-Systeme. SAP selbst bietet zudem „SAP Test Automation by Tricentis“ an. Laut SAP erhalten On-Premise-Kunden mit SAP Enterprise Support eine kostenfreie Laufzeitlizenz für Tricentis Test Automation for SAP, integriert mit dem SAP Solution Manager. Prüfen Sie im Einzelfall, welche Funktionen davon abgedeckt sind und was Zusatzlizenz ist.
  • Worksoft: Laut Worksoft setzt die „Connective Automation Platform 2026“ auf impact-gesteuertes Testen, Selbstheilung von Testskripten und KI-gestützte Ursachenanalyse, mit Integration in SAP Solution Manager und SAP Cloud ALM. Interessant für Unternehmen mit vielen Nicht-SAP-Systemen im Prozess.
  • SAP eCATT und CBTA: eCATT ist als Bordmittel im ABAP-Stack weiterhin vorhanden und eignet sich nach unserer Erfahrung für SAP-GUI-Transaktionen und Funktionsbausteine, kaum aber für Fiori-lastige Prozesse. Die komponentenbasierte Testautomatisierung (CBTA) im Solution Manager wird laut SAP nicht auf Cloud-Produkte erweitert. Der Solution Manager selbst ist laut SAP bis Ende 2027 in der Mainstream-Wartung, für ausgewählte Funktionen einschließlich der Test Suite gibt es optional erweiterte Wartung bis Ende 2030.

Für die meisten Mittelständler auf dem Weg zu S/4HANA heißt das: Testmanagement in SAP Cloud ALM, Automatisierung über das SAP-Tool (Public Cloud) oder Tricentis, und keine neuen Investitionen mehr in eCATT- oder CBTA-Skripte. Wie Cloud ALM im Projekt und Betrieb zusammenspielt, zeigt unser Beitrag zu SAP Cloud ALM in S/4HANA-Projekten.

Change Impact Analysis: nur testen, was wirklich betroffen ist

Das Kern-Set läuft bei jedem größeren Update. Darüber hinaus sollte der Umfang aus einer Change Impact Analysis abgeleitet werden: Welche Objekte ändern sich, welche Prozesse nutzen sie, welche Tests decken diese Prozesse ab, und wo gibt es Lücken?

  • Public Cloud: SAP stellt für Upgrades das Werkzeug Release Assessment and Scope Dependency (RASD) bereit, das die Auswirkungen eines Releases auf Ihren Scope zeigt. Die resultierenden Maßnahmen lassen sich in SAP Cloud ALM als Aufgaben verfolgen.
  • Private Cloud und On-Premise: Laut Tricentis analysiert LiveCompare einzelne Transporte und ChaRM-Vorgänge auf geschäftliches und technisches Risiko, erzeugt je Transportbündel eine Liste der auszuführenden Tests und zeigt Abdeckungslücken, bevor ein Transport in die Produktion geht. Worksoft verfolgt mit „Impact“ einen vergleichbaren Ansatz.
  • Ohne Spezialwerkzeug: Transportinhalte systematisch auswerten, Verwendungsnachweise prüfen und die Prozessverantwortlichen fragen. Das ist aufwendiger, aber besser als Bauchgefühl.

Wie eine werkzeuggestützte Analyse konkret aussieht, beschreiben wir im Beitrag Change Impact Analysis für SAP S/4HANA mit Tosca.

Kontinuierliches Testen in S/4HANA Cloud: Public, Private und RISE

Continuous Testing bedeutet, dass Regressionstests kein Projektereignis mehr sind, sondern ein fester Bestandteil jedes Änderungszyklus. In der Public Cloud ist das durch den SAP-Takt erzwungen: Mit zwei Upgrades im Jahr und Hotfix Collections alle zwei Wochen ist ein manueller Ansatz auf Dauer nicht durchzuhalten. In der Private Cloud und bei RISE with SAP haben Sie mehr Freiheit beim Zeitpunkt, aber kontinuierliche Tests lohnen sich auch dort, weil Transporte, Hinweise und Schnittstellenänderungen laufend anfallen.

Wichtig für RISE-Kunden: SAP übernimmt den technischen Betrieb. Ob Ihre Geschäftsprozesse nach einem Update fachlich korrekt laufen, müssen Sie in der Regel weiterhin selbst nachweisen. Klären Sie im Vertrag und mit Ihrem Partner, wer welche Tests verantwortet.

Der stärkste Hebel gegen wachsenden Regressionsaufwand liegt übrigens vor dem Test: Je weniger Modifikationen und je sauberer die Erweiterungen über freigegebene Schnittstellen laufen, desto weniger bricht bei Upgrades. Eine konsequente Clean-Core-Strategie senkt deshalb dauerhaft den Testaufwand.

Verantwortlichkeiten: Key User, Testkoordinator, Partner

Regressionstests scheitern im Betrieb selten an der Technik, sondern an unklaren Zuständigkeiten. Bewährt hat sich diese Aufteilung:

  • Key User: verantworten ihre Prozesse und Testfälle fachlich, führen manuelle Tests durch und geben Ergebnisse frei. Sie brauchen dafür eingeplante Zeit, nicht „nebenbei“.
  • Testkoordinator: eine benannte Person auf Kundenseite, die das Regressionstest-Set, den Testkalender, die Testdaten und das Reporting verantwortet. Im Mittelstand ist das oft eine Teilzeitrolle in der IT oder im ERP-Team.
  • Implementierungs- oder Betriebspartner: liefert technische Upgrades, Transporte und Fehlerbehebung, pflegt bei Bedarf Automatisierungsskripte. Er sollte nicht allein entscheiden, ob seine eigene Lieferung ausreichend getestet ist.
  • IT-Leitung: entscheidet auf Basis der Testergebnisse über die Freigabe in die Produktion.

Typische Fehler bei Regressionstests im SAP-Betrieb

  • Projekttests einfach weiterverwenden: Testfälle aus dem Einführungsprojekt sind zu zahlreich, zu kleinteilig und oft nicht mehr aktuell.
  • Nur SAP-Standard testen: Die meisten Probleme nach Upgrades entstehen an Eigenentwicklungen, Formularen und Schnittstellen.
  • Testdaten dem Zufall überlassen: Wer erst am Testtag Daten sucht, verliert die Hälfte des Fensters.
  • Automatisieren ohne Wartungsbudget: Skripte, die niemand pflegt, liefern nach zwei Releases mehr Fehlalarme als Erkenntnisse.
  • Berechtigungen vergessen: Getestet wird mit einem Superuser, der Fehler tritt erst beim Sachbearbeiter auf.
  • Keine Auswertung nach dem Go-Live des Updates: Ohne Rückkopplung aus der Produktion lernt das Test-Set nichts dazu.

Kennzahlen, die Regressionstests steuerbar machen

ERP-Testmanagement im Betrieb braucht wenige, aber aussagekräftige Kennzahlen:

  • Testabdeckung kritischer Prozesse: Anteil der als kritisch eingestuften Prozesse mit aktuellem, lauffähigem Regressionstest. Ziel: vollständig.
  • Automatisierungsquote im Kern-Set: Anteil der Kern-Szenarien, die ohne manuelle Eingriffe laufen.
  • Durchlaufzeit eines Regressionszyklus: von Bereitstellung des Testsystems bis Freigabe. In der Public Cloud muss sie sicher ins Fenster bis zum Produktions-Upgrade passen.
  • Fehler nach Go-Live des Updates: Anzahl und Schwere der Fehler, die trotz Test in der Produktion auftreten, jeweils mit Ursache: Testlücke, Datenproblem oder nicht erkannte Auswirkung.
  • Wartungsrückstand: Anzahl der Testfälle, die nach Änderungen noch nicht aktualisiert wurden.

So unterstützt W+W

W+W steuert Tests auf Kundenseite und ist unabhängig vom Implementierungspartner. Wir bauen mit Ihren Key Usern das Prozessinventar und das risikobasierte Regressionstest-Set auf, definieren Testdatenmanagement und Verantwortlichkeiten, wählen passende Werkzeuge aus und begleiten Upgrades bis zur Freigabe. Grundlage sind über 30 Jahre SAP-/ERP-Erfahrung, mehr als 50 SAP- und ERP-Projekte und eine Go-Live-Quote von 100 %. Für die Ableitung von Testfällen aus Anforderungen nutzen wir bei Bedarf auch den KI-Testfallgenerator unserer Schwesterfirma. Details finden Sie auf unserer Seite Testmanagement und Testautomatisierung.

Fazit: Regressionstests als Betriebsprozess etablieren, nicht als Projekt

Jede Änderung an S/4HANA ist ein Risiko für Prozesse, die heute funktionieren, und die Taktung durch SAP wird nicht langsamer. Unsere Empfehlung: Bauen Sie innerhalb eines Quartals ein risikobasiertes Kern-Set Ihrer kritischen End-to-End-Prozesse mit festen Testdaten auf, automatisieren Sie es schrittweise mit SAP Cloud ALM und dem passenden Werkzeug, legen Sie eine verbindliche Zuordnung von Änderungsanlass zu Testumfang fest und benennen Sie einen Testkoordinator. Wenn Sie dabei Unterstützung wünschen, sprechen Sie mit uns.

Quellen

Häufige Fragen

Häufige Fragen zu Regressionstests in SAP

Was ist ein Regressionstest in SAP?

Ein Regressionstest in SAP prüft nach einer Änderung, ob bereits funktionierende Prozesse weiterhin korrekt laufen. Anlass können ein Release-Upgrade, ein Support Package, ein Transport, ein SAP-Hinweis oder eine Schnittstellenänderung sein. Im Unterschied zum Funktionstest geht es nicht um die neue Funktion, sondern um unbeabsichtigte Nebenwirkungen auf bestehende Abläufe wie Auftragsabwicklung, Beschaffung oder Monatsabschluss.

Wie oft brauche ich Regressionstests in SAP S/4HANA Cloud Public Edition?

Mindestens zweimal jährlich zu den großen Upgrades, die SAP laut eigener Aussage im Februar und August durchführt. Dazu kommen Hotfix Collections alle zwei Wochen, für die sich ein automatisierter Smoke-Test der wichtigsten Prozesse empfiehlt. SAP rät, direkt nach dem Upgrade des Testsystems zu testen, das Fenster bis zur Produktion beträgt etwa zwei bis vier Wochen.

Wie viele Testfälle braucht ein Regressionstest-Set im Mittelstand?

Weniger als die meisten erwarten. Entscheidend ist nicht die Anzahl, sondern die Abdeckung der geschäftskritischen End-to-End-Prozesse inklusive Eigenentwicklungen, Formularen und Schnittstellen. Nach unserer Erfahrung reichen häufig wenige Dutzend gut geschnittene Szenarien mit klaren Soll-Ergebnissen. Wichtiger als ein großer Katalog ist, dass das Set gepflegt wird und im verfügbaren Zeitfenster vollständig durchläuft.

Lohnt sich Testautomatisierung für Regressionstests im Mittelstand?

Für das Kern-Set in der Regel ja, weil dieselben Prozesse bei jedem Update erneut geprüft werden müssen. In der Public Cloud ist Automatisierung durch den Upgrade-Takt praktisch Pflicht, das SAP-eigene Test Automation Tool ist laut SAP kostenfrei. Manuell bleiben Tests, die Fachurteil verlangen, selten laufen oder sich häufig ändern. Planen Sie immer Budget für die Wartung der Skripte ein.

Was gehört zum Testdatenmanagement bei SAP-Regressionstests?

Testdatenmanagement umfasst feste Stammdaten je Testszenario, Verbrauchsdaten wie Bestände oder offene Posten, die sich vor jedem Lauf wiederherstellen lassen, einen geregelten Umgang mit Systemkopien aus der Produktion und die Anonymisierung personenbezogener Daten. Ohne diese Grundlage scheitern Regressionstests oft an gesperrten Materialien, geschlossenen Perioden oder fehlenden Daten statt an echten Fehlern.

Wer ist bei RISE with SAP für Regressionstests verantwortlich?

Bei RISE with SAP übernimmt SAP den technischen Betrieb, die fachliche Prüfung der Geschäftsprozesse nach Updates bleibt in der Regel beim Kunden. Praktisch bedeutet das: Key User verantworten ihre Prozesse, ein Testkoordinator auf Kundenseite steuert Set, Testdaten und Kalender, der Partner liefert Upgrades und Korrekturen. Halten Sie diese Aufteilung schriftlich fest, bevor das erste Upgrade ansteht.