Ballast abwerfen: ungenutzte Eigenentwicklungen vor der Migration finden
Gewachsene SAP-Systeme tragen hunderte, oft tausende Eigenentwicklungen mit sich — Z-Programme, Z-Transaktionen, Erweiterungen. Dokumentiert ist davon meist wenig, und über die Jahre hat niemand mehr den Überblick, was davon eigentlich noch gebraucht wird.
Vor einer S/4- oder Cloud-Migration wird daraus ein handfestes Kostenproblem. Denn für jede einzelne Eigenentwicklung fällt eine Entscheidung: mitnehmen, ersetzen oder streichen. Und die teuerste Antwort ist die stillschweigende: Was nie hinterfragt wird, wird mitmigriert — inklusive Anpassungsaufwand, Testlast und dauerhafter Pflege. Für Code, den womöglich seit Jahren niemand mehr ausführt.
Warum die Einzelbewertung nicht skaliert
Der klassische Weg ist die manuelle Bestandsaufnahme: Ein Beratungsteam geht die Objektliste durch, befragt Entwickler und Fachbereich, bewertet Stück für Stück. Bei mehreren tausend Z-Objekten wird das schnell ein sechsstelliger Aufwand — und das Ergebnis ist eine Momentaufnahme, die mit dem nächsten Transport zu altern beginnt.
Dazu kommt: Die Befragten erinnern sich an das, was sie kennen. Genau die Entwicklungen, um die es geht — die vergessenen — hat niemand mehr auf dem Schirm.
Zwei Fragen statt tausend Einzelfälle
Belastbar wird die Entscheidung, wenn man sie auf zwei Fragen zurückführt, die sich beide aus Daten beantworten lassen:
- Was tut die Eigenentwicklung fachlich? Nicht der technische Name, sondern der Zweck: Gehört sie ins Finanzwesen, in die Logistik, ins Reporting? Eine KI-gestützte Analyse liest den Code und gruppiert die Objekte nach fachlichem Thema — aus einer unübersichtlichen Liste wird eine strukturierte Landkarte.
- Nutzt sie noch jemand? Die Nutzungsdaten zeigen pro Organisationseinheit, was tatsächlich im Einsatz ist — und was seit Monaten oder Jahren nicht mehr aufgerufen wurde.
Erst die Kombination macht den Unterschied. Eine ungenutzte Entwicklung, an der keine Org-Einheit mehr hängt, ist nicht „vermutlich verzichtbar” — sie ist belegbar tot und damit sicher abschaltbar.
Der günstigste Teil der Migration
Aus den beiden Antworten ergibt sich eine saubere Dreiteilung des Custom-Code-Bestands:
- Bleibt: genutzt und ohne Standard-Äquivalent — wird migriert und bewusst weiterbetrieben.
- Wird ersetzt: genutzt, aber im Zielbild durch Standard oder Cloud-Funktion abgedeckt — hier lohnt die Umstellung.
- Wird verabschiedet: nachweislich ungenutzt — wird nicht migriert, sondern gestrichen.
Die dritte Kategorie ist der einfachste Gewinn des ganzen Projekts: kein Migrationsaufwand, keine Testlast, keine künftige Pflege. Man muss sie nur belegen können — gegen Erinnerungen lässt sich streiten, gegen Nutzungsdaten nicht.
Genau das liefert Conjola: Die KI analysiert Ihre Eigenentwicklungen aus dem Extrakt, gruppiert sie thematisch und ordnet sie Ihren fachlichen Themen zu. FeatureInsights zeigt daneben, was pro Buchungskreis wirklich genutzt wird — ungenutzte Features und toter Custom Code werden belegbar. Jährlich wiederholbar, statt einmaliger Momentaufnahme.