Es gibt einen Zustand, den viele Betriebe kennen: Das System läuft. Es macht, was es soll. Aber niemand traut sich mehr, etwas daran zu ändern. Der Entwickler von damals ist nicht mehr erreichbar, die Dokumentation existiert nur in den Köpfen von zwei Kollegen, und jede Anpassung fühlt sich an wie eine Operation ohne Röntgenbild.
Solange nichts passiert, geht das gut. Kritisch wird es, wenn eine gesetzliche Änderung ansteht, ein Server ersetzt werden muss oder der letzte Kollege geht, der das System kennt.
Wann eine Ablösung nötig ist – und wann nicht
Alt ist kein Grund. Ein System, das fachlich passt, stabil läuft und gepflegt werden kann, darf zwanzig Jahre alt sein. Der Austausch kostet Geld und Nerven, und beides sollte einen Anlass haben.
Echte Anlässe gibt es vier:
- Niemand kann es mehr ändern. Der Entwickler ist weg, die Technik ist so alt, dass sich kaum jemand damit auskennt.
- Die Umgebung wird unsicher. Betriebssystem oder Datenbank bekommen keine Sicherheitsupdates mehr. Das ist der dringlichste Fall, weil er ein Risiko darstellt, das nicht wartet.
- Es blockiert das Geschäft. Neue Anforderungen lassen sich nicht abbilden, jede Anpassung dauert Wochen.
- Die Wartung wird unbezahlbar. Weil nur noch wenige Spezialisten es können, und die entsprechend kosten.
Fehlt jeder dieser vier Punkte, ist die ehrliche Empfehlung: laufen lassen. Was in dem Fall trotzdem lohnt, ist eine Bestandsaufnahme, damit das Wissen nicht an einzelnen Personen hängt.
Warum der Stichtag selten funktioniert
Die naheliegende Vorstellung: Am Freitag läuft das alte System, am Montag das neue. Bei kleinen, abgegrenzten Systemen geht das. Bei allem, was über Jahre gewachsen ist, ist es die riskanteste Variante – aus drei Gründen.
Erstens kennt niemand den vollen Funktionsumfang. In gewachsenen Systemen stecken Sonderfälle, an die sich keiner mehr erinnert, bis sie fehlen. Zweitens gibt es keinen Weg zurück: Fällt am Montag etwas Wesentliches aus, steht der Betrieb. Drittens ist die Belastung fürs Team enorm – alles ändert sich gleichzeitig.
Schritt 1: Bestandsaufnahme
Bevor irgendetwas gebaut wird, muss klar sein, was das alte System eigentlich tut. Das klingt trivial und ist der aufwendigste Teil – besonders, wenn niemand mehr da ist, der es erklären kann.
Was dabei entsteht, ist eine Landkarte: Welche Abläufe laufen darüber? Welche Daten liegen darin? Welche anderen Systeme hängen daran? Und, oft übersehen: Welche Auswertungen zieht jemand regelmäßig daraus, ohne dass es im Handbuch steht?
Eine Methode, die gut funktioniert: einen Tag mit den Leuten verbringen, die täglich damit arbeiten, und zusehen. Nicht fragen, was das System kann – sondern beobachten, was sie tatsächlich tun. Dabei kommen die Umwege ans Licht, die niemand mehr erwähnt, weil sie zur Gewohnheit geworden sind.
Schritt 2: Die richtige Reihenfolge
Nicht alles auf einmal, aber auch nicht beliebig. Bewährt hat sich, mit einem Bereich zu beginnen, der drei Eigenschaften hat: abgegrenzt, sichtbar nützlich und nicht geschäftskritisch.
Abgegrenzt, damit er sich lösen lässt, ohne alles andere anzufassen. Sichtbar nützlich, damit das Team früh merkt, dass sich etwas verbessert – das trägt durch die späteren, mühsameren Schritte. Und nicht geschäftskritisch, weil die ersten Schritte immer auch Lernschritte sind.
| Reihenfolge | Warum |
|---|---|
| Auswertungen und Berichte | lesen nur, ändern nichts – risikoarmer Einstieg |
| Abgegrenzte Nebenabläufe | sichtbarer Nutzen bei überschaubarem Risiko |
| Stammdaten | Grundlage für alles Weitere |
| Kernablauf | der große Schritt – mit Erfahrung aus den vorigen |
| Abschaltung des Altsystems | erst wenn nachweislich nichts mehr darauf zugreift |
Schritt 3: Datenmigration
Hier entstehen die meisten bösen Überraschungen. Altdaten sind nie so sauber wie erinnert: derselbe Kunde dreimal angelegt, Pflichtfelder leer, weil sie früher keine waren, drei Schreibweisen für denselben Ort, Beträge mal mit Punkt, mal mit Komma.
Was hilft, ist ein nüchternes Vorgehen in vier Schritten:
- Analysieren. Wie viele Datensätze, wie viele Dubletten, wie viele mit fehlenden Pflichtfeldern? Erst zählen, dann planen.
- Entscheiden. Was wird übernommen, was archiviert, was verworfen? Nicht alles muss mit – Adressen von Kunden, die seit zwölf Jahren nichts bestellt haben, können ins Archiv.
- Probelauf. Die Migration wird mehrfach durchgespielt, bevor sie zählt. Beim ersten Mal geht immer etwas schief; das ist der Sinn der Übung.
- Abgleichen. Nach der Migration wird geprüft: Stimmen die Anzahlen? Stimmen die Summen? Stichproben mit dem Fachbereich.
Der Parallelbetrieb
Für eine Weile laufen beide Systeme. Das ist unbequem, aber der Preis für die Sicherheit – und es gibt drei Punkte, die vorher geklärt sein müssen.
Wer führt? Für jeden Datenbereich muss festgelegt sein, welches System die Wahrheit hält. Zwei Systeme, in denen dieselben Daten gepflegt werden, laufen garantiert auseinander.
Wie lange? Der Parallelbetrieb braucht ein Enddatum. Ohne eines wird er zum Dauerzustand, und dann zahlt man zwei Systeme und pflegt alles doppelt.
Was sagt man dem Team? Menschen arbeiten mit dem System weiter, das sie kennen – besonders wenn es hektisch wird. Der Wechsel braucht eine klare Ansage, ab wann was gilt, und jemanden, der bei Fragen erreichbar ist.
Was mit den Altdaten passiert
Ein Punkt, der gern vergessen wird: Handels- und steuerrechtliche Aufbewahrungsfristen gelten weiter, auch für Daten, die im neuen System nicht mehr gebraucht werden. Das alte System einfach abzuschalten und den Server zu entsorgen, ist keine gute Idee.
Üblich sind zwei Wege: Die Altdaten werden in einem unveränderbaren Archivformat abgelegt, oder das alte System bleibt in einer abgeschotteten Umgebung lesend verfügbar. Welcher Weg passt, hängt davon ab, wie oft jemand darauf zugreifen muss – und was der Steuerberater dazu sagt.
Typische Fehler
- Das Alte eins zu eins nachbauen. In gewachsenen Systemen steckt viel, was nur existiert, weil es damals nicht anders ging. Eine Ablösung ist die Gelegenheit, das wegzulassen – aber bewusst, nicht aus Versehen.
- Den Fachbereich außen vor lassen. Wer täglich damit arbeitet, kennt die Sonderfälle. Ohne diese Leute baut man ein System für ein Unternehmen, das es so nicht gibt.
- Die Datenmigration unterschätzen. Sie ist oft der größte Einzelposten und wird fast immer zu klein geplant.
- Keinen Weg zurück vorsehen. Jeder Schritt sollte umkehrbar sein, solange das Alte noch läuft.
- Zu früh abschalten. Erst wenn nachweislich nichts mehr auf das alte System zugreift – und das prüft man, indem man es einen Tag lang abschaltet und schaut, wer sich meldet.
Häufige Fragen
Muss der Betrieb während der Umstellung stillstehen?
Nein, wenn schrittweise vorgegangen wird. Das alte System bleibt in Betrieb, während einzelne Bereiche nacheinander abgelöst werden. Ein Stichtag mit kompletter Umstellung über Nacht ist die riskanteste Variante – sie funktioniert nur bei kleinen, klar abgegrenzten Systemen.
Was passiert mit den alten Daten?
Sie werden übernommen, geprüft und in der Regel zusätzlich als unveränderbares Archiv aufbewahrt. Wichtig sind zwei Dinge: eine Abgleichprüfung, die belegt, dass nichts verloren ging, und die Einhaltung der handels- und steuerrechtlichen Aufbewahrungsfristen – auch für Daten, die im neuen System nicht mehr gebraucht werden.
Woran erkennt man, dass eine Ablösung nötig wird?
Typische Anzeichen: Niemand traut sich mehr an Änderungen, der ursprüngliche Entwickler ist nicht mehr verfügbar, das System läuft auf einer veralteten Umgebung ohne Sicherheitsupdates, oder jede kleine Anpassung dauert Wochen. Ein System, das fachlich passt und stabil läuft, muss dagegen nicht ersetzt werden – auch wenn es alt ist.
Wie lange dauert so eine Ablösung?
Bei schrittweisem Vorgehen rechnet man in Monaten, nicht in Wochen – wobei nach dem ersten Schritt schon etwas Nutzbares vorliegt. Die Gesamtdauer hängt vor allem an der Zahl der Schnittstellen und am Zustand der Altdaten, weniger am Funktionsumfang.
Wir haben keine Dokumentation. Geht es trotzdem?
Ja, das ist eher die Regel als die Ausnahme. Dann beginnt das Projekt mit einer Bestandsaufnahme: Datenbank ansehen, Abläufe beobachten, mit den Leuten sprechen, die es täglich nutzen. Das kostet Zeit, ist aber machbar – und das Ergebnis ist die Dokumentation, die vorher gefehlt hat.