Shopware umziehen — mit Bestellungen im Betrieb.

Bestandsaufnahme.

1. Shopware-Version und PHP-Version am Ausgangsort.
2. Verfügbare PHP-Fassungen am Ziel.
3. Pluginliste mit Versionen und Lizenzen.
4. Zusätzliche Dienste: Zwischenspeicher, Suche.
5. Zeitgesteuerte Aufgaben und Warteschlangen-Vorgang.
6. Verkaufskanäle und ihre Domains.
7. Schnittstellen zu Warenwirtschaft, Buchhaltung, Versand.
8. Kommandozeilenzugriff am Ziel — bei Shopware Voraussetzung.
9. Größe: Datenbank, Medien, Bestellvolumen.

Punkt drei ist shopware-typisch: Kostenpflichtige Plugins sind an den Shop gebunden. Ein Umzug kann bedeuten, dass Lizenzen auf die neue Umgebung umgezogen werden müssen — das klärt man vorher mit dem Hersteller, nicht am Umschalttag (Lizenzen).

Punkt sieben gehört ebenfalls vorher geklärt: Eine angebundene Warenwirtschaft muss wissen, wo der Shop künftig liegt, und Zugangsdaten müssen angepasst werden.

Ziel vorbereiten.

PHP-Fassung einstellen, benötigte Erweiterungen prüfen, Datenbank anlegen, Grenzen für Arbeitsspeicher und Laufzeit großzügig setzen. Shopware braucht beim Bauen der Oberfläche deutlich mehr als im Betrieb.

Wenn am Ausgangsort ein Zwischenspeicher- oder Suchdienst genutzt wird, muss er am Ziel ebenfalls verfügbar sein — oder die Konfiguration entsprechend angepasst werden. Sonst sucht Shopware einen Dienst, den es nicht gibt (Serverausstattung).

Shopware bringt eine Systemprüfung mit, die Anforderungen gegen die Umgebung hält. Die vor dem Umzug am Ziel laufen zu lassen, spart Überraschungen.

Dateien übertragen.

Das gesamte Projektverzeichnis wandert mit, einschließlich der Teile außerhalb des öffentlichen Bereichs. Bei einer Installation über die Abhängigkeitsverwaltung liegt das Webverzeichnis in einem Unterordner, und darüber liegen weitere Dateien.

Diese Struktur muss am Ziel abgebildet werden. Wenn der Hoster ein festes öffentliches Verzeichnis vorgibt, muss das passen — sonst liegt die Umgebungsdatei mit den Zugangsdaten im Netz.

Nicht mitkopieren: Cache-Verzeichnis, Protokolle, erzeugte Theme-Dateien. Die Abhängigkeitsverzeichnisse lassen sich ebenfalls auslassen, wenn am Ziel Kommandozeilenzugriff besteht — sie machen einen erheblichen Teil der Dateien aus und werden dort neu aufgebaut.

Mitkopieren musst du dagegen das Medienverzeichnis mit allen Produktbildern. Bei großen Sortimenten ist das der zeitaufwendigste Teil — plan das ein und übertrag es vorab, nicht am Umschalttag.

Datenbank übertragen.

1. Export über die Kommandozeile, bei Shop-Datenbanken meist die einzig praktikable Wahl.
2. Vorher Cache-Tabellen leeren — das verkleinert den Export deutlich.
3. Zeichensatz beachten.
4. Am Ziel einspielen.
5. Tabellenzahl vergleichen.
6. Stichprobe: Artikel, Bestellungen, Umlaute.

Punkt zwei lohnt bei Shops besonders: Cache- und Protokolltabellen machen oft einen erheblichen Teil des Volumens aus. Ein Export ohne sie ist deutlich schneller übertragen und eingespielt.

Während der eigentlichen Übertragung sollte nicht bestellt werden — sonst fehlen Bestellungen am Ziel. Dazu unten mehr.

Die Umgebungsdatei.

Hier stehen die umgebungsabhängigen Angaben. Anzupassen sind:

Die letzte Zeile ist wichtig: Aus diesem Schlüssel werden Prüfwerte abgeleitet. Wird am Ziel eine frische Installation aufgesetzt und deren Datei weiterverwendet, passt der Schlüssel nicht zu den vorhandenen Daten — und es treten schwer zuzuordnende Fehler auf. Aus der alten Datei übernehmen.

Sicherheitshinweis: Diese Datei enthält Zugangsdaten im Klartext. Prüf nach dem Umzug, ob der Server sie ausliefert — ruf den Pfad einmal im Browser auf. Kommt der Inhalt, ist die Verzeichnisstruktur falsch.

Die Verkaufskanal-Domain.

Der Punkt, den kaum jemand auf dem Schirm hat und der nach einem Umzug für Ratlosigkeit sorgt: Shopware speichert die Domain je Verkaufskanal in der Datenbank.

Das heißt: Eine Änderung in der Umgebungsdatei allein reicht nicht. Wer den Shop unter einer Testadresse aufrufen will, muss die Domain des Verkaufskanals entsprechend ergänzen — sonst leitet Shopware auf die alte Adresse um oder meldet, dass kein Verkaufskanal gefunden wurde.

Praktisch: Für den Testbetrieb die Testadresse als zusätzliche Domain am Verkaufskanal eintragen, und am Umschalttag wieder entfernen. Bei mehreren Verkaufskanälen je Kanal.

Wenn das Backend nicht erreichbar ist, geht die Anpassung über die Datenbank in der Tabelle der Verkaufskanal-Domains — vorher sichern (Weiße Seite).

Cache und Builds.

Der alte Cache enthält Pfade des alten Servers und führt zuverlässig zu Fehlern. Nicht übertragen, und falls doch geschehen, am Ziel leeren.

Wichtiger noch: Theme und Verwaltungsoberfläche müssen am Ziel neu gebaut werden. Die erzeugten Dateien sind umgebungsabhängig, und ein Umzug ohne diesen Schritt endet in einem Shop ohne Gestaltung.

Die Reihenfolge am Ziel: Abhängigkeiten auflösen, Cache leeren, Datenbankmigrationen prüfen, Theme bauen, Verwaltung bauen, Cache aufwärmen (Cache und Build).

Dateirechte.

Shopware braucht Schreibrechte im Medienverzeichnis, im Cache-Verzeichnis, im Protokollverzeichnis und für die erzeugten Theme-Dateien.

Typisches Bild nach einem Umzug: Dateien gehören dem übertragenden Benutzer, nicht dem Webserver. Dann kann Shopware nicht schreiben — Bilder werden nicht erzeugt, der Cache nicht gefüllt, das Theme nicht gebaut.

Setz keine pauschal weit offenen Rechte. Bei einem Shop mit Zahlungsdaten ist das ein ernstes Risiko und löst die Ursache nicht.

Warteschlange und Aufgaben.

Ein Shopware-spezifischer Punkt, der regelmäßig vergessen wird und erst Tage später auffällt.

Shopware braucht zwei laufende Vorgänge: einen für die zeitgesteuerten Aufgaben und einen, der die Nachrichtenwarteschlange abarbeitet. Beide laufen über Cronjobs auf dem Server — und die wandern beim Umzug nicht mit.

Ohne sie passiert zunächst nichts Sichtbares. Dann kommen keine Bestellbestätigungen mehr, die Suche findet neue Produkte nicht, Bilder werden nicht erzeugt und Indizes veralten. Das wirkt wie ein Shop-Fehler und ist ein fehlender Cronjob.

Richte beide am Ziel ein, bevor umgeschaltet wird, und prüf nach einer Stunde, ob die Warteschlange abgearbeitet wird (Wartung).

Unter Testadresse prüfen.

1. Testadresse am Verkaufskanal eintragen.
2. Startseite, Kategorie, Produktseite aufrufen.
3. Bilder werden angezeigt und neu erzeugt?
4. Suche und Filter ausprobieren.
5. Testkauf mit jeder Zahlungsart, Zahlungsarten auf Testbetrieb.
6. Bestätigungsmail prüfen.
7. Backend: Anmeldung, Bestellungen, Produkte bearbeiten.
8. Warteschlange läuft?
9. Protokoll ansehen.

