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:

1. 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.
2. 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 dafür ist Conjola gebaut: Die KI analysiert Ihre Eigenentwicklungen aus dem Extrakt, beschreibt, was jedes Objekt tut, gruppiert sie thematisch und ordnet sie Ihren fachlichen Themen zu. Daneben steht die Transaktionsnutzung aus der ST03N je System und Buchungskreis, und FeatureInsights zeigt, was pro Buchungskreis wirklich genutzt wird — so wird belegbar, welche Z-Transaktionen und Features niemand mehr aufruft. Die Entscheidung je Objekt treffen Sie, und was verabschiedet wird, halten Sie als Stilllegungsvermerk fest. Jährlich wiederholbar, statt einmaliger Momentaufnahme.