Vom SaaS-Mietshop in die eigene Plattform: Wann der Wechsel sich rechnet — und welche Spuren der Vorgänger im Bestand hinterlässt

„Wir wollen weg von der Mietshop-Lösung und unseren eigenen Shop bauen.“ Dieser Satz ist im Jahr 2026 öfter zu hören als vor fünf Jahren. Die Gründe sind selten ein einzelner Auslöser — meist ist es die Summe: steigende Monatsgebühren, ein Plugin-Friedhof, der jährlich teurer wird, eine Layout-Welt, die nicht zur Marke passt, Funktionen, die nicht abbildbar sind, ohne ein weiteres Modul zu mieten.

Dieser Artikel beschreibt, wie der Wechsel von einem SaaS-Mietshop (Plattform-Namen vermeiden wir bewusst — die Kategorie ist klar) zur eigenen Plattform praktisch abläuft. Wir nennen die typischen Datenströme, die Fallen und die Entscheidungs-Punkte. Ziel: realistisches Bild für Inhaber, die den Wechsel überlegen oder schon im Anlauf sind.

Warum überhaupt wechseln

SaaS-Mietshops sind eine ehrliche Antwort auf einen ehrlichen Bedarf: schnell einen Shop online stellen, ohne eigene Infrastruktur. Für die ersten Jahre eines Sortiments oder als Test-Vehikel sind sie oft der richtige Weg. Sie haben aber strukturelle Grenzen, die mit wachsendem Geschäft sichtbar werden:

• Monatsgebühren skalieren mit dem Umsatz, nicht mit dem Funktions-Umfang. Wer im sechsstelligen Bereich verkauft, zahlt für die Mietshop-Lösung oft fünfstellige Jahresbeträge — für eine Leistung, die ihn vor fünf Jahren noch beeindruckt hat und heute nur noch funktional ist.
• Plugin-Friedhof. Jede Sonder-Funktion (Premium-Versand, B2B-Logik, externes Lager, Warenwirtschafts-Anbindung) braucht ein eigenes Modul. Jedes Modul kostet, jedes muss gepflegt werden, jedes ist abhängig von einem dritten Anbieter, der morgen die Konditionen ändern kann.
• Daten gehören dem Plattform-Anbieter. Bestellungen, Kundendaten, Sortimente — alles liegt im fremden System. Export ist möglich, aber meistens umständlich und unvollständig.
• Branding-Grenzen. Die Mietshop-Themes sind sehr austauschbar. Wer ein Premium-Markenbild will, kämpft gegen die Templates, statt mit ihnen zu arbeiten.
• Performance-Grenzen. Bei wachsendem Sortiment werden die Standard-Themes langsam. Geschwindigkeits-Optimierung in der gemieteten Umgebung ist eingeschränkt möglich.
• Anbieter-Abhängigkeit. Wer auf einer Mietshop-Plattform sitzt, ist von deren Roadmap, Preis-Politik und Übernahme-Geschehen abhängig. Branchen-Veränderungen können den Shop von heute auf morgen teurer oder enger machen.

Wann der Wechsel sich rechnet

Drei Indikatoren, die wir in Audits regelmäßig sehen:

• Jährliche SaaS-Kosten über etwa 6.000 bis 10.000 Euro — ab diesem Bereich amortisiert sich die eigene Plattform meist innerhalb von zwei bis drei Jahren über eingesparte Lizenz-Gebühren plus gewonnene Funktions-Tiefe.
• Mehr als drei Sonder-Module im Einsatz — der Plugin-Stapel wird zur eigenen Wartungs-Disziplin, ohne dass das Geschäft davon profitiert.
• Mehrere unausgesprochene Wünsche, die das Mietshop-System nicht abbildet — eigene B2B-Logik, eigenes Druckportal-Modul, eigene KI-Integration, eigene Workflow-Abläufe. Solange das Aufkommen einzeln bleibt, kann der Mietshop reichen. Sobald sich drei oder mehr solcher Wünsche sammeln, wird der Wechsel wirtschaftlich vernünftig.

Wenn keiner dieser drei Indikatoren stimmt, ist der Wechsel selten eine gute Idee. „Lust auf etwas Neues“ ist kein wirtschaftliches Argument — die Migration kostet Zeit und Risiko, das nur dann sinnvoll investiert ist, wenn am Ende eine echte Verbesserung steht.

Die drei Daten-Kategorien

Produktdaten

