Datenmigration im Mittelstand: Was wirklich schiefgeht

Warum die Daten nie so daliegen, wie das neue System sie erwartet

Jedes System, das ein Unternehmen neu einführt, hat eine Vorstellung davon, wie ein Datensatz aussehen soll. Ein Kunde hat eine Nummer. Eine Adresse hat eine Postleitzahl. Ein Auftrag hat ein Datum. Diese Vorstellungen sind einleuchtend, weil sie aus einem Moment stammen, in dem jemand von außen auf den Betrieb geschaut und entschieden hat, was ein Datensatz braucht.

Was sie nicht abbilden, ist die Geschichte des Betriebs.

In einem Verwaltungsunternehmen zum Beispiel wurde das Feld „Notiz" im alten System irgendwann zur einzigen Möglichkeit, eine zweite Kontaktperson zu hinterlegen. Das Feld war da, das Bedürfnis war da — also hat man es genutzt. Wer das weiß, liest die Notiz anders als wer es nicht weiß. Das neue System hat ein eigenes Feld für Kontaktpersonen. Es kann mit einer Notiz, die eine halbe Adresse enthält, nichts anfangen.

Das ist kein Fehler im System und kein Fehler im alten System. Es ist das Ergebnis davon, dass Software im Alltag benutzt wird — und Alltag selten so aussieht wie das Handbuch, das zum Zeitpunkt der Einführung galt.

Wenn ein Feld zu viel getragen hat

Solche Felder gibt es in fast jedem Betrieb, der länger als drei Jahre mit derselben Software arbeitet. Das Kommentarfeld, in dem Zahlungskonditionen hinterlegt wurden. Die Kundennummer, deren vierte Stelle eigentlich eine Regionszuordnung codiert, die aber nirgends dokumentiert steht. Das Datumsfeld, in das manche Mitarbeitenden den Eingang, andere die Fälligkeit eingetragen haben — je nachdem, was sie gerade brauchten.

• Freitextfelder, in denen strukturierte Information steckt, die sich nicht automatisch herauslesen lässt
• Pflichtfelder im neuen System, die im alten nie existierten — und deshalb in Tausenden von Datensätzen leer sind
• Felder, die in beiden Systemen „Kategorie" heißen, aber unterschiedliche Wertelisten dahinter haben
• Datumswerte, die je nach Nutzer oder Abteilung unterschiedlich interpretiert wurden
• Beträge, die in einem System mit Mehrwertsteuer, im anderen ohne erfasst wurden — ohne dass das irgendwo vermerkt ist

Keines dieser Probleme ist beim ersten Blick auf einen Export sichtbar. Ein Datenexport aus dem Altsystem kann vollständig wirken — alle Spalten vorhanden, alle Zeilen befüllt. Erst wenn das neue System versucht, diese Daten einzulesen, zeigt sich, was in den Jahren zwischen Einführung und heute passiert ist.

Das Wissen steckt in den Köpfen, nicht in den Feldbeschreibungen

Was folgt, ist meistens keine technische Arbeit, sondern eine inhaltliche: Jemand muss entscheiden, was die Notiz wirklich bedeutet. Jemand muss die Regionszuordnung aus der Kundennummer rekonstruieren. Jemand muss festlegen, welches Datum in das neue Feld kommt — und was mit den Datensätzen passiert, in denen beide Interpretationen möglich wären.

Diese Entscheidungen können nicht vom System getroffen werden. Sie müssen von Menschen getroffen werden, die den Betrieb kennen und sich erinnern, warum das Feld damals so befüllt wurde. Wie viel Zeit das kostet, hängt davon ab, ob diese Menschen noch im Betrieb sind, ob sie erreichbar sind, und ob das Wissen über die eigenen Daten überhaupt noch irgendwo hängt — oder ob es mit jemandem gegangen ist, der vor zwei Jahren das Unternehmen verlassen hat.

Genau das ist der Moment, in dem eine Migration stockt, die auf dem Papier zwei Wochen dauern sollte.

Was mit Jahren gewachsener Datenpflege passiert, wenn jemand hinsieht

Irgendwann zu Beginn einer Migration schaut jemand genauer hin. Meistens ist das kein freudiger Moment. Die Daten, die seit Jahren in einem System liegen, sehen von außen geordnet aus — Spalten, Felder, Datensätze. Aber wer den Export öffnet, sieht etwas anderes.

