SAP Support Dienstleister wechseln: So gelingt eine sichere Transition

Erfahren Sie, wie Sie Wissen, Zugänge und operative Verantwortung kontrolliert an einen neuen SAP Support Partner übergeben.

Der Wechsel eines SAP Support Dienstleisters ist möglich, ohne den laufenden Betrieb unnötig zu gefährden. Voraussetzung ist jedoch, dass Unternehmen den Anbieterwechsel nicht als einfachen Vertragswechsel behandeln, sondern als kontrollierte Transition von Wissen, Zugängen, Prozessen und operativer Verantwortung.

Die größten Risiken entstehen meist nicht am eigentlichen Go-live des neuen Partners. Kritischer sind unvollständige Dokumentationen, ungeklärte Zuständigkeiten, fehlende Systemzugänge, offene Incidents und Wissen, das nur bei einzelnen Beratern oder internen Mitarbeitenden vorhanden ist. Werden diese Punkte frühzeitig erfasst und geprüft, lässt sich die Übergabe schrittweise absichern.

Kurzantwort: Eine sichere SAP Support Transition benötigt einen klar abgegrenzten Leistungsumfang, verbindliche Verantwortlichkeiten, einen strukturierten Wissenstransfer sowie definierte Abnahmekriterien. Der neue Dienstleister sollte kritische Supportfälle bereits vor der vollständigen Übernahme selbstständig bearbeiten können.

Dieser Leitfaden behandelt den Wechsel des operativen SAP Support- oder AMS-Dienstleisters. Damit ist nicht automatisch eine Kündigung des SAP-Wartungsvertrags, ein Wechsel der SAP-Plattform oder die Ablösung des ERP-Systems verbunden. Diese Entscheidungen können miteinander zusammenhängen, müssen aber vertraglich und organisatorisch getrennt betrachtet werden.

Wann ist ein Wechsel des SAP Support Dienstleisters sinnvoll?

Ein Wechsel des SAP Support Dienstleisters ist sinnvoll, wenn wiederkehrende und messbare Probleme zeigen, dass der aktuelle Partner die operativen, technischen oder strategischen Anforderungen des Unternehmens nicht mehr erfüllt. Einzelne Verzögerungen oder Kommunikationsprobleme reichen dafür nicht aus. Entscheidend ist, ob sich die Situation trotz klarer Eskalation, angepasster Governance und konkreter Verbesserungsmaßnahmen dauerhaft nicht verändert.

Typische Warnsignale sind regelmäßig verfehlte Service Levels, wiederkehrende Störungen ohne nachhaltige Ursachenanalyse oder fehlendes Know-how für die Weiterentwicklung der SAP-Landschaft. Auch mangelnde Transparenz kann problematisch sein: Unternehmen sollten nachvollziehen können, welche Tickets offen sind, wie Supportkapazitäten eingesetzt werden, welche Risiken bestehen und welche Maßnahmen zur Stabilisierung geplant sind.

Nicht jedes dieser Signale erfordert automatisch einen Anbieterwechsel. Unklare Rollen, unrealistische SLAs oder ein schlecht abgegrenzter Leistungsumfang können häufig durch eine Überarbeitung des bestehenden Supportmodells behoben werden.

Ein Wechsel sollte daher nicht allein aus Unzufriedenheit erfolgen. Er ist dann gerechtfertigt, wenn die Probleme strukturell sind, den Geschäftsbetrieb oder die SAP-Roadmap beeinträchtigen und der bestehende Dienstleister keine glaubwürdige Verbesserung nachweisen kann.

Was muss vor der Kündigung geklärt werden?

Bevor ein Unternehmen den bestehenden SAP Supportvertrag kündigt, müssen die vertraglichen Rahmenbedingungen, der genaue Leistungsumfang, die administrativen Zugänge und das künftige Supportmodell geklärt sein. Erfolgt die Kündigung zu früh, kann zwischen dem bisherigen und dem neuen Dienstleister eine operative Lücke entstehen.

Verträge und Exit-Regelungen prüfen

