Datenmigration beim Website Relaunch: So gehen keine Daten verloren

Die Datenmigration beim Website Relaunch überträgt Kundenkonten, Bestellungen, Formulareinträge, Postfächer und die Analytics Historie vollständig vom alten auf das neue System. In diesem Leitfaden geht es nicht um Design oder Seiteninhalte. Stattdessen behandle ich die unsichtbare Ebene: Datenbank, Backup, Testmigration und Prüfung. Seit 2012 sehe ich die teuersten Relaunch Fehler genau hier.

Was bedeutet Datenmigration beim Website Relaunch?

Datenmigration ist der Prozess, bei dem Sie Datensätze aus der alten Datenbank und den angebundenen Diensten exportieren, der Struktur des neuen Systems zuordnen, importieren und anschließend prüfen. Dazu gehören Benutzerkonten, Passwort Hashes, Bestellungen, Formulareinträge, E-Mail und Analytics Daten. Das Ziel lautet: kein einziger Datensatz geht verloren.

Dabei ziehe ich eine klare Grenze. Seitentexte, Bilder und URLs umzuziehen ist Content Migration; die SEO Seite beschreibe ich im Beitrag SEO beim Website Relaunch schützen. Hier geht es dagegen um das Gedächtnis des Unternehmens. Also darum, wer was gekauft hat, wer welches Formular ausgefüllt hat und welcher Kunde sich mit welchem Passwort anmeldet.

Kurz gesagt: Das Design dürfen Sie erneuern. Die Geschichte des Unternehmens dagegen muss unverändert ins neue Haus umziehen.

Warum gehen beim Relaunch Daten verloren?

Daten verschwinden selten aus böser Absicht. Meist fehlt schlicht ein Plan. Das häufigste Szenario sieht so aus: Das Team baut die neue Website wochenlang auf einem Staging Server. Währenddessen nimmt die alte Seite weiter Bestellungen und Anfragen an. Importieren Sie am Starttag nur die erste Kopie, fallen alle Datensätze aus diesen Wochen ins Leere.

Außerdem hat jede Plattform ihr eigenes Datenmodell. Zum Beispiel speichert das alte System den vollständigen Namen in einem Feld, während das neue Vor und Nachname getrennt erwartet. Ohne saubere Zuordnung bleiben Namen dann abgeschnitten oder leer. Zudem sorgen Zeichensätze für Ärger, denn Umlaute verwandeln sich plötzlich in Fragezeichen.

• Neue Datensätze zwischen Staging Kopie und Starttag.
• Fehler bei der Feldzuordnung und abgeschnittene Texte.
• Falsche Zeichensätze, etwa latin1 gemischt mit utf8mb4.
• Ein zu früh gekündigtes Hosting.
• Daten in externen Tools, für die niemand zuständig ist.

Deshalb ist Datenverlust meist kein technischer Unfall, sondern die Folge fehlender Planung.

Dazu kommt die Frage der Zuständigkeit. Der Designer glaubt, der Entwickler übernimmt die Datenmigration. Der Entwickler wiederum nimmt an, der Kunde habe längst ein eigenes Backup. Vertraut jeder auf den anderen, macht am Ende niemand die letzte Kontrolle. Daher lege ich schon im ersten Termin fest, wer die Datenmigration verantwortet, und zwar mit Namen. Somit gibt es für jede offene Frage eine klare Ansprechperson.

Welche Daten müssen Sie migrieren, und wie erstellen Sie das Inventar?

Zunächst brauchen Sie eine Liste aller Datenarten, die die Website speichert. Gemeint ist dabei keine Seitenliste. Konkret geht es um Datenbanktabellen und externe Dienste. Ich sammle beides in einer Tabelle und weise jeder Zeile eine verantwortliche Person zu.

Somit landet keine Datenart in der Kategorie "Ich dachte, das macht jemand anders". Zusätzlich empfehle ich eine Spalte, die festhält, ob das neue System ein passendes Feld besitzt.

Wie sichern Sie Ihre Daten vor der Datenmigration?