Er sieht Arbeitsgeschichte. Jede Mitarbeiterin, die das System je benutzt hat, hat ihre eigenen Gewohnheiten hinterlassen. Die eine hat Ortsbezeichnungen in das Postleitzahlen-Feld eingetragen, weil sie die PLZ gerade nicht zur Hand hatte. Der andere hat Freitextnotizen ins Telefonnummer-Feld geschrieben, weil es das einzige Feld war, das er schnell genug fand. Beide haben nichts falsch gemacht — sie haben eine Aufgabe erledigt und das System so benutzt, wie es sich in diesem Moment anbot.

Was sich im Laufe der Jahre ansammelt, ist selten dramatisch. Es ist kleinteilig:

• Felder, die ursprünglich eine Bedeutung hatten und heute eine andere haben — ohne dass jemand die alten Einträge angepasst hat
• Kundenkategorien, die zwei Mal umbenannt wurden, aber deren alte Werte noch unverändert im System stehen
• Duplikate, weil ein Kontakt einmal unter dem Firmennamen und einmal unter dem Namen der Ansprechpartnerin angelegt wurde
• Pflichtfelder, die nie wirklich Pflicht waren, weil das System sie nicht erzwungen hat — und die deshalb bei einem Drittel der Datensätze leer geblieben sind
• Datumsangaben in drei verschiedenen Formaten, je nachdem, wann und von wem ein Eintrag stammt

Keine dieser Abweichungen war Nachlässigkeit. Jede ist die Spur einer Situation, in der jemand eine Entscheidung getroffen hat, die in diesem Moment vernünftig war. Das neue System versteht das nicht. Es erwartet Einheitlichkeit — und bekommt Wirklichkeit.

Besonders heikel ist, was in den Freitextfeldern steht. Wer genau liest, findet dort Dinge, die nie als Teil des Datenstamms gedacht waren: interne Kommentare über Kunden, provisorische Preisabsprachen, Notizen aus Telefonaten, die eigentlich in eine E-Mail gehört hätten. All das ist technisch Teil des Exports. Wer es ins neue System übernimmt, zieht informelle Betriebsgeschichte in eine frische Struktur. Wer es weglässt, weiß nicht, was er verliert — und wird es erst Monate später merken, wenn jemand nach genau diesem Kontakt sucht.

Das Eigenartige an diesem Moment ist, dass die Daten nicht schlechter geworden sind. Sie waren immer so. Das bisherige System hat sie nach seinen eigenen Regeln angezeigt — Abweichungen blieben unsichtbar, weil niemand nach ihnen gesucht hat. Erst wenn jemand fragt, wie die Daten in ein anderes System passen sollen, wird aus einem funktionierenden Betrieb ein Datenproblem. Nicht weil etwas kaputtgegangen ist. Sondern weil jetzt jemand hinschaut.

Wer im Betrieb für die Migration zuständig ist — und warum das niemand sagen kann

In fast jedem Gespräch über einen Systemwechsel kommt irgendwann die Frage: Wer ist eigentlich zuständig? Die Antwort darauf ist selten eine Person. Meistens ist sie eine Pause.

Das liegt nicht daran, dass niemand Verantwortung übernehmen will. Es liegt daran, dass die Daten, die migriert werden sollen, nie einer einzigen Stelle gehören — auch wenn das auf dem Papier so steht.

Die IT kennt die Struktur, aber nicht die Bedeutung

Die Person, die den Server verwaltet und den Export aus dem Altsystem durchführen kann, weiß häufig nicht, was die einzelnen Felder im Alltag bedeuten. Sie weiß, dass es eine Spalte „Status" gibt. Sie weiß nicht, dass dieser Status seit drei Jahren von zwei verschiedenen Kolleginnen unterschiedlich befüllt wird — eine schreibt „offen", die andere „in Bearbeitung" — und dass beide dasselbe meinen.

Wenn die IT fragt, ob das Feld übernommen werden soll, ist die ehrliche Antwort: Ja, aber welcher Wert gilt? Und wer entscheidet das?

Die Fachabteilung kennt die Bedeutung, aber nicht die Struktur

Die Vertriebsleiterin weiß genau, welche Kundeninformationen sie täglich braucht. Sie weiß, welche davon verlässlich sind und welche seit Jahren niemand mehr anfasst. Was sie nicht weiß: wie diese Informationen im System abgelegt sind, in wie vielen Tabellen sie verteilt sind und was passiert, wenn eine Adresse an drei verschiedenen Stellen leicht voneinander abweicht.