Zunächst sollten Einkauf, IT und Rechtsabteilung gemeinsam prüfen, welche Kündigungsfristen, automatischen Verlängerungen und Exit-Verpflichtungen gelten. Besonders relevant ist, ob der bisherige Dienstleister während der Transition zur Mitwirkung verpflichtet ist und ob diese Leistungen bereits im Vertrag enthalten sind oder separat vergütet werden.

Darüber hinaus muss geklärt werden, wem Dokumentationen, Konfigurationen, Quellcode, Ticketdaten und andere im Rahmen des Supports entstandene Arbeitsergebnisse gehören. Auch Regelungen zur Rückgabe beziehungsweise Löschung von Daten, zum Einsatz von Subunternehmern und zur Auftragsverarbeitung sollten vor der Kündigung überprüft werden.

Supportumfang eindeutig abgrenzen

Unternehmen müssen dokumentieren, welche Leistungen tatsächlich vom bisherigen Anbieter übernommen werden. Dazu können First-, Second- und Third-Level-Support, funktionale Betreuung, SAP Basis, Schnittstellen, Custom Development, Monitoring, Release Management oder Cloud Operations gehören.

Diese Abgrenzung ist notwendig, weil nicht jede Aufgabe automatisch an den neuen SAP Support Partner übergeht. Leistungen können weiterhin bei internen Teams, SAP selbst, einem Hosting-Anbieter oder weiteren Spezialdienstleistern liegen. Ohne eine klare Scope-Baseline entstehen schnell doppelte Zuständigkeiten oder unbetreute Bereiche.

Zugänge und administrative Kontrolle sichern

Kritische Zugänge sollten unter der Kontrolle des Unternehmens stehen und nicht ausschließlich über personenbezogene Konten des bisherigen Dienstleisters verfügbar sein. Zu prüfen sind unter anderem SAP for Me, S-User und deren Berechtigungen, das Ticketing- und Monitoring-System, Transportwerkzeuge, Cloud-Plattformen, technische Benutzer sowie Zertifikate und Schnittstellenkonten.

SAP for Me verwendet S-User und spezifische Berechtigungen für den Zugriff auf Supportfälle, Installationen und weitere sensible Unternehmensdaten. Nur entsprechend berechtigte Administratoren können diese Zugänge verwalten. Unternehmen sollten deshalb rechtzeitig prüfen, wer intern über die notwendigen Administrationsrechte verfügt.

Auch der bei einer Installation hinterlegte „Supported By“ Partner sollte kontrolliert werden. SAP sieht die Möglichkeit vor, den eingetragenen Partner für bestehende Installationsnummern zu aktualisieren oder zu entfernen; eine neue Installationsnummer ist dafür nicht grundsätzlich erforderlich.

Zielmodell und neuen Partner festlegen

Vor Beginn der eigentlichen Transition sollte feststehen, wie der künftige Support organisiert wird. Dazu gehören Leistungsumfang, Supportzeiten, Sprachen, benötigte SAP-Kompetenzen, Service Levels, Eskalationswege, Reporting und die Rollen interner Teams.

Der neue Dienstleister sollte außerdem bereits einen verantwortlichen Transition Manager benennen und den erwarteten Aufwand für Analyse, Wissenstransfer, Shadowing und Übernahme bewerten. Erst wenn Zielmodell und Verantwortlichkeiten festgelegt sind, lässt sich ein realistischer Kündigungs- und Übergabezeitpunkt bestimmen.

Hinweis zur SAP-Wartung: Seit dem 10. Juli 2026 gelten neue, von der Europäischen Kommission verbindlich gemachte SAP-Verpflichtungen für Wartung und Support von On-Premise-Produkten. Sie erweitern unter anderem die Flexibilität bei bestimmten Support- und Wartungskonstellationen. Ein gewöhnlicher Wechsel des operativen AMS-Dienstleisters ist jedoch nicht automatisch mit einer Änderung des SAP-Wartungsvertrags gleichzusetzen. Die konkrete vertragliche Anwendung sollte separat geprüft werden.

Planen Sie den Anbieterwechsel, bevor operative Lücken entstehen

LeverX unterstützt Unternehmen dabei, den bestehenden SAP Supportumfang zu analysieren, Übergaberisiken zu identifizieren und ein realistisches Zielmodell für den künftigen Betrieb zu entwickeln.

SAP Support Assessment anfragen

Welche Risiken entstehen beim Wechsel des SAP Support Partners?

