Teil 1: Das Projekt und warum es KMU etwas angeht (ca. 5 Min.)
Die Landesverwaltung Schleswig-Holstein treibt den nächsten Schritt ihrer Strategie für digitale Souveränität voran. Nach dem Umstieg auf LibreOffice, Open-Xchange und perspektivisch Linux nimmt das Land nun auch individuell entwickelte Fachverfahren ins Visier.
Mehr als 100 dieser Anwendungen basieren auf Microsoft Access. Sie sollen schrittweise durch moderne, webbasierte Lösungen abgelöst werden – ein relevanter Teil davon noch im Jahr 2026. Als technische Grundlage dient die A12 AI Enterprise Low-Code-Plattform des deutschen Anbieters mgm technology partners, betrieben in den Rechenzentren des Landes-IT-Dienstleisters Dataport.
Diese Größenordnung klingt zunächst nach einem Problem, das nur große Verwaltungen betrifft. Tatsächlich dürfte die Situation vielen kleineren Unternehmen bekannt vorkommen. Statt „Fachverfahren” heißen die Programme dort vielleicht Kundendatenbank, Auftragsübersicht, Werkzeugverwaltung, Kalkulation, Zeiterfassung oder Lagerliste.
Wenn aus einer kleinen Datenbank ein unverzichtbares System wird
Viele problematische Altsysteme wurden nicht schlecht geplant. Sie wurden überhaupt nicht als dauerhaftes Unternehmenssystem geplant.
Eine Access-Datenbank beginnt häufig mit einer einfachen Aufgabe: Kundendaten sollen besser sortiert werden, eine kleine Oberfläche für Bestellungen entsteht, oder die Geschäftsführung braucht eine übersichtlichere Auswertung. Access eignet sich gut dafür, Formulare, Tabellen, Abfragen und Berichte vergleichsweise schnell miteinander zu verbinden.
Über die Jahre wächst das Konstrukt: Neue Tabellen kommen hinzu, Makros werden eingebaut, immer mehr Arbeitsabläufe hängen daran. Irgendwann steckt in der ursprünglich kleinen Datei ein großer Teil des Wissens über einen betrieblichen Prozess.
Kritisch wird es, wenn niemand mehr genau erklären kann, wie das Ganze funktioniert. Vielleicht hat der Kollege, der es entwickelt hat, das Unternehmen längst verlassen. Vielleicht liegen das letzte Kennwort, eine Beschreibung der Tabellenstruktur oder die Installationsdateien nur noch auf einem alten Rechner.
Aus einem praktischen Hilfsmittel ist so unbemerkt ein geschäftskritisches Altsystem geworden.
Access ist nicht automatisch das Problem
Nicht jede Access-Datenbank muss sofort ersetzt werden. Entscheidend ist, ob das Unternehmen sie noch kontrolliert.
Es wäre zu einfach, Microsoft Access pauschal als unsicher oder ungeeignet darzustellen. Eine kleine, gepflegte Datenbank kann ihren Zweck über Jahre zuverlässig erfüllen. Das eigentliche Risiko entsteht meist nicht durch den Produktnamen, sondern durch den Umgang mit der Anwendung.
Gefährlich wird eine Lösung, wenn sie nicht dokumentiert ist, keine geregelte Datensicherung besitzt oder nur auf einem einzelnen Arbeitsplatz läuft. Ebenso kritisch: Prozesse, die von Makros, alten Treibern, veralteten Office-Versionen oder fest eingetragenen Dateipfaden abhängen.
In manchen Betrieben kann nur eine bestimmte Person Rechnungsdaten importieren. In anderen läuft das System ausschließlich auf einem älteren Computer, weil eine benötigte Komponente auf neuen Geräten nicht mehr installierbar ist. Oft weiß niemand, was eine Änderung an einer Tabelle oder einem Formular tatsächlich auslösen würde.
Das ist keine klassische Abhängigkeit von Microsoft. Es ist eine Abhängigkeit von fehlender Dokumentation, einzelnen Personen und historisch gewachsenen Sonderlösungen.
Teil 2: Personelle Risiken und der Weg von Schleswig-Holstein (ca. 5 Min.)
Das größte Risiko sitzt oft zwischen Stuhl und Bildschirm
Wenn nur ein Mensch weiß, wie ein zentrales System funktioniert, besitzt das Unternehmen kein belastbares Verfahren – sondern persönliches Spezialwissen.
Personelle Abhängigkeiten gehören zu den häufigsten Risiken kleiner Unternehmen. Das betrifft nicht nur Access-Datenbanken, sondern genauso komplexe Excel-Dateien, selbst geschriebene Skripte, alte Warenwirtschaftssysteme oder individuell angepasste Branchenprogramme.
Solange die zuständige Person erreichbar ist, fällt das Problem kaum auf. Erst bei Krankheit, Urlaub, Kündigung oder Ruhestand zeigt sich, wie viel Wissen nie schriftlich festgehalten wurde.
Dabei muss die Anwendung nicht komplett ausfallen – schon eine Kleinigkeit reicht. Ein neuer Rechner wird angeschafft, ein Netzlaufwerk bekommt einen anderen Buchstaben, ein Update verändert das Verhalten eines Makros. Plötzlich lassen sich Rechnungen nicht mehr erzeugen, Aufträge nicht mehr zuordnen oder Daten nicht mehr exportieren.
Besonders gefährlich wird es, wenn gleichzeitig keine aktuelle, geprüfte Sicherung existiert. Eine kopierte Datei auf demselben Rechner ist noch kein verlässliches Backup. Unternehmen sollten wissen, welche Dateien, Zusatzkomponenten, Kennwörter und Einstellungen nötig sind, um ein Verfahren auf einem anderen System wiederherzustellen.
Was Schleswig-Holstein anders machen will
Das Land ersetzt nicht einfach eine Anwendung durch eine andere. Es organisiert gleichzeitig Wissen, Betrieb und Weiterentwicklung neu.
Schleswig-Holstein setzt bei der Ablösung der Access-Verfahren auf modellbasierte Softwareentwicklung. Über die A12-Plattform entstehen webbasierte Fachanwendungen, die sowohl extern als auch von geschulten eigenen Beschäftigten weiterentwickelt werden können.
Dafür baut die Landesverwaltung ein Low-Code-Kompetenzcenter im Zentralen IT-Management der Staatskanzlei auf. Mitarbeitende sollen so qualifiziert werden, dass neue Anwendungen nicht ausschließlich von externen Dienstleistern abhängen. Die entwickelten Verfahren sollen zudem anderen Verwaltungen zur Nachnutzung zur Verfügung stehen.
Auch der Betrieb ist Teil des Konzepts: Die Plattform läuft in den Rechenzentren von Dataport, Anwendungen und Daten bleiben also innerhalb einer kontrollierten öffentlichen Infrastruktur. Eine spätere Nachnutzung durch weitere Dataport-Trägerländer ist eingeplant. Das ist ein wichtiger Unterschied zu vielen klassischen Digitalisierungsprojekten: Digitale Souveränität bedeutet hier nicht nur, eine bestimmte Software einzusetzen, sondern Anwendungen betreiben, prüfen, sichern, verändern und im Zweifel zu einem anderen Anbieter übertragen zu können.
A12 wird teilweise Open Source
Offener Quellcode kann Abhängigkeiten reduzieren – beseitigt sie aber nicht automatisch.
Im Mai 2026 veröffentlichte mgm technology partners zentrale Bestandteile der A12-Plattform unter der European Union Public Licence 1.2. Quellcode, Dokumentation und Entwicklungswerkzeuge wurden über die Verwaltungsplattform openCode sowie über GitHub bereitgestellt. Schleswig-Holstein, das Zentrum für Digitale Souveränität und mgm streben langfristig zudem eine Einbindung in den Deutschland-Stack an.
Bei aller Einordnung bleibt Genauigkeit wichtig: Die Landesregierung spricht von zentralen Bestandteilen der Plattform, nicht zwangsläufig von einer vollständig geöffneten Gesamtlösung. Für die veröffentlichten A12-Komponenten wird zudem eine Wahl zwischen der europäischen Open-Source-Lizenz EUPL 1.2 und einer kommerziellen Lizenz beschrieben.
Für Unternehmen folgt daraus eine wichtige Grundregel: Die Bezeichnung „Open Source” allein beantwortet noch nicht alle Fragen. Vor einer Einführung muss geklärt werden, welche Bestandteile tatsächlich offen verfügbar sind, welche Erweiterungen benötigt werden, wie sich Daten exportieren lassen und wer den laufenden Betrieb übernimmt.
Ein offenes System ohne Dokumentation und ohne verfügbares Fachwissen kann im Alltag genauso problematisch werden wie eine proprietäre Anwendung. Umgekehrt kann eine kommerzielle Lösung durchaus sinnvoll sein, wenn Datenzugriff, Exportmöglichkeiten, Vertragsbedingungen und Zuständigkeiten klar geregelt sind.
Teil 3: Was kleine Unternehmen konkret mitnehmen können (ca. 5 Min.)
Schritt 1: Eine ehrliche Bestandsaufnahme
Der erste Schritt ist nicht die sofortige Ablösung alter Anwendungen, sondern eine ehrliche Bestandsaufnahme.
Viele Unternehmen haben keinen vollständigen Überblick über ihre selbst entwickelten Datenbanken und Tabellen. Einige liegen auf Netzlaufwerken, andere auf einzelnen Arbeitsplätzen oder in privaten Benutzerordnern. Manche werden täglich gebraucht, andere nur einmal im Monat oder zum Jahresabschluss.
Für jede dieser Anwendungen lohnt sich die Frage: Welchem Zweck dient sie, wer nutzt sie, welche Daten stecken darin – und welche Geschäftsprozesse würden ohne sie nicht mehr funktionieren?
Ebenso wichtig: Wer hat sie erstellt oder zuletzt verändert? Existiert eine Dokumentation? Sind Kennwörter, Installationsdateien und Lizenzinformationen verfügbar? Lässt sie sich auf einem anderen Rechner starten? Gibt es einen dokumentierten Export der enthaltenen Daten?
Erst danach lässt sich entscheiden, ob eine bestehende Lösung weiterbetrieben, technisch modernisiert oder vollständig ersetzt werden sollte. Eine kleine Adressliste mit wenigen Einträgen hat schließlich eine andere Priorität als ein System, über das Angebote kalkuliert, Wartungstermine verwaltet oder abrechnungsrelevante Arbeitszeiten erfasst werden.
Schritt 2: Nicht jede Eigenentwicklung braucht eine neue Eigenentwicklung
Bevor eine alte Datenbank individuell nachgebaut wird, sollte geprüft werden, ob eine Standardlösung den Prozess bereits abdeckt.
Viele Access- und Excel-Konstrukte entstanden, weil früher keine passende oder bezahlbare Software verfügbar war. Heute gibt es für zahlreiche Aufgaben offene und kommerzielle Alternativen.
Kundenverwaltung, Angebote, Aufträge, Rechnungen, Projekte und Produkte lassen sich beispielsweise in einem ERP- oder CRM-System zusammenführen – eine Lösung wie Dolibarr kann interessant sein, wenn bislang mehrere Einzellösungen parallel laufen. Dokumente, Freigaben und gemeinsame Dateien lassen sich über Nextcloud, ein Dokumentenmanagementsystem oder eine klar strukturierte Ablage organisieren. Für besonders individuelle Prozesse können moderne Webanwendungen oder Low-Code-Plattformen sinnvoll sein.
Entscheidend ist nicht, möglichst schnell ein neues Werkzeug einzuführen, sondern zunächst zu prüfen, ob der bestehende Ablauf überhaupt noch sinnvoll ist. Wer einen komplizierten, schlecht dokumentierten Prozess unverändert digitalisiert, bekommt am Ende nur ein modernes System mit den alten Problemen.
Schritt 3: Migration beginnt mit den Daten
Oberflächen lassen sich neu entwickeln. Verlorene oder falsch zugeordnete Daten deutlich schwerer.
Vor jeder Ablösung muss klar sein, welche Informationen in der alten Anwendung stecken – nicht nur die sichtbaren Tabellen, sondern auch Beziehungen zwischen Datensätzen, Berechnungsregeln, Pflichtfelder, Makros, Abfragen und Berichte.
In vielen älteren Datenbanken finden sich doppelte Kundeneinträge, uneinheitliche Schreibweisen oder Felder, deren Bedeutung niemand mehr kennt. Solche Altlasten sollten nicht ungeprüft ins neue System übernommen werden. Eine Migration ist deshalb auch eine Gelegenheit, Daten zu bereinigen und Zuständigkeiten neu festzulegen – bei gleichzeitig nachvollziehbarer Archivierung des ursprünglichen Bestands, gerade wenn steuerliche, vertragliche oder personenbezogene Aufbewahrungsfristen greifen.
Vor der endgültigen Umstellung sollte das neue System außerdem mit realistischen Beispieldaten getestet werden – nicht nur, ob sich Datensätze öffnen lassen, sondern auch, ob typische Auswertungen, Exporte, Berechtigungen und Sicherungsprozesse tatsächlich funktionieren.
Schritt 4: Webanwendung heißt nicht automatisch sicherer
Eine moderne Oberfläche ist noch kein Sicherheitskonzept.
Webbasierte Anwendungen bieten viele Vorteile: Sie funktionieren unabhängig vom einzelnen Arbeitsplatz, lassen sich zentral aktualisieren und trennen Daten, Oberfläche und Geschäftslogik klarer voneinander.
Gleichzeitig entstehen neue Pflichten. Der Server muss gewartet, die Anwendung aktualisiert, der Zugriff abgesichert werden. Benutzerkonten brauchen passende Berechtigungen, Protokolle, Backups und Wiederherstellungstests müssen eingerichtet sein.
Wer eine lokale Access-Datei durch eine selbst gehostete Webanwendung ersetzt, übernimmt damit zusätzliche Verantwortung – das kann sinnvoll sein, sollte aber bewusst geplant werden. Alternativ kann ein spezialisierter Dienstleister den Betrieb übernehmen. Dann muss vertraglich geregelt sein, wo die Daten liegen, wie Sicherungen erfolgen und in welchem Format man seine Informationen bei einem Anbieterwechsel zurückbekommt.
Der richtige Zeitpunkt ist vor dem Ausfall
Altsysteme werden selten in Ruhe ersetzt, wenn bereits nichts mehr funktioniert.
Solange eine alte Datenbank zuverlässig läuft, wirkt ihre Ablösung selten dringend. Genau dann bestehen jedoch die besten Bedingungen für eine geordnete Migration: Daten lassen sich prüfen, Prozesse dokumentieren, verschiedene Lösungen testen – ohne akuten Zeitdruck im laufenden Betrieb.
Nach einem Ausfall ändern sich die Prioritäten. Dann geht es nicht mehr um die beste langfristige Lösung, sondern darum, Rechnungen zu schreiben, Aufträge zu bearbeiten oder Kundendaten wieder verfügbar zu machen. Entscheidungen unter Zeitdruck führen oft zu Übergangslösungen, die länger im Einsatz bleiben als geplant.
Fazit: Eine Vorlage für den Mittelstand
Die wichtigste Botschaft lautet nicht „Access muss weg”. Sie lautet: Kritische Anwendungen müssen beherrschbar bleiben.
Schleswig-Holstein zeigt mit der geplanten Ablösung von mehr als 100 Access-Verfahren, wie groß der Bestand historisch gewachsener Anwendungen selbst in einer zentral organisierten Verwaltung sein kann. Kleine Unternehmen besitzen im Vergleich meist deutlich weniger Einzellösungen – dafür treffen Ausfälle sie oft unmittelbarer, weil selten eine eigene IT-Abteilung bereitsteht, um das Problem zu analysieren.
Digitale Souveränität beginnt deshalb nicht erst bei der Entscheidung zwischen Microsoft, Linux oder Open Source. Sie beginnt mit grundlegenden Fragen: Weiß das Unternehmen, wo seine Daten liegen? Lassen sie sich vollständig exportieren? Ist das Verfahren dokumentiert? Existiert eine geprüfte Sicherung? Könnte ein anderer Mitarbeiter oder Dienstleister das System übernehmen?
Wer diese Fragen beantworten kann, muss eine funktionierende Access-Datenbank nicht überstürzt abschalten. Wer sie nicht beantworten kann, sollte mit der Bestandsaufnahme beginnen – bevor aus einer kleinen Datei eine große Betriebsunterbrechung wird.
Quelle der aktuellen Meldung: Landesregierung Schleswig-Holstein, „Land löst Microsoft Access ab”, veröffentlicht bzw. zuletzt aktualisiert am 7. Juli 2026.