Sortiment mit allen Varianten, Bildern, Beschreibungen, Kategorien, Preisen, Steuersätzen. Im SaaS-Mietshop liegen diese Daten in einem proprietären Format. Der Export ist meist als CSV oder über eine API möglich, aber nicht immer vollständig — typische Schwachstellen:

• Varianten-Logik unterschiedlich pro System. Was im alten Shop „Größe: M, Farbe: blau“ als zwei Achsen war, muss im neuen Shop in der gleichen Logik wieder zusammengebaut werden.
• Bilder als externe URLs eingebunden — beim Wechsel müssen sie auf die neue Domain umgezogen werden, sonst entstehen Image-Hot-Links zum alten System.
• SEO-Daten (Meta-Beschreibung, Schema.org-Marker) sind oft nur halb exportierbar.
• Reviews und Bewertungen kommen je nach altem System ganz oder gar nicht mit.
• Produkt-Beziehungen (Cross-Sell, Up-Sell, Zubehör) müssen oft komplett neu aufgebaut werden.

Kundendaten

Konten, Bestell-Historie, Wunschlisten, Zustimmungen für Newsletter und Tracking. Die rechtliche Lage ist sensibel:

• Konto-Passwörter sind nicht migrierbar — sie sind im alten System gehasht, das neue System hat eine andere Hash-Logik. Die Käufer müssen ihre Passwörter zurücksetzen.
• Bestell-Historie ist DSGVO-relevant, sie kann migriert werden, wenn der Käufer dem zugestimmt hat (im Regelfall im Vertrag des Mietshops abgedeckt) oder wenn ein berechtigtes Interesse vorliegt.
• Newsletter-Zustimmungen sind nicht ohne Weiteres übertragbar. Im Zweifelsfall muss der Käufer erneut zustimmen — Double-Opt-In im neuen System.
• Tracking-Zustimmungen verfallen mit dem alten Cookie-Banner. Der neue Shop fragt neu.

URL-Struktur

Hier liegt die größte Migrations-Falle — und sie ist die teuerste, wenn sie schiefläuft. Suchmaschinen haben über Jahre die alten URLs des Shops indexiert. KI-Suche zitiert die alten URLs, weil sie in ihrem Trainings- oder Live-Bestand stehen. Wenn der neue Shop andere URLs hat (was er fast immer hat, weil die Systeme unterschiedlich strukturieren), verliert der Inhaber die SEO-Substanz, die er über Jahre aufgebaut hat — es sei denn, er setzt 301-Weiterleitungen sauber um.

Eine 301-Weiterleitung sagt der Suchmaschine: „Diese URL ist dauerhaft auf jene umgezogen“. Suchmaschinen übertragen das Ranking-Vermögen auf die neue URL — vollständig, sofern die Weiterleitung sauber ist und die neue Seite inhaltlich passt.

In der Praxis heißt das: Vor der Migration wird eine vollständige URL-Liste des alten Shops gezogen (Produktseiten, Kategorie-Seiten, Inhalts-Seiten, Blog-Beiträge). Pro alter URL wird die neue URL definiert. Die Weiterleitungen werden im neuen Shop oder in der Webserver-Konfiguration eingerichtet und vor dem Go-Live getestet.

Der Migrations-Ablauf

Phase 1: Vorbereitung (2 bis 6 Wochen)

• Sortiments-Audit. Was bleibt, was fliegt raus (alte Saisonware, Auslauf-Modelle).
• Kategorie-Struktur neu denken. Die alte Struktur ist oft historisch gewachsen — die Migration ist die Gelegenheit, sie zu schärfen.
• URL-Plan. Pro alter URL die neue URL festlegen.
• Export-Tests aus dem alten System. Was kommt vollständig raus, was lückenhaft?
• Architektur-Entscheidungen neuer Shop. Plattform, Hosting, Module.

Phase 2: Aufbau (4 bis 12 Wochen)

• Neuer Shop wird parallel zum alten aufgebaut. Domain läuft noch auf alt.
• Sortimentsdaten werden importiert, manuell nachgepflegt wo nötig.
• Design-Anpassungen, Branding, Tonalität.
• Integrationen (Versand, Zahlung, Lager).
• Funktions-Tests: Bestell-Strecke, Checkout, Retoure, Self-Service.

Phase 3: Cut-over (1 Tag bis 1 Woche)