Beim Wechsel eines SAP Support Partners entstehen Risiken vor allem dort, wo Wissen, Zugänge oder Verantwortlichkeiten nicht eindeutig übertragen werden. Kritisch ist deshalb nicht nur, ob Dokumente vorhanden sind, sondern ob der neue Dienstleister den operativen Kontext versteht und geschäftskritische Situationen selbstständig bearbeiten kann.

Das größte Risiko ist häufig nicht eine vollständig fehlende Dokumentation, sondern die Lücke zwischen dokumentiertem Systemwissen und tatsächlich nutzbarem Betriebswissen. Eine Schnittstelle kann beispielsweise technisch beschrieben sein, ohne dass dokumentiert wurde, welche Fachprozesse davon abhängen, welche Fehler regelmäßig auftreten und wer bei einer Störung entscheiden muss.

Deshalb sollte die Qualität der Übergabe nicht allein an der Anzahl übertragener Dokumente gemessen werden. Entscheidend ist, ob der neue Dienstleister typische Supportfälle analysieren, notwendige Zugriffe nutzen, Abhängigkeiten erkennen und kritische Eskalationen innerhalb des vereinbarten Prozesses bearbeiten kann.

Wie läuft eine SAP Support Transition ab?

Eine SAP Support Transition sollte in fünf klar abgegrenzten Phasen erfolgen: Analyse, Planung, Wissenstransfer, operative Erprobung und kontrollierte Übernahme. Jede Phase benötigt konkrete Ergebnisse und Abnahmekriterien. Nur so lässt sich objektiv feststellen, ob der neue Dienstleister tatsächlich bereit ist, die Verantwortung für den SAP-Betrieb zu übernehmen.

Phase 1: SAP-Landschaft und Supportumfang analysieren

Die Transition beginnt mit einer belastbaren Bestandsaufnahme. Dabei reicht es nicht aus, lediglich Systeme und SAP-Module aufzulisten. Das neue Team muss verstehen, welche Geschäftsprozesse unterstützt werden, welche Anwendungen besonders kritisch sind und welche technischen oder organisatorischen Abhängigkeiten bestehen.

Zur Analyse gehören unter anderem:

• SAP-Systeme, Mandanten und Umgebungen,
• unterstützte Module und Geschäftsprozesse,
• aktuelle Ticketvolumen und häufige Störungsarten,
• offene Incidents, Problems und Service Requests,
• individuelle Entwicklungen und Erweiterungen,
• Schnittstellen, Middleware und Drittsysteme,
• Hintergrundjobs und wiederkehrende Betriebsaufgaben,
• aktuelle Service Levels und Eskalationswege,
• geplante Releases, Migrationen oder größere Projekte,
• kritische Termine wie Monatsabschluss, Payroll oder Produktionsspitzen.

Auch bekannte Schwachstellen sollten offen erfasst werden. Dazu gehören fehlende Dokumentationen, veraltete Runbooks, Abhängigkeiten von einzelnen Beratern oder Tickets, die seit längerer Zeit nicht nachhaltig gelöst wurden.

Die Ergebnisse werden in einer Scope-Baseline, einem Risikoregister und einem Transition Backlog zusammengeführt. Jedes identifizierte Problem erhält einen Verantwortlichen und eine Entscheidung: Es wird vor dem Cutover geschlossen, während der Transition bearbeitet oder bewusst als Restrisiko übernommen.

Abschlusskriterium: Alle Systeme, Leistungen, Abhängigkeiten und bekannten Lücken innerhalb des Transition-Umfangs sind dokumentiert und einem Owner zugeordnet.

Phase 2: Governance und Transition planen

Auf Grundlage der Analyse wird ein verbindlicher Transition-Plan erstellt. Er definiert nicht nur Termine, sondern auch Zuständigkeiten, Entscheidungswege und Kriterien für die spätere Abnahme.

Auf Kundenseite sollte eine Person die Gesamtverantwortung übernehmen. Zusätzlich benötigen der bisherige und der neue Dienstleister jeweils einen Transition Manager. Fachbereiche, interne SAP-Teams, Infrastruktur, Security, Einkauf und weitere Anbieter werden abhängig vom Umfang eingebunden.