Punkt fünf mit Nachdruck: Zahlungsarten in der Testumgebung auf Testbetrieb stellen, bevor jemand einen Testkauf macht. Sonst entstehen echte Buchungen — das ist schon vorgekommen.

Testfassung vor Suchmaschinen sperren und die Sperre nach dem Umschalten entfernen (robots.txt).

Der Umschalttag.

Hier unterscheidet sich ein Shop von einer Website. Es laufen Bestellungen, es gibt offene Warenkörbe, und Zahlungen sind beim Anbieter unterwegs.

1. Zeitpunkt wählen nach den eigenen Zahlen — wann wird am wenigsten bestellt?
2. Medien vorab übertragen, damit am Tag nur noch die Differenz läuft.
3. Verkauf stoppen: Wartungsmodus mit verständlichem Hinweis.
4. Kurz warten, damit unterwegs befindliche Zahlungen zurückmelden können.
5. Letzte Datenbankübertragung mit dem aktuellen Stand.
6. Am Ziel: Cache, Builds, Migrationen prüfen.
7. Verkaufskanal-Domain auf die echte Adresse stellen.
8. Umschalten über die Namenseinträge.
9. Prüfen, dann Wartungsmodus beenden.

Punkt vier wird gern übersprungen und ist wichtig: Eine Zahlung, die beim Anbieter angestoßen wurde und deren Rückmeldung während der Umschaltung eintrifft, kann verlorengehen. Eine Viertelstunde Puffer löst das.

Senk die Gültigkeitsdauer der Namenseinträge einige Tage vorher, damit die Umschaltung schnell greift (DNS).

Danach prüfen.

• Testkauf auf der echten Adresse, mit jeder Zahlungsart.
• Zahlungsanbieter: Kommen Rückmeldungen an? Oft sind Adressen beim Anbieter hinterlegt.
• Schnittstellen: Kommt die Bestellung in der Warenwirtschaft an?
• Warteschlange läuft und ist nicht gestaut?
• Zeitgesteuerte Aufgaben laufen?
• Suchmaschinensperre entfernt?
• Zertifikat gültig und Verlängerung aktiv (SSL).
• Protokoll die ersten Tage beobachten.
• Erst nach zwei Wochen kündigen.

Punkt zwei ist shopspezifisch und wichtig: Zahlungsanbieter hinterlegen oft Rückmeldeadressen in ihrem System. Ändert sich die Adresse des Shops oder die Serveradresse, müssen diese Angaben angepasst werden — sonst wird die Zahlung ausgelöst, aber die Bestellung nie bestätigt (Zahlungsprobleme).

Häufige Fehler.

• Verkaufskanal-Domain nicht angepasst.
• Anwendungsschlüssel nicht übernommen.
• Theme und Verwaltung nicht gebaut.
• Cronjobs für Aufgaben und Warteschlange vergessen.
• Zwischenspeicher- oder Suchdienst eingetragen, den es am Ziel nicht gibt.
• Medienverzeichnis unvollständig übertragen.
• Rückmeldeadressen beim Zahlungsanbieter nicht angepasst.
• Dateirechte falsch.
• Umgebungsdatei wird vom Server ausgeliefert.
• Zu früh gekündigt.

Die ersten vier erklären zusammen die Mehrzahl aller Probleme nach einem Shopware-Umzug. Punkt sieben ist der teuerste, weil er stillschweigend Umsatz kostet: Der Shop läuft, Kunden bezahlen, und die Bestellungen kommen nie an.

Wenn du nicht weiterkommst.

Wenn ein Umzug ansteht und dabei keine Bestellung verlorengehen darf. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn gerade keine Bestellungen durchgehen, hilft der Notfall-Support, dauerhaft begleitet die Shopware-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management- und Shopsysteme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme von innen: Datenmodell, Rechtekonzept, Templating, Plugin-Architektur, Caching, Betrieb.

Bei Shopware 6 zahlt sich das besonders aus, weil es auf demselben professionellen Unterbau aufsetzt wie andere ausgewachsene Systeme: Abhängigkeitsverwaltung, Dienste-Container, eine getrennte Verwaltungsoberfläche und eine Schnittstelle für alles. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo ein Shop gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob dein Shop weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.