Shopware 6 Domain-Umzug: Shop auf neuen Webspace umziehen

von Der Atilla | Aug. 6, 2026 | Alle | 0 Kommentare

Ein Shopware-6-Domain-Umzug klingt nach einem reinen Datei- und Datenbank-Thema — ist es aber nur zur Hälfte. Wer beim Wechsel auf einen neuen Webspace nur Dateien kopiert und die Datenbank importiert, landet fast immer bei einem 500er oder der Meldung „Unable to find a matching sales channel for the request“. Der eigentliche Kern beim Shopware 6 Domain umziehen sind drei Stellschrauben, die zusammenspielen müssen: die APP_URL in der Konfigurationsdatei, der Domain-Eintrag im Verkaufskanal und der Lizenz-Host im Shopware-Account. In diesem Artikel gehen wir Schritt für Schritt durch, was beim Umzug auf einen neuen Server oder eine neue Domain wirklich passiert, was Shopware-Bordmittel dafür hergeben, welche Store-Plugins in dem Kontext sinnvoll sind und welche Fehlerbilder in der Praxis am häufigsten gemeldet werden.

Shopware 6 Domain umziehen: Was technisch wirklich passiert
Shopware 6 Domain umziehen: Lösung A – mit Bordmitteln
Shopware 6 Domain umziehen: Lösung B – Store-Plugins
Shopware 6 Domain umziehen: Praxis-Fehlerbilder aus der Community
Shopware 6 Domain umziehen: Schritt-für-Schritt-Ablauf
Shopware 6 Domain umziehen: Muss das Theme mit umziehen?

1. Was beim Domain-Umzug technisch wirklich passiert

Der Reflex bei „Shop auf neuen Webspace umziehen“ ist meistens: Dateien per FTP/SSH rüberkopieren, Datenbank exportieren und importieren, fertig. Technisch korrekt ist das auch – nur reicht es für Shopware 6 nicht. Nach unserer Recherche in Doku, Quellcode und Community-Threads sind es konkret drei Bausteine, die beim Domain- bzw. Webspace-Wechsel zusammenspielen:

APP_URL in .env.local (Format APP_URL="https://ihre-domain.de") – muss die extern erreichbare Domain enthalten. Seit Shopware 6.5.0.0 gehört dieser Wert in .env.local, nicht mehr in die .env selbst.
Sales-Channel-Domain in der Datenbanktabelle sales_channel_domain, Feld url – wird im Admin unter Verkaufskanäle → Domains gepflegt.
Lizenz-Host unter Einstellungen → System → Shopware-Account – muss auf die neue Hauptdomain umgestellt werden, danach jeder Verkaufskanal einzeln auf seine Produktivdomain.

Der Grund, warum ausgerechnet diese drei Stellschrauben zusammenspielen müssen, liegt an der Architektur von Shopware 6: APP_URL ist der Wert, den die Anwendung selbst für intern generierte Links und für die App-Kommunikation nutzt, die Sales-Channel-Domain ist der Wert, über den der jeweilige Verkaufskanal beim Routing erkannt wird, und der Lizenz-Host ist der Wert, den der Shopware-Account zur Zuordnung der Lizenz und zur App-Abrechnung heranzieht. Stimmen diese drei nicht überein, arbeiten Routing, App-System und Lizenzverwaltung mit unterschiedlichen Vorstellungen davon, wo der Shop eigentlich erreichbar ist – und genau das äußert sich dann in den Fehlerbildern aus Abschnitt 4.

Erkennt Shopware beim Admin-Login eine Diskrepanz zwischen der gespeicherten und der aktuell aufgerufenen URL, erscheint automatisch ein Modal mit drei Optionen: Apps auf die neue Domain migrieren (Shop-ID bleibt erhalten – der richtige Weg bei einem echten Umzug), Apps auf die aktuelle Domain kopieren (neue Shop-ID, gedacht für Staging-Umgebungen) oder Apps deinstallieren.^Quelle Der Sales-Channel-Domain-Mechanismus ist außerdem direkt im Quellcode nachvollziehbar und laut mehreren Community-Threads der häufigste Stolperstein, wenn er vergessen wird.^Quelle Hosting-seitig muss die Domain zusätzlich korrekt auf das /public/-Verzeichnis der Installation zeigen.^Quelle