Eine kompakte RACI-Matrix verhindert, dass mehrere Beteiligte dieselbe Aufgabe übernehmen oder davon ausgehen, jemand anderes sei verantwortlich.

Der Plan sollte außerdem festlegen:

• welche Workstreams parallel laufen,
• welche Workshops und Übergaben erforderlich sind,
• wann Shadowing und Reverse Shadowing beginnen,
• wie offene Risiken eskaliert werden,
• welche Regeltermine stattfinden,
• wie Fortschritt und Qualität gemessen werden,
• wer über Verschiebung oder Freigabe des Cutovers entscheidet.

Jede Aktivität benötigt ein konkretes Ergebnis. „Wissenstransfer durchgeführt“ ist beispielsweise kein ausreichendes Abschlusskriterium. Besser ist: „Der neue Dienstleister hat drei typische Incidents im Bereich Order-to-Cash analysiert und den vereinbarten Lösungsweg nachvollziehbar dokumentiert.“

Abschlusskriterium: Jede Transition-Aktivität verfügt über einen Verantwortlichen, einen Termin, ein erwartetes Ergebnis und eine definierte Abnahmemethode.

Phase 3: Dokumentation und Wissen übertragen

Der Wissenstransfer sollte sich an Geschäftsprozessen und realen Support-Szenarien orientieren, nicht ausschließlich an SAP-Modulen. Ein rein technischer Workshop zu SAP FI hilft nur begrenzt, wenn das neue Team nicht versteht, wie Monatsabschluss, Zahlungsverkehr oder lokale steuerliche Prozesse im Unternehmen tatsächlich ablaufen.

Sinnvolle Wissenstransfer-Einheiten verbinden daher mehrere Perspektiven:

• fachlicher Prozess und beteiligte Organisationseinheiten,
• relevantes Customizing,
• individuelle Entwicklungen,
• Schnittstellen und Hintergrundjobs,
• typische Incidents,
• bekannte Fehler und Workarounds,
• Monitoring und Eskalation,
• verantwortliche Key User und externe Partner.

Neben Präsentationen sollten konkrete Tickets, Systemabläufe und historische Störungen betrachtet werden. Gerade wiederkehrende Probleme zeigen häufig, wie der produktive Betrieb tatsächlich funktioniert und welche Abhängigkeiten in formalen Dokumentationen fehlen.

Wichtige Ergebnisse dieser Phase sind aktualisierte Prozessbeschreibungen, technische Dokumentationen, Runbooks, Known-Error-Einträge, Eskalationskontakte und ein Knowledge Backlog. Der Backlog enthält Punkte, die noch nicht vollständig geklärt wurden, mit Owner und verbindlichem Termin.

Der bisherige Dienstleister sollte Wissen erklären und demonstrieren. Das neue Team muss es anschließend zusammenfassen, anwenden und offene Fragen selbst identifizieren. Dadurch wird sichtbar, ob Informationen nur übertragen oder tatsächlich verstanden wurden.

Abschlusskriterium: Kritische Prozesse und Support-Szenarien sind dokumentiert, offene Wissenslücken sind transparent erfasst und das neue Team kann die wesentlichen Zusammenhänge nachvollziehbar erklären.

Phase 4: Shadowing und Reverse Shadowing durchführen

Im Shadowing beobachtet das neue Team, wie der bisherige Dienstleister reale Tickets, Betriebsaufgaben und Eskalationen bearbeitet. Diese Phase vermittelt den praktischen Ablauf: Welche Informationen werden zuerst geprüft? Welche Teams werden einbezogen? Welche Workarounds sind zulässig? Wann muss ein Fall eskaliert werden?

Danach folgt das Reverse Shadowing. Nun übernimmt der neue Dienstleister die Bearbeitung, während das bisherige Team beobachtet und nur bei Bedarf eingreift.

Mindestens drei Arten von Szenarien sollten geprüft werden:

1. ein kritischer produktiver Incident,
2. eine fehlerhafte Schnittstelle oder ein fehlgeschlagener Hintergrundjob,
3. ein funktionales Problem, das Analyse, Korrektur, Test und Transport erfordert.

