Shopsystem wechseln: Ablauf, Risiken und Zeitplan

Ein Shopsystemwechsel verbindet Aufgaben, die zum selben Termin zusammenpassen müssen: Weiterleitungen, Datenübernahme, Zahlungs- und Versandanbindungen, Kundendaten und die Texte des Shops. Der Plan unten legt jeden Schritt auf ein Zeitfenster, nennt das Ergebnis zum Abhaken und bestimmt vorher den Rückweg. Die Zeitangaben sind eine Vorlage; Ihre Dauer hängt von Kataloggröße und Zahl der Schnittstellen ab.

Was Sie vorab brauchen

• eine Liste aller URLs des heutigen Shops aus Sitemap, Serverprotokoll und Webanalyse
• eine Liste der Funktionen und Anbindungen: Zahlung, Versand, Warenwirtschaft, Buchhaltung, Newsletter (ERP im Onlinehandel, Warenwirtschaft für den Onlineshop)
• eine Feldliste Ihrer Daten: Produkte, Kundenkonten, Bestellungen, Gutscheine, Inhalte
• Zugang zu Domain, DNS-Einträgen, TLS-Zertifikat und Search Console
• einen Datenbank-Snapshot des Altsystems und eine Umgebung, um den Rückweg zu üben
• eine Abnahmeliste (Anforderungen im Lastenheft)

Der Zeitplan in T-Wochen

T-0 ist der Umschalttermin, T-8 acht Wochen davor, T+8 acht Wochen danach. Die Tabelle ist ein Vorlageplan für einen Shop mit wenigen Schnittstellen.

Phase	Zeitfenster	Ergebnis, an dem Sie abhaken
Bestandsaufnahme	T-12 bis T-10	URL-, Funktions- und Anbindungsliste
Datenumfang und Feldzuordnung	T-10 bis T-8	Feldliste mit Quelle, Zielfeld, Regel
Testsystem und Probeimport	T-8 bis T-4	Zweiter Shop mit Echtdaten, Testbestellungen je Zahlungsart
URL-Zuordnung und Weiterleitungen	T-6 bis T-2	Zuordnungstabelle alt nach neu, geprüft
Abnahmetest	T-3 bis T-1	Checkliste abgehakt, Rückweg geübt, Entscheider benannt
Go-live	T-0 im trafficärmsten Fenster	Weiterleitungen aktiv, Sitemap eingereicht
Beobachtung	T+1 Tag bis T+8 Wochen	Tagesvergleich mit dem Vorjahr, Fehlerprotokolle
Weiterleitungen halten	mindestens ein Jahr	geänderte alte URLs führen direkt auf die neuen

Die Dokumentation von Google (zuletzt aktualisiert am 9. September 2026, abgerufen am 14. Oktober 2026) empfiehlt ein trafficarmes Zeitfenster und rät ab, alle Änderungen gleichzeitig vorzunehmen.

Schritt für Schritt: Vom Beschluss zum laufenden Shop

Schritt 1: Bestand aufnehmen

Notieren Sie, was der heutige Shop leistet und wovon er abhängt: alle URLs, dazu Funktionen wie Kundenkonto, Gutscheine und Abos sowie jede Anbindung an Zahlung, Versand, Buchhaltung, Lager und Newsletter. Tragen Sie je Eintrag ein, ob er im neuen System ersetzt, übernommen oder abgeschaltet wird. Jede Zeile bekommt einen Namen; eine Zeile ohne Namen ist ein offenes Risiko.

Schritt 2: Datenumfang und Feldzuordnung festlegen

Legen Sie fest, welche Daten mitgehen: Produkte mit Varianten, Preise, Bestände, Kundenkonten, Bestellhistorie, Gutscheine und Inhalte. Füllen Sie eine Tabelle mit den Spalten Quelle, Zielfeld, Pflicht oder optional und Behandlungsregel. Was nicht übernommen wird, braucht ebenfalls eine Regel, damit es nicht unbemerkt verschwindet. Wie die Feldzuordnung aussieht und wie Sie mit Zugangsdaten umgehen, beschreibt Datenmigration beim Shopwechsel.

Schritt 3: Testsystem mit Echtdaten aufbauen

