Altsystem wird abgelöst: Wie kommen deine Daten vollständig mit?

Bei einer Ablösung bringt der neue Anbieter meist ein Importformat mit, aber selten den Export. Den baut, wer das Altsystem kennt oder sich hineinarbeitet. Das gilt auch, wenn ein Dritter das neue System liefert: Er weiss, was er empfangen kann, nicht, was in deinem alten System steckt. Deshalb beginnt jede Migration auf der Seite des Altsystems.

Welche Daten wo liegen und wo sie hängen bleiben

Datenart	Wo sie meist liegt	Typischer Stolperstein
Kunden und Konten	Tabellen für Kunden, Benutzer und Adressen	Dubletten, mehrere Adressen pro Kunde, Firmen- und Privatkonten gemischt
Passwörter	Als Hash in der Benutzertabelle, nie im Klartext	Das neue System kennt das Hash-Verfahren nicht. Shopify etwa nimmt beim Kunden-Import per CSV keine Passwörter an
Bestellungen und Rechnungen	Bestell-, Positions- und Statustabellen, dazu oft PDF-Dateien	Die Historie kommt nicht mit, Shopify übernimmt per Kunden-CSV keine Bestellungen. Die Aufbewahrungspflicht bleibt
Dateien, Bilder, Dokumente	Im Dateisystem, etwa in einem Upload-Ordner, nicht in der Datenbank	Der Datenbank-Export enthält nur Pfade. Die Dateien fehlen, oder die Pfade stimmen nicht mehr
Texte mit Umlauten und Sonderzeichen	Datenbankspalten mit eigener Zeichenkodierung	Doppelt kodierte Umlaute wie «Ã¼» statt «ü». MySQL-Spalten mit utf8mb3 speichern viele Emojis gar nicht
Einstellungen und Zusatzfelder	Serialisierte PHP-Werte oder JSON in einer Textspalte	PHP speichert die Länge jedes Textes mit. Ändert Suchen und Ersetzen oder eine Umkodierung sie, liefert unserialize() nur noch false
Verlauf und Notizen	Protokoll- und Historientabellen, Kommentare, Statuswechsel	Übernommen wird nur der aktuelle Stand, wer wann was geändert hat, geht verloren
Newsletter-Abonnenten	Eigene Tabelle oder externer Versanddienst	Einwilligungen ohne Zeitpunkt und Quelle, Abmeldungen werden wieder zu Abonnenten
Adressen der Seiten	Routing, Slugs, SEO-Felder	Alte Links laufen ins Leere. Google empfiehlt dauerhafte Weiterleitungen, in der Regel mindestens ein Jahr lang
Nummern und Verknüpfungen	Kunden- und Rechnungsnummern, IDs für ERP, Buchhaltung und Zahlungsanbieter	Neue Nummern brechen den Abgleich mit Buchhaltung und offenen Zahlungen

Bei den Passwörtern gibt es einen Mittelweg, wenn das neue System mitspielt: Es übernimmt die alten Hashes, prüft beim nächsten Login das Passwort nach dem alten Verfahren und speichert es danach neu. In PHP-Anwendungen hilft dabei die Funktion password_needs_rehash(), die erkennt, ob ein Hash noch dem gewünschten Verfahren entspricht. Geht das nicht, brauchen deine Kunden eine Einladung, ein neues Passwort zu setzen, und die gehört in die Planung, nicht in die Woche nach dem Stichtag.

Datenmigration in 12 Schritten

1. Datenlandkarte erstellen. Welche Datenarten gibt es, wo liegen sie (Datenbank, Dateisystem, externe Dienste), und wer ist fachlich dafür zuständig?
2. Umfang entscheiden. Was kommt mit, was wird archiviert, was gelöscht? Halte die Begründung fest.
3. Zielformat klären. Welche Felder, Pflichtfelder und Importwege bietet das neue System? Lass dir das vom neuen Anbieter schriftlich geben.
4. Feld-Mapping schreiben. Feld für Feld von alt nach neu, inklusive Umrechnungen wie Status, Länder, Steuersätze und Masseinheiten.
5. Vollbackup ziehen. Datenbank, Dateien und Konfiguration des Altsystems, gespeichert ausserhalb des Servers, Wiederherstellung einmal getestet.
6. Daten bereinigen. Dubletten, Testdatensätze und verwaiste Einträge entfernen, im Altsystem oder im Exportskript, nie von Hand im Zielsystem.
7. Export als Skript bauen. Wiederholbar statt Handarbeit: Jeder Lauf liefert aus demselben Stand dasselbe Ergebnis.
8. Probeexport in eine Testumgebung. Vollständige Daten ins echte Zielsystem, aber in eine Testinstanz, auf die nur die Personen zugreifen, die prüfen.
9. Abgleichen. Anzahlen, Summen und Abweichungen ins Abgleichprotokoll. Jede Abweichung braucht eine Begründung.
10. Fachabnahme durch die Leute, die täglich mit den Daten arbeiten. Stichproben wie drei bekannte Kunden, die letzte Bestellung, eine alte Rechnung und ein bekannter Sonderfall.
11. Stichtag mit Delta-Export. Altsystem auf Nur-Lesen stellen, alle Änderungen seit dem letzten Probelauf exportieren, abgleichen und umschalten. Weiterleitungen und Schnittstellen ziehen am selben Tag mit.
12. Altsystem geordnet abschalten. Ein lesbares Archiv für alles, was aufbewahrt werden muss, dann Server, Datenbank, Exportdateien und Backups löschen, die niemand mehr braucht. Halte fest, was wann gelöscht wurde.