Das Backup ist die Versicherung jeder Datenmigration, deshalb erstellen und testen Sie es, bevor irgendetwas umzieht. Vor allem vertraue ich nie einem einzelnen Backup. Stattdessen erstelle ich einen vollständigen Datenbankdump, ein Archiv des Dateisystems und eine Kopie aller Postfächer.

1. Exportieren Sie die komplette Datenbank, also Struktur und Inhalt.
2. Archivieren Sie das Dateisystem, vor allem den Upload Ordner.
3. Laden Sie das Backup herunter; eine Kopie auf demselben Server hilft beim Serverausfall nicht.
4. Prüfen Sie die Integrität der Datei mit einer Prüfsumme.
5. Spielen Sie das Backup testweise in eine leere Umgebung ein.

In der Praxis überspringen die meisten Teams den letzten Schritt. Allerdings ist ein Backup, das Sie nie zurückgespielt haben, eher eine Hoffnung als eine Sicherung. Zudem sollten Sie den Dump nach dem Projekt nicht auf dem Server liegen lassen. Ein vergessener Datenbankexport in einem öffentlichen Ordner ist ein ernstes Datenleck.

Wie migrieren Sie Benutzerkonten und Passwörter?

Bei Benutzerkonten sind zunächst Passwörter der schwierigste Teil. Ein sauberes System speichert Passwörter nie im Klartext, sondern nur als Hash. Daher können Sie ein Passwort nicht einfach auslesen und ins neue System schreiben. Sie übertragen den Hash, und das neue System muss ihn prüfen können.

Ein Plattformwechsel macht genau das schwierig. Laut Ankündigung des WordPress Core Teams wechselte WordPress mit Version 6.8 von phpass zu einem Verfahren auf Basis von bcrypt. Das heißt, sogar zwischen zwei Versionen derselben Plattform kann sich das Hash Format ändern. Wechseln Sie die Plattform, brauchen Sie also eine Kompatibilitätsschicht, die alte Hashes erkennt.

Klappt das nicht, bleibt als Ausweg ein Passwort Reset beim ersten Login. Kündigen Sie ihn dann aber vorab per E-Mail klar an. Sonst läuft Ihr Support in der Startwoche über.

Wie bleibt die Bestell und Rechnungshistorie vollständig?

Bestelldaten bestehen nie aus nur einer Tabelle. Bestellkopf, Positionen, Zahlung, Versand und Kundendatensatz hängen über IDs zusammen. Reißen diese Verbindungen, sieht die Bestellliste zwar voll aus. Trotzdem gehört dann keine Bestellung mehr zum richtigen Kunden.

Deshalb lautet meine erste Regel: Behalten Sie die alten IDs, wo immer es geht. Falls das nicht möglich ist, führen Sie eine Zuordnungstabelle zwischen alten und neuen IDs und löschen Sie sie nach dem Start nicht. Braucht die Buchhaltung Monate später einen alten Datensatz, rettet diese Tabelle den Tag.

Achten Sie außerdem auf die Bestellnummern. Beginnt das neue System wieder bei 1, tragen alte und neue Bestellungen dieselben Nummern. Lassen Sie die neue Serie daher oberhalb der höchsten alten Nummer starten. Bei Onlineshops plane ich diese Einstellungen von Anfang an im Rahmen der E-Commerce Beratung.

Wie schützen Sie Formulareinträge und Leads?

Formulareinträge sind auf vielen Websites die am stärksten vernachlässigten Daten. Kontakt, Angebots und Terminformulare speichern Einträge oft in der Tabelle eines Plugins. Fehlt dieses Plugin auf der neuen Seite, bleibt die Tabelle zurück, und jahrelange Anfragen verschwinden still.

Meine Methode: Zunächst exportiere ich alle alten Einträge als CSV. Danach importiere ich sie ins CRM oder in die Formulartabelle des neuen Systems. So hängen die Einträge nicht mehr an einer einzigen Plattform. Zudem gleiche ich die Feldnamen ab, denn kleine Unterschiede wie "telefon" und "tel" erzeugen beim Import leere Spalten.