Importieren Sie einen vollständigen Datenauszug ins neue System und lassen Sie es wie im Betrieb laufen. Legen Sie Testbestellungen je Zahlungs- und Versandart an, einmal als Gast und einmal angemeldet, und prüfen Sie Belege, Bestandsänderungen und Rückmeldungen an Warenwirtschaft und Buchhaltung. Erst wenn das ohne Handgriff funktioniert, ist das System abnahmereif; ein Rundgang im Demo-Shop zeigt die Datenübernahme nicht (Proof of Concept).

Schritt 4: URL-Zuordnung und Weiterleitungen vorbereiten

Ordnen Sie jeder geänderten alten URL genau ein Ziel zu und tragen Sie die Paare in eine Tabelle ein; beim Zusammenlegen dürfen mehrere alte URLs auf dieselbe neue zeigen. Unverändert übernommene URLs brauchen keinen Eintrag. Entfällt Inhalt ohne passendes Gegenstück, geben Sie auf der neuen Seite den HTTP-Status 404 oder 410 zurück. Bleibt die Domain gleich, ändert sich nur der Pfad: Eine Musterregel je Pfadfamilie genügt nur, wenn die neue Systematik der alten folgt. Richten Sie serverseitige dauerhafte Weiterleitungen ein, mit Status 301 oder 308, und vermeiden Sie Ketten über Zwischenziele: Der Googlebot folgt bis zu zehn Sprüngen, empfohlen sind höchstens drei bis vier. Alte URLs gehören nicht gesammelt auf die Startseite; das kann Google als soft 404 werten. Aufbau der Tabelle: Shop-Relaunch und SEO.

Schritt 5: Rückweg und Snapshot festlegen

Bestimmen Sie vor dem Umschalten, was Sie zurücknehmen können und wie schnell: ein Datenbank-Snapshot des Altsystems direkt vor dem Start, ein kurzfristig änderbarer DNS-Eintrag und die Schwellen aus dem Rollback-Plan. Senken Sie die Gültigkeitsdauer (TTL) der DNS-Einträge vorher, denn die TTL bestimmt, wie lange ein Eintrag zwischengespeichert werden darf (RFC 1035, Abschnitt 3.2.1). Legen Sie namentlich fest, wer den Rückweg anordnet.

Schritt 6: Umschalten und eng beobachten

Schalten Sie im trafficärmsten Zeitfenster um, das Ihre Webanalyse zeigt. Aktivieren Sie dann die Weiterleitungen, reichen Sie die neue Sitemap ein und entfernen Sie die Test-Sperren (robots.txt, noindex). Behalten Sie in den ersten Tagen Bestelleingang, Zahlungen, Serverfehler und indexierte Seiten im Blick. Rechnen Sie mit stärkerem Crawling und mit Schwankungen in der Suche; für kleine und mittlere Websites nennt Google Wochen bis zur Migration. Wechselt die Domain, reichen Sie in der Search Console eine Adressänderung ein.

Schritt 7: Altsystem nach der Beobachtung abschalten

Lassen Sie das Altsystem erreichbar, solange die Weiterleitungen laufen, und schalten Sie es erst ab, wenn dort keine Bestellung mehr eingeht. Halten Sie die Weiterleitungen mindestens ein Jahr, wie es Google für die Übertragung der Signale empfiehlt, und aktualisieren Sie in dieser Zeit eigene Links und Werbekampagnen. Klären Sie vor der Kündigung alter Lizenzen, welche Daten Sie später noch brauchen (Gesamtkosten berechnen).

Die Go-live-Checkliste

Arbeiten Sie diese acht Punkte vor dem Umschalten ab; jeder hat einen sichtbaren Endzustand.

1. Jede geänderte alte URL antwortet mit 301 oder 308 und führt in einem Schritt auf die passende neue Seite; unveränderte URLs bleiben erreichbar, entfallene Inhalte ohne Ersatz antworten mit 404 oder 410.
2. Die Sitemap mit den neuen URLs ist eingereicht; robots.txt- und noindex-Sperren aus der Testphase sind entfernt.
3. Je Zahlungsart und je Versandart ist eine Testbestellung durchgelaufen, mit Beleg und richtiger Bestandsänderung.
4. Anmeldung, Passwort-Reset und Bestellhistorie funktionieren in einer Stichprobe, und der Umgang mit Kundenpasswörtern ist entschieden.
5. Warenkörbe, Wunschlisten, Gutscheine sowie Weiterleitungen für Bilder und PDF-Dateien sind geprüft oder bewusst verworfen.
6. Monitoring und Alarmierung für Serverfehler, Bestelleingang und Zahlungen laufen (Shop-Ausfall: Monitoring und Notfallplan).
7. Der Rückweg ist geübt: Snapshot vorhanden, DNS-Zugriff getestet, Schwellen und Entscheider schriftlich.
8. Die Rechtstexte sind eingesetzt und verlinkt; die Angaben je Land prüfen Sie mit den Länderartikeln zu Impressum, Widerruf und Preisangaben.

