Der Anruf, der bei mir am häufigsten landet, klingt fast immer gleich: „Unser Access-Entwickler ist weg – geht das jetzt noch, oder müssen wir alles neu bauen?“ Mal ist der Grund Ruhestand, mal Kündigung, mal – wie bei einem Unternehmensberater aus dem Produktionsumfeld, mit dem ich seit einiger Zeit arbeite – der Tod des Entwicklers. Der Anlass ändert sich, die Lage im Unternehmen ist danach immer dieselbe: Ein System, das seit Jahren läuft, und niemand mehr, der es versteht.
Woran es bei vielen KMU tatsächlich klemmt
Access-Anwendungen wachsen über Jahre. Ein Modul hier, eine Sonderauswertung dort, ein Formular, das „mal eben schnell“ für einen Kunden gebaut wurde und seitdem Kernprozess ist. Wer das gebaut hat, trägt die Struktur im Kopf – dokumentiert wird selten, weil es nie eilig genug schien. Fällt diese eine Person aus, ist nicht nur Code weg. Es ist das Wissen, warum der Code so aussieht, wie er aussieht.
Warum das Problem entsteht
Der naheliegende Reflex ist, schnell einen günstigen Ersatz zu finden – die nächste Freelancer-Plattform, der nächste Stundensatz unter fünfzig Euro. Der Unternehmensberater aus meinem Beispiel hat genau das versucht, mehrfach. Das Ergebnis war jedes Mal ähnlich: langsame Umsetzung, wenig Eigeninitiative, kein Wissen über SQL Server, keine Erfahrung darin, mit einer Geschäftsführung zu sprechen statt nur mit einem Ticket-System. Zwei VBA-Entwickler unterscheiden sich oft wie ein Panda von einem Porsche – beide haben vier Buchstaben im Namen, mehr nicht. Der Preis pro Stunde sagt darüber fast nichts aus.
Was konkret hilft
- Keine Panik-Migration. Ein funktionierendes Access-System ist kein Notfall, nur weil der Entwickler fehlt. Es wird erst zum Notfall, wenn niemand hinschaut.
- Dokumentation sichten – auch wenn es keine gibt. Meist existiert irgendetwas: alte E-Mails, Kommentare im Code, Excel-Nebenlisten. Das reicht als Startpunkt.
- Code analysieren, nicht nur überfliegen. Beim Unternehmensberater fiel der erste Mangel innerhalb kurzer Zeit auf: Ein Formular öffnete spürbar langsam. Ursache war ein Filter auf eine Spalte ohne Index – ein Klassiker in gewachsenen Access-Projekten, der sich fast identisch auch in SQL-Server-Datenbanken findet, wenn niemand die Indizierung pflegt.
- Optionen sauber bewerten. Weiterentwicklung, Teilmigration nach SQL Server oder Ablösung – die Entscheidung hängt vom Zustand des Codes ab, nicht vom Bauchgefühl.
- Nicht den nächstbilligen Freelancer buchen. Ein Berater, der selbst programmiert, direkt mit der Geschäftsführung spricht und keinen Wasserkopf mitbringt, deckt Mängel der Vorgänger auf, statt sie fortzuschreiben.
Wo der Ansatz an Grenzen stößt
Nicht jedes Access-System lohnt die Rettung. Wenn die Datenstruktur von Grund auf falsch angelegt ist oder die Anwendung nur noch einen Bruchteil der eigentlichen Prozesse abdeckt, ist eine Neukonzeption ehrlicher als ein weiteres Flickwerk. Eine erste Analyse ersetzt außerdem keine vollständige Bestandsaufnahme – sie zeigt nur, ob sich der nächste Schritt lohnt.
Was das für dich bedeutet, wenn du das selbst nicht bewertest
Für den Unternehmensberater aus dem Beispiel ging es am Ende um mehr als ein schnelles Formular-Fix. Die Mängel der Vorgänger offenzulegen machte die Lösung wartbarer und sicherer für die Zukunft. Und es eröffnete eine Perspektive, die vorher fehlte: ein Weg, Logik schrittweise auf SQL Server zu verlagern und die Datenbank später auch für ein KI-Interface anschlussfähig zu machen – ohne dass morgen ein ERP-Wechsel ansteht.
Wer sich das einmal anschauen lassen möchte, sichert sich ein kostenloses Erstgespräch über sesoft.de/kostenloses-erstgespraech-sichern.
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Modernisierung und Weiterentwicklung von Microsoft-Access-Anwendungen. Sein Schwerpunkt liegt auf der Übernahme gewachsener Systeme nach dem Ausfall des ursprünglichen Entwicklers und auf der schrittweisen Anbindung an SQL Server. Mehr unter sesoft.de/datenschaefer-soenke-schaefer.