Sie kann sagen, was ankommen soll. Nicht, wie man es herausholt.

Wenn beide Seiten aufeinandertreffen

Was entsteht, ist eine Zuständigkeit, die zwischen Abteilungen pendelt. Die IT wartet auf eine inhaltliche Entscheidung. Die Fachabteilung wartet auf eine technische Einschätzung. Die Geschäftsführung hat das Projekt genehmigt, aber keinen Zeitbudget für die Klärungsgespräche eingeplant, die es braucht, bevor der erste Datensatz bewegt wird.

In mittelständischen Betrieben kommt hinzu, dass es keine neutrale Stelle gibt, die beides versteht — und die Zeit hat, beides zusammenzuführen. Diese Rolle fällt dann jemandem zu, der sie nie gesucht hat: der Projektleiter, der sich in Datenstrukturen einarbeitet. Die Buchhalterin, die erklärt, warum Kundennummern nicht eindeutig sind. Der Geschäftsführer, der am Ende selbst entscheidet, welche der drei Varianten von „Interessent" ins neue System übernommen wird.

• Die Entscheidung, welche Daten überhaupt migriert werden, fällt oft zu spät — wenn das neue System schon eingerichtet ist.
• Daten, über deren Qualität niemand sprechen wollte, werden einfach übernommen.
• Verantwortung für Fehler nach der Migration ist noch schwerer zuzuordnen als vorher.

Das Ergebnis ist nicht, dass das Projekt scheitert. Meistens wird es fertig. Aber die Frage, wer für die Daten zuständig ist, ist am Ende genauso unbeantwortet wie am Anfang — nur dass das neue System jetzt läuft und niemand mehr Zeit hat, sie zu stellen.

Exportformate, die auf dem Papier stimmen und in der Praxis nicht passen

Wenn das alte System Daten exportiert, sieht das Ergebnis zunächst vollständig aus: eine Datei, ein paar Tausend Zeilen, alles drin. Der Anbieter des neuen Systems sagt, das Format werde unterstützt. Der Dienstleister, der die Migration begleitet, nickt. Dann beginnt der Import — und die Hälfte der Datensätze schlägt fehl.

Das liegt selten daran, dass irgendjemand unrecht hatte. CSV ist kein einheitliches Format. Eine Exportdatei mit Semikolon als Trennzeichen unterscheidet sich von einer mit Komma. Datumsangaben im Format 15.03.2019 und 2019-03-15 enthalten dieselbe Information, aber kein System liest das andere ohne Anpassung. Umlaute, die im alten System korrekt angezeigt werden, tauchen im neuen als unleserliche Zeichen auf — weil beide Seiten unterschiedliche Zeichensätze verwenden und das beim Export niemandem aufgefallen ist.

Was beim Vergleich auffällt — und was nicht

Ein Dienstleister, der eine Exportdatei prüft, sieht die Spaltenüberschriften und die Struktur. Was er nicht sieht: ob das Feld „Betrag" im alten System Brutto- oder Nettowerte enthält, ob Leerzeichen am Anfang von Adressfeldern mitexportiert werden, ob leere Felder als wirklich leer oder als Nullwert kodiert sind. Diese Unterschiede sind im Export unsichtbar. Sie zeigen sich erst, wenn Buchungen falsch zugeordnet werden oder Adressen in Suchabfragen nicht mehr gefunden werden.

Ein häufiger Fall: Das alte System speichert Telefonnummern ohne feste Formatierung. Eine Mitarbeiterin hat sie mit Bindestrich eingetragen, eine andere mit Leerzeichen, manche mit Ländervorwahl, manche ohne. Das neue System erwartet ein einheitliches Muster für die automatische Zuordnung. Der Export ist technisch korrekt — er bildet genau ab, was vorher drinstand. Das Problem liegt nicht im Format, sondern in dem, was über Jahre in das alte System eingetragen wurde.

Felder, die im Export fehlen, weil sie nie als Felder existiert haben

Manche Informationen stecken nicht in eigenen Feldern, sondern in Freitextnotizen. Eine Maklerin, die für bestimmte Eigentümer besondere Absprachen im Notizfeld vermerkt hat, wird feststellen, dass diese Information im neuen System keinen Platz findet — weil das neue System dafür kein entsprechendes Feld vorsieht oder weil Freitexte beim Import nicht übernommen werden. Was exportiert wird, ist das, was das alte System strukturiert gespeichert hat. Der Rest bleibt im alten System — oder verschwindet.