Die Bewertung sollte nicht nur das technische Ergebnis berücksichtigen. Ebenso relevant sind Reaktionszeit, Kommunikation, Dokumentation, Einhaltung der Eskalationswege und Abstimmung mit dem Fachbereich.

Ein erfolgreich gelöstes einfaches Ticket reicht nicht als Nachweis für die Betriebsbereitschaft. Die Tests müssen die tatsächlich kritischen Prozesse und die vereinbarte Supporttiefe abbilden.

Abschlusskriterium: Das neue Team kann repräsentative Supportfälle innerhalb des vorgesehenen Prozesses selbstständig analysieren, koordinieren, dokumentieren und lösen.

Phase 5: Cutover, Hypercare und formale Abnahme

Beim Cutover geht die operative Verantwortung zu einem festgelegten Zeitpunkt auf den neuen SAP Support Partner über. Vorher muss eindeutig feststehen, wer ab diesem Moment neue Tickets annimmt, Monitoring-Alarme bearbeitet, Eskalationen koordiniert und mit SAP oder weiteren Anbietern kommuniziert.

Zum Cutover gehören insbesondere:

• Übertragung offener Tickets,
• Aktivierung der finalen Zugänge,
• Anpassung von Verteilerlisten und Supportkontakten,
• Übergabe der Monitoring-Verantwortung,
• Information der Key User und Fachbereiche,
• Überprüfung technischer Benutzer und Zertifikate,
• Einschränkung oder Entfernung nicht mehr benötigter Altanbieter-Zugänge.

In der anschließenden Hypercare-Phase sollten kurze tägliche Reviews stattfinden. Im Mittelpunkt stehen neue Incidents, fehlende Berechtigungen, offene Wissenslücken, Prozessabweichungen und bevorstehende geschäftskritische Termine.

Die Transition endet nicht automatisch nach einer festgelegten Anzahl von Tagen. Sie ist abgeschlossen, wenn der neue Dienstleister den vereinbarten Leistungsumfang eigenständig erbringt, kritische Prozesse stabil laufen und verbleibende Risiken einen verantwortlichen Owner und einen verbindlichen Maßnahmenplan haben.

Abschlusskriterium: Der neue SAP Support Partner arbeitet eigenständig, der Betrieb ist stabil, offene Transition-Punkte sind kontrolliert und der bisherige Dienstleister besitzt keine unnötigen Systemzugänge mehr.

SAP Support Transition strukturiert vorbereiten

Von der Bestandsaufnahme über den Wissenstransfer bis zu Shadowing, Cutover und Hypercare: LeverX begleitet die kontrollierte Übernahme komplexer SAP Support- und AMS-Umgebungen.

Transition mit LeverX besprechen

Welche Informationen und Zugänge müssen übergeben werden?

Eine SAP Support Übergabe ist erst dann vollständig, wenn der neue Dienstleister nicht nur Dokumente erhalten hat, sondern die relevanten Systeme, Prozesse und Betriebsaufgaben selbstständig nachvollziehen kann. Deshalb sollte jede Übergabe mit einem konkreten Validierungsschritt verbunden werden.

Besondere Aufmerksamkeit benötigen Informationen, die nicht in zentralen Dokumenten hinterlegt sind. Dazu gehören manuelle Arbeitsschritte, historisch entstandene Workarounds, lokale Prozessvarianten und Entscheidungen, die nur einzelnen Beratern oder Key Usern bekannt sind.

Die Übergabe sollte deshalb nicht anhand der Anzahl gelieferter Dateien abgenommen werden. Ein Dokument kann vorhanden und trotzdem veraltet, unvollständig oder im operativen Betrieb nicht nutzbar sein. Entscheidend ist, ob das neue Supportteam die beschriebenen Abläufe praktisch anwenden kann.

Für jeden Übergabebereich sollte daher ein eindeutiger Status verwendet werden:

• übergeben: Informationen oder Zugänge wurden bereitgestellt;
• geprüft: Inhalt und technische Nutzbarkeit wurden kontrolliert;
• validiert: Das neue Team hat den entsprechenden Prozess oder Supportfall erfolgreich ausgeführt;
• offen: Es besteht noch eine dokumentierte Lücke mit Owner und Termin.