Wichtig für die Einordnung: Eine einzelne, offizielle „So ziehen Sie Ihren Shop auf einen neuen Webspace um“-Anleitung gibt es bei Shopware nicht. Der oben skizzierte Ist-Stand ist aus drei separaten Quellen zusammengesetzt – der APP-URL-FAQ, dem Golive-Leitfaden und dem Staging-Guide. Das ist im weiteren Verlauf des Artikels relevant, weil an manchen Stellen die Praxis (Community-Foren) mehr Details liefert als die Doku selbst.

Zurück zur Übersicht

2. Lösung A: Domain-Umzug mit Shopware-Bordmitteln

Für den reinen Server- und Domain-Wechsel braucht es kein zusätzliches Plugin – die nötigen Werkzeuge bringt Shopware selbst bzw. die shopware-cli mit. Das gilt unabhängig davon, ob der neue Webspace bei einem Shared-Hoster, einem Managed-Shopware-Hoster oder einem eigenen Server liegt – der Ablauf unterscheidet sich nur in Details wie SSH-Zugriff oder Datenbank-Freigaben, nicht im Kern der Shopware-Konfiguration.

Datenbank sichern und übertragen

Für den Datenbank-Transfer gibt es zwei gangbare Wege. Der klassische Weg per mysqldump funktioniert weiterhin technisch einwandfrei. In der aktuellen Staging-Dokumentation wird daneben aber shopware-cli project dump beschrieben, optional mit den Flags --clean und --anonymize:

shopware-cli project dump --clean --host … --output shop.sql shopware – bereinigt den Dump und kann personenbezogene Daten anonymisieren.
mysqldump bleibt eine gültige Alternative, ist aber in der aktuellen Doku nicht mehr der explizit hervorgehobene Standardweg – ein Unterschied in der Betonung, kein „veraltet“.

Ein praktischer Hinweis aus der Staging-Doku: mysqldump/mysql-Binaries müssen auf Quell- und Zielserver von derselben Major-Version und demselben Hersteller stammen (also nicht MySQL-Dump gegen MariaDB-Import mischen).^Quelle Ein natives bin/console database:export-Kommando existiert für Shopware 6.7 nicht – wer danach sucht, landet zwangsläufig bei einem der beiden genannten Wege.

Dateien und Datenbank auf den neuen Webspace bringen

Beim reinen Dateitransfer (Shop-Verzeichnis, files/, public/media) empfiehlt sich SSH/SFTP gegenüber einer FTP-Einzeldatei-Übertragung, gerade bei vielen kleinen Mediendateien – dazu mehr im Abschnitt zu den Praxis-Fehlerbildern. Nach dem Übertragen der Dateien wird die SQL-Datei auf dem Zielserver importiert.

phpMyAdmin-Oberfläche beim Datenbank-Export als Alternative zu mysqldump

APP_URL und Sales-Channel-Domain anpassen

Nach dem Import folgt der eigentlich Shopware-spezifische Teil: .env.local auf die neue Domain setzen und anschließend im Admin unter Verkaufskanäle → Domains den passenden Eintrag korrigieren. Ein aus mehreren Community-Threads immer wieder genannter Praxis-Tipp: Domain nicht direkt in der Datenbank per SQL-Statement ändern, sondern zuerst .env.local anpassen und dann /admin aufrufen – Shopware zeigt dann von selbst den App-URL-Änderungsdialog aus Abschnitt 1.

Weitere nützliche Bordmittel

APP_URL_CHECK_DISABLED=1 in .env/.env.local, falls die automatische Erreichbarkeitsprüfung in Produktivumgebungen fälschlich fehlschlägt – mit dem Hinweis, dass das die App-Funktionalität beeinträchtigen kann.
Konsolenbefehle laut Commands-Referenz: sales-channel:update:domain, system:setup, system:setup:staging und app:url-change:resolve.^Quelle

Alle vier Kommandos richten sich in erster Linie an Staging- und Automatisierungs-Szenarien, lassen sich aber auch bei einem klassischen Domain-Umzug gezielt einsetzen, wenn Sie Teile des Ablaufs statt über den Admin-Dialog per Konsole steuern möchten.

Nach jeder Config- oder Domain-Änderung auf der Zielinstanz gehört bin/console cache:clear dazu – wichtiger als das oft empfohlene „Cache vor dem Export leeren“ ist der Cache-Clear nach der Domain-Umstellung.