• Trennzeichen: Komma, Semikolon oder Tabulator — jede Variante ist gültig, keine ist universell.
• Datumsformate: Amerikanisch, europäisch, ISO — dasselbe Datum, drei Schreibweisen, und das neue System kennt nur eine davon.
• Zeichensätze: Was im alten System als Ä, Ö, Ü erscheint, kann im Export zu Fragezeichen werden, wenn beide Seiten unterschiedliche Kodierungen verwenden.
• Leerwerte: Ein leeres Feld kann im Export als zwei aufeinanderfolgende Trennzeichen erscheinen, als Wort „NULL" oder als nichts — drei Darstellungen, die das neue System unterschiedlich interpretiert.

Exportformate sind Vertragssprache zwischen zwei Systemen. Sie regeln, was übertragen wird — aber nicht, was damit gemeint war. Wenn ein Anbieter sagt, er unterstütze den Import einer bestimmten Dateiart, bedeutet das, dass sein System eine bestimmte Variante davon lesen kann. Ob das genau die Variante ist, die das alte System erzeugt, steht auf einem anderen Blatt. Diesen Abgleich im Voraus zu machen kostet Zeit. Ihn im Nachhinein zu machen, wenn die ersten Datensätze falsch importiert wurden, kostet mehr.

Warum ein Parallelbetrieb länger dauert als geplant

Die ursprüngliche Idee klingt vernünftig: Beide Systeme laufen für eine Weile nebeneinander, bis das neue sich bewährt hat, dann wird das alte abgeschaltet. Vier Wochen, vielleicht sechs. In der Praxis werden daraus oft vier Monate — manchmal mehr.

Der erste Grund ist unscheinbar: Niemand weiß genau, wann der Parallelbetrieb als abgeschlossen gilt. Es gibt kein vereinbartes Kriterium, keinen definierten Zustand, der als Ziel dient. Also läuft er weiter.

Zwei Systeme, zwei Wahrheiten

Sobald dieselben Vorgänge in zwei Systemen geführt werden, entstehen Abweichungen. Ein Auftrag, der im alten System als abgeschlossen gilt, taucht im neuen noch als offen auf. Eine Adresse wurde in einem System aktualisiert, im anderen nicht. Wer hat recht? Diese Frage lässt sich nicht automatisch beantworten — sie braucht jemanden, der nachschaut, vergleicht und entscheidet.

In vielen Betrieben übernimmt das dieselbe Person, die ohnehin schon zu wenig Zeit hat. Die ungeklärten Abweichungen häufen sich. Jede kostet Aufmerksamkeit, jede ungeklärte verlängert den Betrieb beider Systeme um weitere Wochen.

Das alte System wird zum Sicherheitsnetz

Irgendwann nutzen die meisten das neue System für neue Vorgänge und schauen für alles, was vorher passiert ist, im alten nach. Das klingt pragmatisch. Es ist auch die Situation, in der sich das alte System nie ganz abschalten lässt: Es enthält Informationen, die nicht vollständig ins neue überführt wurden — sei es, weil die Übernahme sie nicht erfasst hat, sei es, weil das neue System sie gar nicht abbilden kann.

Dann fängt jemand an, Dinge per Hand zu übertragen. Einzelne Einträge, Sonderfälle, Ausnahmen. Das ist nicht geplant und erscheint in keiner Aufwandsschätzung. Es passiert trotzdem, weil der Betrieb nicht aufhören kann zu warten.

Berichte, die nicht übereinstimmen

Wenn der Monatsbericht aus dem neuen System andere Zahlen zeigt als der gewohnte Bericht aus dem alten, müssen beide erklärt werden. Das kostet Zeit — und solange die Erklärung aussteht, vertraut niemand dem neuen System genug, um das alte freizugeben. Manchmal sind die Zahlen unterschiedlich, weil die Auswertungslogik sich geändert hat und beide Ergebnisse technisch korrekt sind. Das ist schwerer zu kommunizieren als ein offensichtlicher Fehler.

In Betrieben mit mehreren Standorten oder Abteilungen verschärft sich das: Jede Gruppe hat ihre eigene Vertrauensschwelle. Solange eine Abteilung noch offene Fragen hat, bleibt das alte System für alle zugänglich — und damit in Betrieb.