Auch der Starttag birgt ein Risiko. Läuft das alte Formular noch, während das neue live geht, landen Anfragen eine Weile an zwei Orten. Schalten Sie daher das alte Formular beim Start ab und prüfen Sie spätere Einträge gesondert. Für das neue Formular lohnt sich ein Blick auf meinen Beitrag zu Termin, Angebots und Demo Formularen.

Worauf achten Sie beim Umzug der E-Mail Konten?

E-Mail ist der heimtückischste Verlust beim Relaunch. In vielen kleinen Unternehmen liegt die Firmen E-Mail auf demselben Hosting wie die Website. Zieht die neue Seite auf einen anderen Server um und kündigen Sie das alte Hosting, verschwinden jahrelange Korrespondenzen gleich mit.

• Klären Sie zuerst, wo die E-Mail liegt: beim Hosting oder bei einem eigenen Anbieter.
• Kopieren Sie die Postfächer per IMAP auf den neuen Server, und zwar inklusive Historie.
• Notieren Sie die aktuellen MX, SPF, DKIM und DMARC Einträge, bevor Sie DNS ändern.
• Prüfen Sie das alte Postfach nach der DNS Umstellung noch einige Tage.

Die aktuellen Einträge sehen Sie schnell mit der DNS Abfrage. Außerdem nimmt die Trennung von E-Mail und Website dieses Risiko beim nächsten Relaunch komplett weg; mehr dazu im Beitrag E-Mail mit eigener Domain.

Wie übernehmen Sie die Analytics Historie?

Streng genommen migrieren Sie Analytics Daten gar nicht. Richten Sie alles korrekt ein, bleiben sie einfach, wo sie sind. Die Regel lautet: Legen Sie für die neue Seite keine neue GA4 Property an. Behalten Sie stattdessen die bestehende Property und die Mess ID. Dann stehen Vorher und Nachher im selben Bericht nebeneinander.

Beachten Sie allerdings die Aufbewahrungsdauer. Laut Google Analytics Hilfe speichern Standard Properties Daten auf Ereignisebene standardmäßig 2 Monate, und Sie können die Dauer auf maximal 14 Monate verlängern. Diese Einstellung wirkt sich auf explorative Analysen aus. Wollen Sie langfristig vergleichen, aktivieren Sie daher vor dem Relaunch den BigQuery Export von GA4.

Denken Sie zudem an die Conversion Ereignisse. Ändern sich die Namen der Formular oder Kaufereignisse, erhalten die Conversion Ziele im Werbekonto keine Daten mehr. Behalten Sie die Ereignisnamen deshalb exakt bei.

Was passiert mit Search Console und Werbekonten?

Daten in der Search Console hängen an der Domain. Bleibt die Domain gleich, bleiben auch die bisherigen Leistungsdaten erhalten. Ändert sich die Domain, bestätigen Sie alte und neue Property und nutzen das Tool zur Adressänderung. Wie das funktioniert, erkläre ich in der Search Console Anleitung.

Bei Anzeigen liegt das eigentliche Risiko in fehlenden Conversion Tags. Fehlt das Tag, sieht das Werbekonto tagelang null Conversions. Die automatische Gebotsstrategie liest diese Lücke dann als "Anzeigen wirken nicht" und senkt die Gebote. Deshalb teste ich die Tags vor dem Start auf dem Staging Server mit dem Tag Assistant.

Andererseits hängen auch Remarketing Listen an Cookies. Bleibt das Tag gleich, wachsen die Listen ohne Unterbrechung weiter. Ändern Sie es, füllen sie sich von null.

Wie ordnen Sie Felder zu, wenn die Datenbankstruktur abweicht?

Eine Feldzuordnung zeigt, wohin jede alte Spalte im neuen System wandert. Ich erstelle sie in einer Tabelle, bevor jemand Code schreibt. Links steht das alte Feld, in der Mitte das neue und rechts die Umwandlungsregel.