Caches leeren im Shopware-Administrationsbereich
Bestätigungsmeldung nach erfolgreichem Cache-Leeren

Zurück zur Übersicht

3. Lösung B: Store-Plugins rund um den Umzug

Für den reinen Webspace-/Domain-Umzug einer bestehenden Shopware-6-Instanz gibt es im Shopware Store aktuell kein dediziertes Umzugs-Plugin – das ist Server-/Datenbank-Administration und kein klassischer Plugin-Use-Case. Zwei Plugins sind in diesem Kontext trotzdem erwähnenswert:

Backup (swpa) – erstellt automatische Datenbank-, Media- und System-Backups lokal oder zu FTP/SFTP/S3, inklusive Retention-Policy und Wartungsmodus während des Backup-Vorgangs. Sinnvoll als zusätzliche Absicherung vor dem Umzug, ergänzend zum manuellen mysqldump/shopware-cli-Dump. Preis: 150,00 €/Jahr (bzw. 12,50 €/Monat) oder 15,00 €/Monat, ein Monat kostenlos testbar. Kompatibilität laut Store-Seite: 6.0.0-DP1 bis 6.7.12.2, Bewertung 4,4/5 bei 8 Rezensionen (Stand 03.08.2026).^Quelle
Shopware Migration Assistant (offiziell von shopware AG) – nur relevant, wenn parallel zum Umzug tatsächlich eine Datenmigration von Shopware 5 auf Shopware 6 gemeint ist, nicht für einen reinen Server-/Domain-Wechsel derselben Shopware-6-Instanz. Kostenlos, kompatibel mit 6.6.0.0 bis 6.7.12.2. Die Bewertung ist mit 1,8/5 bei 33 Rezensionen (64 % Ein-Stern) deutlich unterdurchschnittlich – Nutzer berichten von unvollständigen Migrationen sowie falschen Preis- und Bestandsdaten (Stand 03.08.2026). Wer wirklich nur die Domain bzw. den Webspace wechselt, braucht dieses Plugin nicht.^Quelle

Backup-Button in der Backup-Plugin-Verwaltung anklicken

Das deckt sich mit der allgemeinen Rolle des Shopware Store: Er bietet vor allem Erweiterungen für Funktionen innerhalb einer laufenden Instanz, nicht für Infrastruktur-Aufgaben wie Server- oder Domain-Wechsel. Wer nach einem Plugin sucht, das den kompletten Umzug automatisiert, wird also strukturell nicht fündig – das ist kein Zufall, sondern liegt am Charakter der Aufgabe.

Kurz zusammengefasst: Für den eigentlichen Domain-/Webspace-Umzug bleiben Sie im Bordmittel-Bereich (Lösung A). Ein Backup-Plugin ist eine sinnvolle Vorsichtsmaßnahme, ersetzt aber nicht die manuellen Schritte an APP_URL, Sales-Channel-Domain und Lizenz-Host.

Zurück zur Übersicht

4. Praxis-Fehlerbilder aus der Community

Die Shopware-Dokumentation deckt den Idealfall ab – die Community-Foren zeigen, wo es in der Praxis tatsächlich hakt. Eine Auswahl belegter Fehlerbilder aus 2023–2026:

Fehlendes „www“-Präfix im Sales-Channel-Domain-Eintrag führt zur Meldung „Unable to find a matching sales channel for the request: https://www.domain.de“, wenn die DNS-Weiterleitung mit www arbeitet, der Domain-Eintrag im Admin aber ohne www gepflegt ist (Forum, 16.05.2025).^Quelle
500er-Fehler nach dem Umzug von Staging auf Produktiv trotz korrektem DB-Restore und angepasster .env. Der Community-Rat: Domain nicht direkt in der Datenbank ändern, sondern .env.local anpassen und /admin aufrufen, damit Shopware selbst den App-URL-Dialog anzeigt (Forum, 6.7.x, 23.–24.04.2026).^Quelle
Hosterwechsel IONOS → Hetzner: FTP-Timeouts bei über 60 Einzeldateien, leere Backend-Seite, fehlendes Frontend-CSS und ausgefallene Plugin-Funktionen; zusätzlich erzwang eine MariaDB-Inkompatibilität ein Versions-Upgrade. Empfehlung aus dem Thread: Dateien vor dem Transfer zippen statt einzeln per FTP zu übertragen (Forum, 30.04.–17.05.2024). Das ist eine Einzelmeinung aus einem konkreten Fall, keine generelle Hoster-Warnung.^Quelle
AppUrlChangeDetectedException als Kernproblem: Ändert sich die APP_URL, ohne dass die Änderung sauber über den Admin-Dialog aufgelöst wird, drohen im Worst Case Datenvermischung zwischen Shop-Umgebungen und Datenverlust (GitHub Issue #6749, erstellt 12.02.2025, mittlerweile geschlossen).^Quelle
Zwei grundsätzlich unterschiedliche Szenarien: (a) ein echter Serverwechsel verlangt Lizenz-Umschreibung, Verkaufskanal-Änderung und .env-Anpassung; (b) eine reine Domain-Weiterleitung wird dagegen besser über einen zusätzlichen Verkaufskanal gelöst statt über eine harte Domain-Änderung (Forum, 21.01.2023).^Quelle
Error 500 nach Host-/Domainwechsel trotz korrektem Backup: Die Ursache war am Ende nicht die Datenbankverbindung, sondern eine falsche Sales-Channel-Domain-Zuordnung. Fix: Lizenzdomain, Sales-Channel-Domain, APP_URL/DATABASE_URL und die Domain-Bestätigung im Shopware-Account gemeinsam prüfen (Forum, 03.05.–17.07.2023).^Quelle

Ein häufig genannter, aber ausdrücklich nicht offiziell unterstützter Workaround aus dem Forum lautet bin/console system:config:set core.app.shopId https://yourUrl.com (Antwort vom 29.05.2024). Der Original-Poster nennt keine bekannten Nebenwirkungen, es handelt sich aber um einen ungetesteten Community-Befehl, keinen offiziell dokumentierten Weg – vor dem Einsatz auf einer Produktivinstanz sollte das mit Bedacht und idealerweise erst auf einer Kopie getestet werden.^Quelle

Auffällig an den hier gesammelten Fällen ist, dass die konkrete Fehlermeldung – ob 500er, „Unable to find a matching sales channel“ oder eine leere Backend-Seite – kaum etwas über die tatsächliche Ursache verrät. In praktisch allen zitierten Threads landete die Diagnose am Ende bei genau einer der drei Stellschrauben aus Abschnitt 1.

Zurück zur Übersicht

5. Schritt-für-Schritt-Ablauf für den Domain-Umzug

Aus Dokumentation, Quellcode und den Community-Fehlerbildern lässt sich eine praxistaugliche Reihenfolge ableiten. Sie ist nicht wörtlich als „die“ offizielle Schritt-für-Schritt-Anleitung von Shopware dokumentiert, sondern aus den in Abschnitt 1 und 2 genannten Quellen zusammengesetzt:

Backup/DB-Dump erstellen – per shopware-cli project dump, mysqldump oder einem Backup-Plugin (siehe Lösung A und B).
Dateien übertragen – Shop-Verzeichnis, files/ und public/media per SSH/SFTP auf den neuen Webspace kopieren.
Datenbank auf dem Zielserver importieren – SQL-Datei einspielen, bei Bedarf externen Datenbankzugriff beim neuen Hoster temporär freischalten, falls der Import nicht direkt auf dem Server, sondern über ein lokales Tool erfolgt. Das ist ein allgemeiner Hosting-Mechanismus und vom jeweiligen Provider abhängig, keine Shopware-spezifische Vorgabe.
.env.local anpassen – APP_URL auf die neue, extern erreichbare Domain setzen.
Sales-Channel-Domain im Admin eintragen – Verkaufskanäle → Domains, inklusive korrektem www-Präfix passend zur DNS-Konfiguration.
Lizenz-Host umstellen – Einstellungen → System → Shopware-Account zuerst auf die neue Hauptdomain, danach jeden Verkaufskanal einzeln auf die Produktivdomain setzen.
Cache leeren – bin/console cache:clear nach allen Config-Änderungen.
Admin-Login und App-URL-Dialog – /admin aufrufen, den App-URL-Änderungsdialog bestätigen (in der Regel „Apps auf neue Domain migrieren“ bei einem echten Umzug).

Shop-Ordner auf dem neuen Server via SSH-Verbindung
FileZilla mit dem privaten Ordner der Shopware-Installation
Schalter für externen Datenbankzugriff in der Hosting-Verwaltung

Diese Reihenfolge deckt den Regelfall ab: derselbe Shop, dieselbe Instanz, neuer Server und/oder neue Domain. Bei einer reinen Domain-Weiterleitung ohne Serverwechsel kann laut einem der Foren-Threads auch ein zusätzlicher Verkaufskanal statt einer harten Domain-Änderung die bessere Lösung sein.

Nach erfolgreichem Umzug lohnt sich ein kurzer manueller Check: Startseite und mindestens ein Produkt im Frontend aufrufen, den Checkout bis zur Zahlartauswahl durchklicken und im Admin unter Einstellungen → System → Shopware-Account prüfen, ob die Lizenz korrekt der neuen Domain zugeordnet ist. Das ersetzt keine vollständige Testroutine, deckt aber die häufigsten der in Abschnitt 4 beschriebenen Fehlerbilder zuverlässig auf.

Zurück zur Übersicht

6. Muss ich beim Umzug das Theme wechseln?

Kurze Antwort: Nein, ein Theme-Wechsel ist beim reinen Domain-/Webspace-Umzug nicht nötig. Die Theme-Konfiguration hängt am Theme selbst und am Verkaufskanal, nicht an der Domain – das lässt sich aus dem in Abschnitt 1 verifizierten Sales-Channel-Domain-Mechanismus plausibel ableiten. Eine Quelle, die das wortwörtlich als „Theme-Konfiguration bleibt bei einem Domain-Umzug erhalten“ formuliert, haben wir bei der Recherche allerdings nicht gefunden, deshalb formulieren wir das hier bewusst vorsichtig. In der Praxis bedeutet das für Nutzer unseres eigenen DreamTheme: Der Umzug selbst ist ein reiner Infrastruktur-Vorgang und betrifft primär APP_URL, Sales-Channel-Domain und Lizenz-Host – am Theme oder dessen Einstellungen müssen Sie dafür nichts anfassen. Anders sieht es nur aus, wenn im Zuge des Umzugs zusätzlich ein Wechsel der Storefront-Technologie oder ein Wechsel des Sales-Channel-Typs geplant ist – das ist dann aber ein eigenständiges Projekt und kein Bestandteil des reinen Domain-Umzugs.

Zurück zur Übersicht

Häufig gestellte Fragen zum Shopware 6 Domain-Umzug

Reicht es, nur die Dateien und die Datenbank zu übertragen?

Nein. Ohne Anpassung von APP_URL in .env.local und dem Domain-Eintrag im Verkaufskanal (sales_channel_domain) meldet Shopware typischerweise „Unable to find a matching sales channel for the request“ oder einen 500er, selbst wenn Datenbank und Dateien korrekt übertragen wurden.

Wo trage ich die neue Domain überhaupt ein?

An zwei Stellen: in .env.local als APP_URL und im Admin unter Verkaufskanäle → Domains als Sales-Channel-Domain. Zusätzlich unter Einstellungen → System → Shopware-Account als Lizenz-Host.

Was ist der Unterschied zwischen shopware-cli project dump und mysqldump?

Beide exportieren die Datenbank technisch funktionsfähig. shopware-cli project dump ist in der aktuellen Staging-Dokumentation der stärker hervorgehobene Weg und bietet Zusatzoptionen wie --clean und --anonymize. mysqldump funktioniert weiterhin, ist aber nicht mehr der explizit betonte Standardweg.

Brauche ich für den Umzug ein Store-Plugin?

Für den reinen Domain-/Webspace-Umzug einer bestehenden Shopware-6-Instanz nicht zwingend – es gibt dafür kein dediziertes Store-Plugin. Ein Backup-Plugin wie swpa Backup ist als zusätzliche Absicherung sinnvoll, der Shopware Migration Assistant ist nur bei einer echten SW5→SW6-Migration relevant.

Was mache ich, wenn nach dem Umzug ein 500er-Fehler erscheint?

Laut mehreren Foren-Threads liegt die Ursache meistens nicht an der Datenbankverbindung, sondern an einer falsch gepflegten Sales-Channel-Domain oder einer nicht angepassten APP_URL. Prüfen Sie zuerst .env.local, dann den Domain-Eintrag im Verkaufskanal, danach Lizenzdomain und Cache. Ergänzend hilft ein Blick ins Shopware-Log-Verzeichnis (var/log) – die dort protokollierte Exception liefert in der Regel einen konkreteren Hinweis als die reine 500-Meldung im Browser.