Erst wenn geschäftskritische Bereiche validiert sind und verbleibende Lücken kontrolliert behandelt werden, sollte die operative Verantwortung vollständig auf den neuen SAP Support Partner übergehen.

Wie bleibt der SAP-Betrieb während des Wechsels stabil?

Ein stabiler SAP-Betrieb während des Dienstleisterwechsels entsteht nicht dadurch, dass alter und neuer Anbieter gleichzeitig für alles verantwortlich sind. Entscheidend ist vielmehr, dass für jeden Service, jedes Ticket und jede Eskalation jederzeit genau ein operativer Owner feststeht.

Besonders wichtig ist die klare Zuordnung offener Tickets. Für jeden Incident, jedes Problem und jeden Service Request sollte festgelegt sein, ob der bisherige Anbieter den Fall abschließt oder der neue Partner ihn übernimmt. Bei komplexen Fällen kann der alte Dienstleister unterstützend eingebunden bleiben, ohne dass dadurch die Gesamtverantwortung unklar wird.

Auch der Geschäftskalender muss Teil der Cutover-Entscheidung sein. Ein technisch geeigneter Termin kann operativ ungeeignet sein, wenn gleichzeitig ein Finanzabschluss, eine Inventur, ein Produktionshochlauf oder eine gesetzliche Meldefrist ansteht. Die verantwortlichen Fachbereiche sollten deshalb den Übergabezeitpunkt ausdrücklich freigeben.

Vor dem Cutover sollte außerdem geprüft werden, ob der neue Dienstleister Monitoring-Alarme tatsächlich empfängt, priorisiert und innerhalb des vereinbarten Prozesses bearbeitet. Dass ein Dashboard sichtbar ist, reicht nicht aus. Der vollständige Ablauf von der Alarmierung bis zur Eskalation muss funktionieren.

Für kritische Störungen benötigt die Übergangsphase einen gemeinsamen Major-Incident-Prozess. Dieser legt fest, wer die technische Koordination übernimmt, wer die Fachbereiche informiert, wer Entscheidungen über Workarounds oder Rollbacks trifft und wann SAP oder weitere Anbieter eingebunden werden.

In der Hypercare-Phase sollten neue Probleme nicht nur gelöst, sondern systematisch als Transition Issue klassifiziert werden. So lässt sich unterscheiden, ob eine Störung aus der bestehenden SAP-Landschaft stammt oder durch eine unvollständige Übergabe, fehlende Berechtigungen oder unklare Prozesse verursacht wurde.

Die operative Stabilität ist erreicht, wenn der neue SAP Support Partner kritische Incidents, Monitoring-Ereignisse und reguläre Supportanfragen eigenständig bearbeitet und keine wesentlichen Aufgaben mehr von informellen Absprachen mit dem bisherigen Dienstleister abhängen.

Wie lange dauert der Wechsel eines SAP Support Dienstleisters?

Die Dauer einer SAP Support Transition hängt weniger von der Unternehmensgröße als vom tatsächlichen Supportumfang, der Komplexität der Systemlandschaft und der Qualität des vorhandenen Betriebswissens ab. Als grobe Planungswerte können Unternehmen mit folgenden Zeiträumen rechnen:

Diese Zeiträume sind keine festen Zusagen. Eine vermeintlich kleine SAP-Landschaft kann eine längere Transition erfordern, wenn zentrale Prozesse nur unzureichend dokumentiert sind oder der Betrieb stark von einzelnen Personen abhängt. Umgekehrt lässt sich auch ein umfangreicher Scope effizient übertragen, wenn Dokumentation, Verantwortlichkeiten und Zugänge gut vorbereitet sind.

Zu den wichtigsten Einflussfaktoren gehören:

• Anzahl der Systeme, Module, Länder und Gesellschaften,
• Umfang individueller Entwicklungen und Schnittstellen,
• Qualität und Aktualität der Dokumentation,
• Anzahl offener Tickets und bekannter Probleme,
• Verfügbarkeit interner Prozessverantwortlicher,
• Mitwirkung des bisherigen Dienstleisters,
• notwendige Supportzeiten und Sprachen,
• regulatorische Anforderungen und geschützte Geschäftszeiträume.