Speichert das alte System Telefonnummern zum Beispiel ohne Ländervorwahl und verlangt das neue sie, legen Sie diese Regel vorab fest. Dasselbe gilt für Datumsformate, Währungen und Statuscodes. Bedeutete die "3" im alten System "versendet", definieren Sie die neue Entsprechung ausdrücklich.

Manche Felder haben im neuen System keinen Platz. Statt sie zu verwerfen, bewahre ich sie in einem Notizfeld oder einer eigenen Archivtabelle auf. Denn ein heute nutzlos wirkendes Feld kann sechs Monate später der einzige Beleg in einem Kundenstreit sein.

Zusammengefasst ist die Feldzuordnung zugleich Fahrplan für die Entwicklung und Nachschlagewerk für spätere Fragen.

Wie vermeiden Sie Probleme mit Zeichensätzen und Formaten?

Falsche Zeichensätze sind die häufigste Datenbeschädigung, die ich auf deutschsprachigen Seiten sehe. Aus "Müller" wird dann "Müller". Das passiert meist, wenn Export und Import unterschiedliche Zeichensätze nutzen.

Deshalb gebe ich beim Export den Zeichensatz ausdrücklich an und lege die neue Datenbank mit utf8mb4 an. utf8mb4 speichert den gesamten Unicode Bereich samt Emojis, während die ältere utf8 Einstellung in MySQL manche Zeichen abschneidet. Nach dem Import öffne ich dann einige Datensätze mit Umlauten und ß von Hand.

Formatprobleme betreffen aber nicht nur Buchstaben. Auch das Dezimaltrennzeichen ist eine klassische Falle: Im deutschen Raum nutzen Sie ein Komma, viele Programme erwarten dagegen einen Punkt. Liest das System ein Preisfeld falsch, erscheint eine Bestellung über 1.250,00 Euro womöglich als 1,25 Euro. Prüfen Sie Betragsfelder also immer mit einer Summenkontrolle.

Was geschieht mit Daten in externen Diensten?

Eine moderne Website besteht nicht nur aus ihrer eigenen Datenbank. Die Newsletterliste liegt beim E-Mail Anbieter, der Chatverlauf im Supporttool, Bewertungen auf einer Bewertungsplattform und Zahlungsdaten beim Zahlungsanbieter. Ein Relaunch kann diese Verbindungen kappen.

• Newsletter: Exportieren Sie die Abonnenten samt Einwilligungsnachweisen.
• Zahlungen: Aktualisieren Sie Callback und Webhook Adressen für die neue Seite.
• Livechat und Support: Exportieren Sie frühere Unterhaltungen.
• Versand und Buchhaltung: Hinterlegen Sie API Schlüssel und Endpunkte neu.

Prüfen Sie außerdem, auf wessen Namen diese Konten laufen. Ein Konto, das an eine frühere Agentur oder einen ausgeschiedenen Mitarbeiter gebunden ist, wird mitten im Projekt zum Zugriffsproblem. Daher empfehle ich, alle Konten auf eine Adresse des Unternehmens umzustellen.

Warum sollten Sie mindestens eine Testmigration durchführen?

Eine Testmigration überträgt eine Kopie echter Daten als Generalprobe ins neue System. Ich plane in jedem Projekt mindestens eine, meist zwei. Die erste findet Fehler, die zweite zeigt, dass die Korrekturen wirklich greifen.

Dabei achte ich vor allem auf verknüpfte Datensätze. Hängen Bestellungen, Adressen und Bewertungen eines Kunden noch am selben Kunden? Können Sie das nicht mit Ja beantworten, starten Sie die echte Datenmigration noch nicht.

Die Probe hat einen weiteren Vorteil: Sie messen die Dauer. Eine große Datenbank braucht für den Umzug unter Umständen Stunden. Ohne diese Zahl wissen Sie nicht, wie lange die Seite in der Startnacht offline bleibt.