• Ungeklärte Abweichungen zwischen den Systemen verlängern den Parallelbetrieb automatisch.
• Fehlende Zugriffsrechte im neuen System zwingen Mitarbeiter ins alte zurück.
• Historische Daten, die nicht vollständig übernommen wurden, machen das alte System unentbehrlich.
• Berichte mit unterschiedlichen Ergebnissen blockieren die Freigabe, auch wenn beide rechnerisch stimmen.

Der Parallelbetrieb endet selten mit einer Entscheidung. Er endet meistens damit, dass das alte System irgendwann nicht mehr gewartet wird, Zugänge ablaufen oder die einzige Person, die noch weiß, wie man darin navigiert, das Unternehmen verlässt. Dann ist die Migration abgeschlossen — ohne dass jemand diesen Moment geplant hätte.

Was übrig bleibt, wenn das neue System läuft und das alte nicht mehr erreichbar ist

Die ersten Wochen nach dem Abschalten verlaufen meist unauffällig. Das neue System läuft, die laufenden Vorgänge sind dort abgebildet, und wer täglich damit arbeitet, gewöhnt sich schneller an die neue Oberfläche als erwartet. Dann kommt die erste Anfrage, bei der jemand zurückblicken muss — auf einen Auftrag von vor zwei Jahren, eine Korrespondenz aus dem Jahr davor, einen Datensatz, der damals als abgeschlossen galt und deshalb nie in die Migration einbezogen wurde.

In diesem Moment zeigt sich, was die Migration tatsächlich übertragen hat. Nicht das, was im Protokoll stand — sondern das, was danach noch gesucht wird.

Die Lücken, die erst nach Monaten sichtbar werden

Historische Daten werden bei Migrationen häufig nach einem Stichtag getrennt: Alles ab einem bestimmten Datum kommt mit, alles davor bleibt im Altsystem oder wird archiviert. Das klingt vernünftig — solange niemand auf die alte Seite zurück muss. Passiert es doch, ist das Altsystem entweder abgeschaltet, die Zugangsdaten sind weg, oder die Installation läuft noch irgendwo auf einem alten Rechner, den niemand mehr anfasst, weil niemand mehr weiß, was passiert, wenn man ihn neustartet.

Was dann bleibt, ist meistens ein Export: eine Handvoll Dateien, die zum Zeitpunkt der Migration gezogen wurden und seitdem unberührt auf einem Server oder einer externen Festplatte liegen. Wer darin etwas sucht, braucht erstens die richtige Datei, zweitens das Wissen, wie die alten Felder hießen, und drittens jemanden, der sich noch erinnert, was damals mit einem bestimmten Wert gemeint war.

Was mit dem Erfahrungswissen passiert

In vielen Betrieben gibt es eine Person — manchmal zwei —, die wissen, wie man das alte System liest. Sie kennen die Abkürzungen in den Statusfeldern, wissen, welche Spalte eigentlich den Rechnungsbetrag enthält, obwohl sie anders beschriftet ist, und erinnern sich daran, dass bestimmte Einträge früher anders erfasst wurden als heute. Dieses Wissen ist nirgendwo dokumentiert. Es war nie nötig, weil die Person immer da war.

Nach der Migration verliert es seinen Ort. Das neue System kennt diese Konventionen nicht. Wer ein halbes Jahr später anfängt, steht vor einem Archiv, das sie oder er nicht interpretieren kann — und fragt bei jemandem nach, der selbst nicht mehr sicher ist.

• Alte Kundennummern, die in Verträgen und E-Mails auftauchen, aber im neuen System nicht mehr existieren
• Auswertungen aus dem Altsystem, auf die Kollegen sich noch beziehen, obwohl die zugrunde liegenden Daten längst nicht mehr zugänglich sind
• Felder, die zwar migriert wurden, deren Bedeutung sich im Laufe der Jahre aber verändert hatte — und die deshalb im neuen System falsch eingeordnet sind, ohne dass es jemand bemerkt

Das Abschalten des alten Systems markiert keinen sauberen Schnitt. Es markiert den Beginn eines anderen Problems: das Verwalten von etwas, das nicht mehr gepflegt werden kann, aber auch nicht vollständig verschwunden ist. Die Frage, die dabei offen bleibt, ist nicht technischer Natur — sie lautet: Wer ist zuständig, wenn etwas gesucht wird, das eigentlich hätte mitgenommen werden sollen?