Die Transition sollte deshalb nicht allein über einen Endtermin gesteuert werden. Für jede Phase müssen Abnahmekriterien gelten. Verzögert sich beispielsweise das Reverse Shadowing, weil das neue Team kritische Supportfälle noch nicht selbstständig bearbeiten kann, sollte der Cutover nicht nur zur Einhaltung des ursprünglichen Zeitplans erfolgen.

Der Wechsel ist abgeschlossen, wenn der neue SAP Support Partner den vereinbarten Leistungsumfang eigenständig erbringt, die notwendigen Zugänge funktionieren, kritische Support-Szenarien validiert wurden und verbleibende Risiken kontrolliert bearbeitet werden.

Checkliste: SAP Support Dienstleister sicher wechseln

Die folgende Checkliste fasst die wichtigsten Voraussetzungen für eine kontrollierte SAP Support Transition zusammen.

Vor der Kündigung

• Kündigungsfristen und automatische Vertragsverlängerungen prüfen
• Exit-Unterstützung und Mitwirkungspflichten des bisherigen Anbieters klären
• Eigentum an Dokumentation, Quellcode, Ticketdaten und Arbeitsergebnissen prüfen
• Künftigen Supportumfang und Zielbetriebsmodell definieren
• Neuen SAP Support Partner auswählen
• Verantwortlichen Transition Manager auf Kundenseite benennen
• Administrative Kontrolle über SAP for Me, S-User und zentrale Tools sicherstellen
• Kritische Geschäftszeiträume und geplante Projekte berücksichtigen

Vor dem Cutover

• Systeme, Module, Geschäftsprozesse und Verantwortlichkeiten vollständig erfassen
• Transition-Plan, RACI und Eskalationsmodell freigeben
• Offene Incidents, Problems und Service Requests eindeutig zuordnen
• Kritische Dokumentationen, Runbooks und Known Errors übergeben
• Technische und funktionale Zugänge praktisch testen
• Monitoring, Alarmierung und Major-Incident-Prozess validieren
• Wissenstransfer anhand realer Prozesse und Supportfälle durchführen
• Shadowing und Reverse Shadowing erfolgreich abschließen
• Offene Wissens- und Dokumentationslücken mit Owner und Termin dokumentieren
• Fachbereiche und Key User über neue Supportwege informieren
• Cutover durch IT und betroffene Prozessverantwortliche freigeben

Nach dem Cutover

• Hypercare mit kurzen täglichen Status- und Risikoreviews durchführen
• Neue Incidents auf mögliche Transition-Ursachen prüfen
• Nicht mehr benötigte Zugänge des bisherigen Dienstleisters entfernen
• Technische Benutzer, Passwörter, Tokens und Zertifikate überprüfen
• Offene Transition-Punkte verbindlich nachverfolgen
• SLA-Erfüllung, Ticketqualität und Eskalationen eng überwachen
• Formale Abnahme anhand der vereinbarten Exit-Kriterien dokumentieren
• Erstes reguläres Service Review mit dem neuen Anbieter terminieren

Der Wechsel sollte erst dann als abgeschlossen gelten, wenn der neue Dienstleister den vereinbarten Supportumfang eigenständig erbringt und keine kritischen Aufgaben mehr von informellem Wissen oder Zugängen des bisherigen Partners abhängen.

FAQ zum Wechsel eines SAP Support Dienstleisters

Kann der bisherige SAP Dienstleister den Wechsel verhindern?

Ein Anbieter kann den Wechsel grundsätzlich nicht dauerhaft verhindern. Vertragsfristen, Exit-Regelungen, offene Zahlungen oder ungeklärte Rechte an Dokumentationen und Arbeitsergebnissen können die Transition jedoch verzögern. Deshalb sollten Einkauf und Rechtsabteilung die vertraglichen Verpflichtungen frühzeitig prüfen. Besonders wichtig ist, welche Unterstützung der bisherige Dienstleister während der Übergabe leisten muss.

Ist ein Wechsel auch ohne vollständige SAP-Dokumentation möglich?

Ja, allerdings erhöht eine unvollständige Dokumentation Aufwand und Risiko. Fehlende Informationen müssen dann durch Systemanalysen, Interviews, Tickethistorien und praktische Prozess-Workshops rekonstruiert werden. Kritische Lücken sollten vor dem Cutover identifiziert werden. Der Wechsel muss nicht warten, bis jedes Dokument perfekt ist, aber alle geschäftskritischen Risiken benötigen einen Owner und einen Maßnahmenplan.