Zudem muss die Staging Umgebung für die Öffentlichkeit gesperrt sein. Ist eine Testseite mit echten Kundendaten für Suchmaschinen erreichbar, drohen doppelte Inhalte und ein Datenleck. Schützen Sie sie mit einem Passwort; der Passwort Generator hilft dabei. Wo möglich, maskieren Sie personenbezogene Felder in der Testkopie.

Wie prüfen Sie die Datenmigration nach dem Import?

Ich prüfe mit Zahlen, nicht mit dem Auge. Vor dem Umzug zähle ich die Datensätze jeder Tabelle im alten System. Danach wiederhole ich die Zählung im neuen. Stimmen die Zahlen nicht überein, wartet der Start, bis ich die Lücke gefunden habe.

1. Anzahl: Kunden, Bestellungen, Formulare und Bewertungen, Tabelle für Tabelle.
2. Summen: Stimmt die Gesamtsumme aller Bestellungen in beiden Systemen überein?
3. Stichproben: Öffnen Sie die Historie von 20 zufälligen Kunden von Hand.
4. Grenzfälle: ältester Datensatz, neuester Datensatz, Namen mit Umlauten.
5. Funktionstest: Melden Sie sich mit einem migrierten Konto an und öffnen Sie eine alte Bestellung.

Anders gesagt: Dass die Seite lädt, ist noch keine Prüfung. Die Datenmigration ist erst fertig, wenn die Zahlen auf beiden Seiten übereinstimmen. Eine schriftliche Checkliste liefert dem Auftraggeber zudem ein transparentes Übergabeprotokoll.

Wie planen Sie die Datenmigration am Starttag?

Im Zentrum des Startplans steht die Deltamigration. Nach der Testkopie erzeugt die alte Seite weiter Datensätze, und diese müssen Sie beim Start nachziehen. Am saubersten gelingt das mit einem kurzen Wartungsfenster.

• Wählen Sie die Stunde mit dem geringsten Traffic; Ihre Analytics Daten zeigen sie.
• Stoppen Sie Bestellungen und Formulare auf der alten Seite.
• Übertragen Sie das Delta und wiederholen Sie die Zählung.
• Stellen Sie erst dann DNS oder das Serverrouting um.
• Lassen Sie das alte System eine Weile im reinen Lesemodus online.

Senken Sie den TTL Wert der DNS Einträge einen Tag vorher, damit sich die Änderung schneller verbreitet. Danach kontrollieren Sie die Weiterleitungen mit dem Redirect Checker. Die komplette URL Seite finden Sie in meiner Checkliste zur Website Migration.

Wie sieht Ihr Rückfallplan aus, wenn etwas schiefgeht?

Ein Rückfallplan beschreibt schriftlich, wie Sie bei einem ernsten Datenproblem nach dem Start zum alten System zurückkehren. Ich schreibe ihn vor dem Starttag, denn in der Panik fällt eine gute Entscheidung schwer.

Der Plan muss drei Fragen klar beantworten. Erstens: Was löst die Rückkehr aus, etwa ausfallende Zahlungen oder viele Kunden ohne Login? Zweitens: Wer gibt die Rückkehr frei? Schließlich: Wie retten Sie die Datensätze, die die neue Seite inzwischen erzeugt hat?

Die letzte Frage vergessen allerdings viele Teams. Lief die neue Seite einige Stunden, liegen die Bestellungen aus dieser Zeit in der neuen Datenbank. Folglich muss auch die Rückkehr diese Daten zurückholen. Ein weiterer Grund, das alte System nicht sofort zu löschen.

So arbeiten Sie in der Startnacht eine Liste ab, statt zu diskutieren.

Wann dürfen Sie das alte System abschalten?

Das alte System direkt nach dem Start abzuschalten, gehört zu den teuersten Gewohnheiten, die ich kenne. Eine übersehene Tabelle fällt meist erst Wochen später auf. Dann fragt ein Kunde nach einer alten Rechnung, oder ein Kollege sucht einen alten Mailverlauf.