Vorlage: Abgleichprotokoll

Das Abgleichprotokoll ist dein Beleg, dass die Migration vollständig ist. Pro Datenart eine Zeile, ausgefüllt nach jedem Probelauf und am Stichtag:

Objekt	Anzahl alt	Anzahl neu	Summe	Abweichung	Begründung
Kunden			–
Kundenkonten mit Login			–
Bestellungen (Zeitraum angeben)			Bestellwert brutto
Bestellpositionen			Menge
Rechnungen			Rechnungsbetrag
Produkte und Varianten			–
Dateien und Bilder			Gesamtgrösse
Newsletter-Abonnenten mit Einwilligung			–
Weiterleitungen			–

• Summe: ein Wert, der sich unabhängig von der Anzahl prüfen lässt. Stimmt die Anzahl, aber nicht die Summe, ist unterwegs etwas falsch übertragen worden.
• Abweichung: Anzahl alt minus Anzahl neu, bei Summen die Differenz.
• Begründung: zum Beispiel «Testbestellungen bewusst nicht übernommen». Eine Abweichung ohne Begründung ist ein Fehler, bis das Gegenteil belegt ist.

Wenn das Altsystem keinen Export hat

Am zuverlässigsten ist der direkte Zugang zur Datenbank, dazu die Dateien auf dem Server. An zweiter Stelle kommt eine Schnittstelle des Altsystems, falls es eine gibt. Bietet das Altsystem weder das eine noch das andere, bleibt das Auslesen der eigenen Website oder Oberfläche per Scraper. Das kommt nur für deine eigenen Daten in Frage, auf die du berechtigt zugreifst. Zugangssperren umgehen oder fremde Inhalte einsammeln gehört nicht dazu.

Aus der Praxis: Migrationen im Portfolio

Ich habe mehrere solche Migrationen gebaut, den Export aus dem Altsystem ebenso wie den Import ins neue System. Eine Ablösung, bei der ein Dritter das neue System geliefert hat, ist darunter nicht. Die Exportseite ist aber dieselbe: Daten finden, aufbereiten, wiederholbar übertragen, prüfen.

• CMS-Migration zu TYPO3: eine mehrsprachige Website mit Tausenden Seiten. Das Dritt-CMS bot weder API noch Datenbankzugriff, deshalb erfasste ein eigener Scraper Inhalte, Hierarchie, Übersetzungen, Bilder und Dateien, und Skripte wandelten sie in TYPO3-Inhaltselemente um.
• TYPO3-Shop zu Shopware: Alle Kundendaten und Newsletter-Abonnenten zogen mit, damit Kunden ihre bestehenden Konten weiter nutzen konnten. Die Importskripte aus FileMaker lassen unvollständige Produkte weg und brechen ab, wenn ein Export fehlerhaft ist.
• Multi-Site zu TYPO3: Seitenstrukturen, Inhalte und Benutzerrechte aus einem anderen CMS in eine zentrale TYPO3-Installation übernommen.
• Akeneo-Import aus SAP: kein Umzug, aber dieselbe Logik wie beim Abgleich. Produkte, die im Export fehlen, werden deaktiviert, und fehlerhafte Datensätze bleiben unverändert, statt halbe Daten zu schreiben.

Recht und Datenschutz, kurz

Das ist keine Rechtsberatung, aber drei Punkte gehören in jeden Migrationsplan:

• Verhältnismässig und zweckgebunden: Nach Art. 6 Abs. 2 und 3 DSG muss die Bearbeitung von Personendaten verhältnismässig sein und zum Zweck passen, für den die Daten beschafft wurden. Für die Migration heisst das: nur mitnehmen, was das neue System für diesen Zweck braucht, und Testumgebungen auf die Personen beschränken, die prüfen.
• Vernichten, was nicht mehr nötig ist: Nach Art. 6 Abs. 4 DSG werden Personendaten vernichtet oder anonymisiert, sobald sie für den Zweck nicht mehr erforderlich sind. Das betrifft nach der Migration auch alte Server, Exportdateien und Backups.
• Aufbewahren, was aufbewahrt werden muss: Geschäftsbücher und Buchungsbelege sind laut Art. 958f OR zehn Jahre aufzubewahren und müssen jederzeit wieder lesbar gemacht werden können. Was davon in deinem Fall dazugehört, klärst du mit deiner Treuhand.

Ob und zu welchen Bedingungen der bisherige Anbieter Daten, Code und Unterlagen herausgeben muss, regelt dein Vertrag. Das lässt du juristisch klären.

Wer den Export baut

Export, Feld-Mapping und Abgleich gehören zur Legacy-Migration, auch wenn ein Dritter das neue System liefert. Ist noch offen, ob das Altsystem überhaupt ersetzt werden soll, hilft Modernisieren oder neu bauen bei der Entscheidung. Muss es bis zur Ablösung noch eine Weile laufen, zeigt Altsystem bis zur Ablösung, wo sich Investitionen noch lohnen. Und damit der nächste Wechsel leichter wird, gehört die Unabhängigkeit vom Anbieter schon in den Vertrag fürs neue System.