Müssen alter und neuer SAP Support Partner parallel arbeiten?

Nicht zwingend bei allen Leistungen. Eine zeitlich begrenzte Zusammenarbeit ist jedoch für kritische Systeme und komplexe Supportbereiche häufig sinnvoll. Während des Shadowings beobachtet der neue Anbieter die Bearbeitung realer Fälle. Im Reverse Shadowing übernimmt er die Aufgaben selbst. Dabei muss für jedes Ticket und jeden Service trotzdem ein eindeutiger operativer Owner feststehen.

Was passiert mit offenen SAP-Tickets während der Transition?

Alle offenen Incidents, Problems und Service Requests sollten vor dem Cutover geprüft, priorisiert und einem Verantwortlichen zugeordnet werden. Der bisherige Anbieter kann ausgewählte Fälle abschließen, während andere kontrolliert an den neuen Partner übergeben werden. Zu jedem übernommenen Ticket gehören Bearbeitungsstand, bisherige Analysen, beteiligte Ansprechpartner, bekannte Risiken und der nächste geplante Schritt.

Muss bei einem AMS-Anbieterwechsel auch der SAP-Wartungsvertrag geändert werden?

Nein, nicht automatisch. Der Wechsel eines operativen AMS- oder SAP Support Dienstleisters und eine Änderung des SAP-Wartungsvertrags sind grundsätzlich getrennte Entscheidungen. Abhängig vom bestehenden Vertragsmodell, den genutzten SAP-Produkten und der Partnerzuordnung können jedoch zusätzliche Anpassungen notwendig sein. Die konkrete Konstellation sollte daher mit SAP, Einkauf und der Rechtsabteilung geprüft werden.

Wie viel interne Kapazität benötigt eine SAP Support Transition?

Auch bei einer weitgehend ausgelagerten Transition werden interne Ansprechpartner benötigt. Dazu gehören mindestens ein Transition Owner sowie Verantwortliche für zentrale Geschäftsprozesse, SAP-Architektur, Berechtigungen und Service Management. Der interne Aufwand ist meist in Analyse, Wissenstransfer, Validierung und Cutover am höchsten. Ohne verfügbare Prozessverantwortliche können wichtige Fragen nicht zuverlässig geklärt werden.

Wann ist eine SAP Support Übergabe offiziell abgeschlossen?

Die Übergabe ist abgeschlossen, wenn der neue Dienstleister den vereinbarten Leistungsumfang eigenständig erbringt und die definierten Abnahmekriterien erfüllt. Dazu gehören funktionierende Zugänge, validierte Support-Szenarien, übernommene Tickets, einsatzbereites Monitoring und klare Eskalationswege. Offene Restpunkte sind möglich, sofern sie dokumentiert, bewertet und mit einem verantwortlichen Owner versehen sind.

Fazit: Der Wechsel gelingt durch kontrollierte Übergabe

Ein Wechsel des SAP Support Dienstleisters ist kein einzelner Cutover-Termin, sondern die kontrollierte Übertragung von Wissen, Zugängen, Prozessen und operativer Verantwortung. Unternehmen reduzieren das Risiko, wenn sie den Supportumfang frühzeitig abgrenzen, klare Zuständigkeiten festlegen und die Einsatzfähigkeit des neuen Partners praktisch validieren.

Drei Faktoren sind besonders wichtig: eindeutige Ownership, ein strukturierter Wissenstransfer und eine risikobasierte Übergangsphase mit klaren Abnahmekriterien. Dokumente allein reichen nicht aus. Entscheidend ist, ob der neue Dienstleister kritische Supportfälle, Monitoring-Ereignisse und Eskalationen selbstständig bearbeiten kann.

Prüfen Sie, wie sicher Ihre SAP Support Transition vorbereitet ist

LeverX analysiert gemeinsam mit Ihnen den aktuellen Supportumfang, bestehende Wissens- und Dokumentationslücken, kritische Abhängigkeiten sowie den realistischen Aufwand für die Übernahme durch einen neuen SAP Support Partner.

SAP Support Transition besprechen