Ein neues ERP, ein modernes Kundenportal oder die Ablöse einer gewachsenen
Access-Datenbank beginnt selten bei null.
Meist müssen Jahre an Aufträgen, Artikelstämmen, Produktionsdaten, Dokumenten und Kundendaten mit.
Genau hier entstehen Datenmigration Risiken:
Nicht die Menge der Daten ist das Hauptproblem, sondern ihre Bedeutung für den laufenden Betrieb.
Ein fehlender Statuswert kann einen Auftrag stoppen. Doppelte Kundennummern verfälschen Auswertungen. Ein falsch zugeordnetes Dokument erschwert die Nachweispflicht. Deshalb ist Datenmigration keine technische Nebenaufgabe am Ende eines Softwareprojekts. Sie ist ein eigener, fachlicher Prozess, der früh geplant und gemeinsam mit den betroffenen Abteilungen abgesichert werden muss.
Warum Datenmigrationen im Mittelstand anspruchsvoll sind
In österreichischen Unternehmen sind Prozesse oft über Jahre gewachsen. Ein ERP wurde erweitert, Excel-Listen ergänzen fehlende Funktionen, Maschinen liefern Daten in eigenen Formaten und wichtige Informationen stecken in Freitextfeldern oder gescannten Dokumenten. Was im Alltag funktioniert, ist für eine Migration nicht automatisch eindeutig.
Ein Beispiel aus der Produktion: Im Altsystem kann ein Artikel über Materialnummer, Zeichnungsstand und eine interne Bezeichnung identifiziert werden. Im neuen System soll eine eindeutige Artikel-ID gelten. Ohne klare Regeln ist nicht sicher, ob zwei ähnlich benannte Datensätze tatsächlich derselbe Artikel sind. Werden sie fälschlich zusammengeführt, entstehen später Fehler in Stücklisten, Lagerbeständen oder der Nachkalkulation.
Die technische Übertragung ist damit nur ein Teil der Aufgabe. Entscheidend ist, wie Daten fachlich interpretiert, bereinigt und in die Logik des neuen Systems überführt werden. Das braucht Verantwortliche aus Fachbereich und IT - nicht nur ein Importskript.
Migrationsvorhaben besprechen (30 min)
Sie planen ein konkretes Softwareprojekt, möchten ein bestehendes System weiterentwickeln oder ablösen.
Die häufigsten Datenmigration Risiken
Unklare Datenqualität wird mitübersiedelt
Altdaten enthalten häufig Dubletten, unvollständige Pflichtfelder, veraltete Ansprechpartner oder uneinheitliche Schreibweisen. Werden diese Bestände ohne Prüfung übernommen, startet das neue System mit denselben Problemen - oft schwerer erkennbar, weil sie nun in neuen Masken und Prozessen auftreten.
Bereinigung kostet Zeit. Dennoch sollte sie nicht pauschal auf alle historischen Daten angewendet werden. Bei zehn Jahre alten Vorgängen kann es sinnvoller sein, sie revisionssicher im Altsystem oder in einem Archiv verfügbar zu halten, statt sie vollständig in die operative Datenbank zu überführen. Welche Historie wirklich benötigt wird, hängt von gesetzlichen Aufbewahrungspflichten, Servicefällen und Auswertungsanforderungen ab.
Falsch verstandene Datenfelder und Regeln
Gleich benannte Felder bedeuten nicht zwingend dasselbe. Ein Feld „Status“ kann in einem System den Bearbeitungsstand eines Auftrags meinen, im anderen die Freigabe für die Verrechnung. Auch Datumsfelder, Mengen, Einheiten oder Preislogiken können abweichen.
Besonders kritisch wird es bei Beziehungen zwischen Daten. Ein Kunde ist mit mehreren Standorten verbunden, ein Auftrag mit Teilaufträgen, ein Produktionslos mit Maschinenmeldungen und Qualitätsprüfungen. Fehlen diese Verknüpfungen nach der Migration, wirken einzelne Datensätze auf den ersten Blick korrekt. Im operativen Ablauf fehlen dann jedoch Zusammenhänge, auf die Disposition, Buchhaltung oder Service angewiesen sind.
Schnittstellen werden zu spät berücksichtigt
Ein neues System steht selten allein. Es tauscht Daten mit Webshops, Speditionen, Zeiterfassung, Finanzbuchhaltung, Maschinensteuerungen oder Kundenportalen aus. Wenn Identifikatoren, Formate und Übergabezeitpunkte während der Migration geändert werden, müssen alle beteiligten Schnittstellen angepasst und getestet werden.
Ein klassischer Fehler ist, nur den Datenimport zu prüfen. Die eigentliche Störung entsteht erst danach: Ein Lagerbestand wird zwar korrekt übernommen, aber die Schnittstelle zum Versand übergibt eine neue Artikelnummer nicht. Deshalb gehören Schnittstellen in den Migrationsplan - inklusive klarer Zuständigkeit für jeden Datenfluss.
Der Cutover wird unterschätzt
Begriff
Als Cutover wird der Zeitpunkt bezeichnet, an dem vom alten auf das neue System umgestellt wird.
In dieser Phase müssen letzte Änderungen abgeglichen, offene Vorgänge behandelt, Daten final importiert und Benutzer informiert werden. Je später man diese Schritte konkret plant, desto höher das Risiko für Stillstand, Doppelarbeit oder widersprüchliche Datenstände.
Ein Wochenende reicht nicht automatisch aus. Bei einem Betrieb mit Schichtarbeit, laufender Produktion oder zeitkritischer Logistik muss genau festgelegt sein, welche Transaktionen bis wann noch im Altsystem stattfinden dürfen. Ebenso wichtig ist eine realistische Rückfalloption, falls ein kritischer Test beim Produktivstart scheitert.
Datenschutz und Berechtigungen geraten aus dem Blick
Mit Kundendaten, Mitarbeiterdaten oder Dokumenten werden oft personenbezogene und vertrauliche Informationen migriert. Das betrifft nicht nur die sichere Übertragung. Berechtigungen müssen im Zielsystem korrekt abgebildet sein, damit Mitarbeitende nach dem Start genau die Daten sehen, die sie für ihre Aufgabe benötigen - und nicht mehr.
Auch Testumgebungen verdienen Aufmerksamkeit. Für Tests reichen häufig anonymisierte oder reduzierte Datensätze. Werden echte Daten verwendet, braucht es definierte Zugriffe, eine sichere Ablage und klare Löschfristen.
Datenmigration Risiken mit einem belastbaren Vorgehen senken
Eine sichere Migration beginnt mit einer Bestandsaufnahme. Dabei wird nicht nur geklärt, welche Tabellen vorhanden sind. Relevanter sind Fragen wie: Welche Daten werden täglich benötigt? Wer verantwortet ihre fachliche Richtigkeit? Welche Felder steuern Folgeprozesse? Welche Informationen müssen aus rechtlichen oder vertraglichen Gründen erhalten bleiben?
Das Ergebnis sollte ein nachvollziehbares Datenmapping sein. Es dokumentiert, aus welchem Quellfeld ein Zielfeld entsteht, welche Werte umgerechnet werden und wie mit fehlenden oder ungültigen Angaben umzugehen ist. Bei individuellen Lösungen kann dieses Mapping direkt mit den vorgesehenen Geschäftsregeln abgestimmt werden. So wird sichtbar, ob das neue System einen Prozess tatsächlich besser abbildet oder lediglich alte Schwächen übernimmt.
Danach folgen Testmigrationen. Ein Test mit wenigen Beispieldaten zeigt, ob das technische Grundprinzip funktioniert. Er ersetzt aber keinen Test mit realistischen Mengen, Sonderfällen und vollständigen Abhängigkeiten. Gerade offene Aufträge, Teilrechnungen, Seriennummern, Chargen oder mehrsprachige Dokumente müssen gezielt geprüft werden.
Für die Abnahme braucht es messbare Kriterien. Statt „Die Daten sehen gut aus“ sollten Unternehmen etwa festlegen:
Messbare Abnahmekriterien
Stimmen die Anzahl aktiver Kunden und offener Aufträge? Sind Summen aus Lager, Debitoren oder Produktionsdaten plausibel? Lassen sich wichtige Vorgänge vom Import bis zur Ausgabe korrekt bearbeiten?
Solche Prüfungen verbinden technische Qualität mit dem tatsächlichen Geschäftsbetrieb.
In wenigen Schritten zu Ihrem Projekt.
Klare Rollen verhindern Entscheidungen unter Zeitdruck
Migrationen scheitern selten daran, dass niemand Daten exportieren kann.
Häufig fehlen fachliche Entscheidungen: Soll ein inaktiver Kunde übernommen werden? Welcher Wert gilt bei widersprüchlichen Stammdaten? Wie werden historische Dokumente auffindbar gemacht?
Diese Fragen brauchen früh benannte Ansprechpartner.
Fachabteilung
Die Fachabteilung entscheidet über Bedeutung und Priorität der Daten.
IT / Entwicklungspartner
Die IT beziehungsweise der Entwicklungspartner gestaltet die technische Umsetzung, Validierung und Protokollierung.
Projektleitung
Die Projektleitung sorgt dafür, dass offene Punkte nicht bis zum Cutover liegen bleiben.
Bewährt hat sich ein Entscheidungskatalog für Ausnahmen. Er hält fest, wie mit Dubletten, fehlenden Pflichtwerten, ungültigen Referenzen oder nicht migrierbaren Dateiformaten umgegangen wird. Das schafft Transparenz und verhindert, dass einzelne Mitarbeitende kurz vor dem Go-live improvisieren müssen.
Der Produktivstart braucht Kontrolle, nicht nur einen Termin
Nach der Umstellung ist die Migration nicht abgeschlossen. In den ersten Tagen sollten Fachbereiche und Technik gemeinsam auf auffällige Fälle achten: fehlende Belege, unerwartete Berechnungen, fehlerhafte Druckausgaben oder nicht laufende Schnittstellen. Ein definierter Supportkanal und rasche Zuständigkeiten helfen, kleine Fehler zu beheben, bevor sie Folgeprozesse beeinträchtigen.
Gleichzeitig sollte das Altsystem für eine vereinbarte Zeit lesbar bleiben, sofern Datenschutz, Lizenzlage und Infrastruktur das erlauben. Es dient nicht als dauerhafte Parallelwelt, sondern als Referenz für Rückfragen und Nachweise. Erst wenn die vereinbarten Kontrollen abgeschlossen sind, wird es geordnet archiviert oder abgeschaltet.
Eine gut vorbereitete Datenmigration schafft mehr als einen erfolgreichen Systemwechsel. Sie räumt gewachsene Datenbestände auf, macht Verantwortlichkeiten sichtbar und verbessert die Grundlage für verlässliche Prozesse. Wer Daten früh als fachliches Projekt behandelt, gewinnt beim Go-live vor allem eines: Kontrolle über den eigenen Betrieb.
FAQ – Frequently Asked Questions
Häufig gestellte Fragen