Daher empfehle ich, das alte System mindestens einige Wochen im reinen Lesemodus zu behalten. Das ist ein Richtwert aus der Praxis, keine Garantie. Legen Sie das Vertragsende beim Hosting entsprechend fest. Vor dem Abschalten ziehen Sie ein letztes Vollbackup und speichern es im Firmenarchiv.

Denken Sie danach auch an personenbezogene Daten auf dem alten Server. Lassen Sie sich vom Hoster bestätigen, dass Konto und Backups gelöscht sind. Sonst liegen Kundendaten weiter auf einem Server, den Sie gar nicht mehr nutzen.

Was bedeutet die DSGVO für die Datenmigration?

Der Umzug personenbezogener Daten ist auch rechtlich ein Vorgang. Greift ein neuer Hoster, ein Softwarehaus oder eine Agentur auf Ihre Daten zu, halten Sie die Bedingungen der Auftragsverarbeitung schriftlich fest. Die rechtliche Bewertung überlassen Sie bitte einer Fachperson; ich teile hier nur die technischen Punkte, auf die ich achte.

• Nutzen Sie auf Staging keine echten Personendaten, oder maskieren Sie sie.
• Versenden Sie Datenbankdumps nie als Anhang oder über offene Freigabelinks.
• Klären Sie den Serverstandort und passen Sie bei Bedarf Ihre Datenschutzerklärung an.
• Löschen Sie alte, nicht mehr benötigte Datensätze nach Ihrem Löschkonzept, statt sie mitzunehmen.

Auch Zugriffsrechte zählen. Entfernen Sie nach der Datenmigration temporäre Datenbanknutzer, FTP Konten und Freigabelinks. Entziehen Sie zudem externen Teams den Zugang. So bleiben die Türen, die Sie für den Umzug geöffnet haben, danach nicht offen.

Somit ist ein Relaunch auch eine gute Gelegenheit zum Aufräumen. Wer Testkonten und Spam Einträge zurücklässt, startet mit einem schlankeren System.

Sollten Sie die Datenmigration selbst übernehmen?

Das hängt von Datenmenge und Plattformwechsel ab. Wechseln Sie nur das Theme auf derselben Plattform, bleibt die Datenbank, wo sie ist, und das Risiko ist gering. Wechselt dagegen die Plattform, etwa von einem Standardsystem zu individueller Software, brauchen Feldzuordnung und Passwort Kompatibilität Erfahrung.

Mein Rat: Egal wer das Design macht, geben Sie der Datenmigration eine namentlich verantwortliche Person, die das Prüfprotokoll unterschreibt. Schwebt die Verantwortung zwischen Designer und Entwickler, gehen die Daten genau dort verloren.

Machen Sie es selbst, dann überspringen Sie zumindest Backup, Testlauf und Zählung nicht. Diese drei Schritte hätten die meisten Verluste verhindert, die ich gesehen habe. In Relaunch Projekten behandle ich die Datenseite als festen Bestandteil meines Webdesigns.

Was beobachten Sie in den ersten 30 Tagen?

Im ersten Monat nach dem Start zeigen sich versteckte Datenprobleme. In dieser Zeit verfolge ich regelmäßig einige Signale.

• Supportanfragen mit dem Satz "Ich kann mich nicht anmelden".
• Formulareingänge im Vergleich zum Durchschnitt vor dem Start.
• Den täglichen Fluss der Conversion Ereignisse in GA4.
• Crawling und Indexierungsfehler in der Search Console.
• Leere oder beschädigte Felder in Bestellungen und Rechnungen.

Ein plötzlicher Einbruch bei Formularen deutet meist auf ein Daten oder Tag Problem hin, nicht auf das Design. Wie Sie solche Signale lesen, zeigt mein Beitrag Marketing Report richtig lesen. Folglich endet die Datenmigration nicht am Starttag, sondern erst, wenn sich die Zahlen am Monatsende eingependelt haben.

Für den größeren Rahmen ist der Leitfaden von Google Search Central zum Websiteumzug ein guter Einstieg. Hängen Sie bei der Datenseite fest, schreiben Sie mir.