• Bestell-Stopp im alten Shop für 24 bis 48 Stunden.
• Letzte Bestellungen abarbeiten.
• Datenstand-Übertrag (offene Bestellungen, finaler Kunden-Stand).
• Domain auf neuen Shop umstellen.
• 301-Weiterleitungen aktivieren.
• Test der gesamten Bestell-Strecke mit Test-Bestellungen.
• Bestell-Annahme im neuen Shop öffnen.

Phase 4: Nachlauf (4 bis 12 Wochen)

• Monitoring der Such-Sichtbarkeit. Weiterleitungen werden von Suchmaschinen verarbeitet — Ranking-Wackel sind in den ersten zwei Wochen normal.
• Käufer-Support für Passwort-Reset und Konto-Wiederherstellung.
• Pflege der Suchmaschinen-Aussagen (sitemap.xml, Search-Console-Eintrag).
• Optimierung der neuen Inhalte, Lücken im Sortiment schließen.
• Alter Shop bleibt für 4 bis 12 Wochen als „Schatten-Kopie“ stehen, falls Daten nachgezogen werden müssen — dann endgültig abgeschaltet.

Die zehn häufigsten Fallen

1. URL-Weiterleitungen unvollständig. Wer nur die Produktseiten weiterleitet und Kategorie-Seiten, Inhalts-Seiten und Blog-Beiträge vergisst, verliert Sichtbarkeit.
2. Bilder-Pfad-Brüche. Alte Bild-URLs zeigen ins Leere, Produktseiten haben Lücken.
3. Steuersatz-Abweichungen. Wer im alten Shop Brutto-Preise pflegte und im neuen Netto, läuft in Preisdifferenzen.
4. Varianten-Logik bricht. Was im alten System zwei Achsen waren, ist im neuen als verschachtelte Varianten gebaut — die Stücklisten passen nicht mehr.
5. Bewertungen verschwinden. Mehrjährige Bewertungs-Sammlung wandert in den Datenfriedhof, statt im neuen Shop weiter sichtbar zu sein.
6. Newsletter-Liste schrumpft. Beim Übergang auf den neuen Newsletter-Stack müssen die Zustimmungen neu eingeholt werden — manche Käufer reagieren nicht, die Liste wird kleiner.
7. Bestand-Synchronisation läuft schief. Während der Cut-over-Phase verkauft das alte System noch, das neue schon — Doppel-Verkäufe sind die Folge.
8. Zahlungs-Anbindungen müssen neu aufgesetzt werden. Verträge mit Zahlungs-Dienstleistern müssen oft erweitert oder neu verhandelt werden, weil das System sich ändert.
9. SEO-Metadaten verloren. Title, Description, Open-Graph-Bilder — wenn diese Metadaten nicht migriert werden, verlieren die neuen Seiten ihre Suchmaschinen-Substanz.
10. Such-Funktion läuft nicht so wie früher. Käufer suchen Produkte, die im alten Shop unter einem Synonym gefunden wurden — im neuen Shop sind die Synonyme nicht hinterlegt, der Käufer findet nicht.

Was Hannes daraus macht

Wir begleiten Migrations-Projekte von SaaS-Mietshops in die eigene Plattform mit einem strukturierten Ablauf:

• Pre-Migration-Audit: Sortiment, Daten, URLs, SEO-Substanz, betriebliche Abläufe.
• URL-Mapping vor Aufbau: alle alten URLs auf neue URLs gemappt, 301-Weiterleitungs-Plan als Liefer-Artefakt.
• Datenmigration in mehreren Wellen, mit Stichprobe-Prüfung nach jeder Welle.
• Parallel-Lauf alter und neuer Shop in der Aufbau-Phase, kein Verlust an Bestellungen während der Migration.
• Cut-over an einem ruhigen Tag (Sonntag früher Morgen ist oft der saubere Slot), mit Test-Bestell-Strecke vor Bestell-Öffnung.
• 4 Wochen Nachlauf-Monitoring mit Such-Sichtbarkeit, Kunden-Support, Bestand-Korrektur.
• Schatten-Kopie alter Shop für mindestens 8 Wochen, falls Nachträge gebraucht werden.

Festpreis nach Audit, transparent kommuniziert. Migrationen sind kein Selbstläufer, aber mit sauberer Vorbereitung kalkulierbar und in einem definierten Zeitfenster machbar. Wer die Migration als „neuen Shop aufsetzen“ plant, unterschätzt sie. Wer sie als „SEO-Vermögen-Übertragung mit Shop-Umstellung im Kern“ plant, ist auf der sicheren Seite.