Der Rollback-Plan

Ein Rollback passt zu einem technischen Ausfall, nicht zu einem Rankingverlauf. Ersetzen Sie die Beispielschwellen unten durch eigene und halten Sie sie schriftlich fest.

Beobachtung	Beispielschwelle	Maßnahme
Checkout nicht bedienbar	kein Kunde kann bestellen	sofort zurück auf das Altsystem, Weiterleitungen umdrehen
Serverfehler häufen sich	mehr als 1 Prozent Antworten mit 5xx	Fehler beheben; ohne Lösung binnen 60 Minuten Rückweg
Bestellungen erreichen die Warenwirtschaft nicht	eine Bestellung bleibt ohne Rückmeldung	Anbindung prüfen, Bestellungen exportieren und nachtragen
Eine Zahlungsart fällt aus	keine erfolgreiche Zahlung binnen einer Stunde	Diese Zahlungsart abschalten, nicht zurückschalten
Sichtbarkeit in der Suche sinkt	Rückgang über mehrere Wochen	kein Rückweg; Schwankungen nennt Google normal

Der Rückweg hat einen Preis: Bestellungen, Belege und Kundendaten aus der Zeit nach dem Umschalten müssen exportiert und im Altsystem nachgetragen werden. Halten Sie es deshalb bis zum Ende der Beobachtung beschreibbar und üben Sie den Rückweg vorher.

So prüfen Sie das Ergebnis

• Vergleichen Sie vier Wochen lang Bestellungen, Umsatz und Warenkorbabbrüche mit demselben Zeitraum des Vorjahres; so fallen saisonale Effekte auf.
• Prüfen Sie 20 geänderte alte URLs von Hand: Status 301 oder 308, ein Sprung, richtiges Ziel.
• Im Indexbericht der Search Console soll die Zahl der indexierten alten URLs sinken, die der neuen steigen.
• Lesen Sie die Serverprotokolle auf neue 5xx-Fehler und auf unerwartete 404 oder 410.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Weiterleitung endet auf einer 404-Seite	Ziel-URL existiert im neuen Shop nicht	Zuordnung korrigieren und die Regel neu testen
Seiten des neuen Shops bleiben aus dem Index	Sperre aus der Testphase ist noch aktiv	robots.txt und noindex entfernen, URL im URL-Prüftool testen
Bestände weichen ab	Import ohne Bewegungen nach dem Stichtag	Bestandsänderungen seit dem Export nachbuchen
Kunden können sich nicht anmelden	Anmeldeweg ist nicht aufgesetzt	Verfahren mit dem Zielsystem klären und den Weg neu bauen
Neue Seite antwortet langsam	Crawling des Altsystems und normaler Zugriff treffen zusammen	Serverkapazität erhöhen, Hostanbieter vorab informieren (Hosting für den Onlineshop)

Wann Sie Hilfe holen sollten

• Wenn der Shop Abos, Vorbestellungen oder Gutscheine mit Salden führt oder an Warenwirtschaft und Buchhaltung hängt; jede Funktion braucht einen eigenen Test (Bestellabwicklung automatisieren).
• Wenn Kundendaten zu einem anderen Dienstleister oder in ein anderes Land wandern; das ist eine Datenschutzfrage für Ihre Rechtsberatung (Datenschutz bei der Shopsystem-Auswahl).
• Wenn Umsatzsteuer, Rechnungen oder Buchhaltung betroffen sind; das klären Sie mit Ihrer Steuerberatung.
• Wenn die Rechtstexte für mehrere Länder gelten: Impressum im Onlineshop in Deutschland, Impressum im Onlineshop in Österreich, Impressum im Onlineshop in der Schweiz und die Widerrufsartikel je Land.
• Wenn Sie zum ersten Mal migrieren und kein eigenes Team für Server, Datenbank und Weiterleitungen haben.

Alle Zeitangaben und Schwellen gehören zu einem Vorlageplan; vor dem Start ersetzen Sie sie durch Werte aus Ihrem Katalog, Ihrer Webanalyse und Ihren Verträgen.