Beibehalten
Die Funktion wird benötigt und arbeitet gut.
Ein Plattformwechsel ist mehr als das Verschieben von Produkten, Kunden und Bestellungen in eine neue Datenbank. Funktionierendes muss erhalten, Integrationen und Suchsichtbarkeit müssen geschützt werden. Zugleich gilt es zu entscheiden, welche Einschränkungen der bisherigen Lösung nicht übernommen werden sollten.
Wir migrieren Magento-1-, WooCommerce- und individuell entwickelte Shops sowie andere Systeme auf Magento 2. Die neue Plattform richten wir an den tatsächlichen Unternehmensprozessen und den Anforderungen der kommenden Jahre aus, statt den bisherigen Shop Funktion für Funktion nachzubauen.
Ein kostenloses Gespräch von 30–60 Minuten. Wir lernen Ihre aktuelle Plattform, den Datenumfang, die Integrationen und die Rahmenbedingungen der Migration kennen. Wir skizzieren die wichtigsten Risiken und Bereiche mit weiterem Discovery-Bedarf.
Ausgangslage
Die Entscheidung für eine Migration entsteht selten aus einem einzelnen Problem. Mit der Zeit verlangt die bestehende Plattform immer mehr Umgehungslösungen, Integrationen werden aufwendiger zu warten und jede individuelle Funktion endet in einem Kompromiss.
Magento ist besonders sinnvoll, wenn ein Unternehmen mehr Kontrolle über Code und Architektur, umfangreiche Integrationen, eigene Geschäftslogik oder Unterstützung für mehrere Märkte und Vertriebsmodelle benötigt.
In einem solchen Projekt geht es nicht einfach darum, Magento zu starten. Ein laufendes Geschäft soll auf eine neue Technologie wechseln, ohne Daten, Prozesse oder Vertriebskontinuität zu verlieren.
Entscheidungen
Ein älterer Shop enthält meist mehrere Logikschichten, die vor Jahren unter bestimmten Bedingungen entstanden sind. Einiges ist weiterhin geschäftlich sinnvoll. Anderes löst Probleme, die nicht mehr bestehen. Manche Mechanismen erledigen aufwendig, was Magento standardmäßig unterstützt.
Deshalb treffen wir während der Discovery für jeden wichtigen Bestandteil der bestehenden Lösung eine von vier Entscheidungen:
Die Funktion wird benötigt und arbeitet gut.
Der Bedarf besteht, die Umsetzung kann aber einfacher oder besser auf Magento abgestimmt werden.
Die Funktion ist nativ vorhanden oder lässt sich mit einer bewährten Lösung abdecken, ohne einen weiteren eigenen Mechanismus aufzubauen.
Der Prozess bringt keinen Nutzen mehr, obwohl er im aktuellen System noch aktiv ist.
Die letzte Entscheidung ist oft die unangenehmste, weil sie Funktionen hinterfragt, die einmal einen berechtigten Zweck hatten. Dieses Gespräch sollte vor der Entwicklung stattfinden, solange sich Annahmen noch ändern lassen, ohne eine fertige Lösung umbauen zu müssen.
Der Versuch, eine alte Plattform eins zu eins nachzubauen, führt meist dazu, ihre Probleme in das neue System zu übertragen und dafür den vollen Preis zu zahlen.
Absicherung
Der Umfang hängt vom Projekt ab. Wir können Produkte und Varianten, Kategorien, Kundenkonten, Adressen, Bestellungen und Kaufhistorie, Preise, Preisregeln, Rabatte, Gutscheine, CMS-Inhalte, Medien, B2B-Daten sowie die Konfiguration von Sprachen, Store Views und Märkten migrieren.
Nicht alle Daten sollten immer übernommen werden. Die Bestellhistorie ist ein gutes Beispiel: Wird sie im Kundenservice oder Reporting genutzt, kann sie nach Magento übertragen werden. Bei großen Datenmengen kann es dagegen sinnvoller sein, ältere Daten als Archiv im Altsystem zu belassen.
Der Umfang richtet sich nach dem geschäftlichen Bedarf, nicht nach dem Grundsatz, alles migrieren zu müssen.
Mit einer Plattformmigration verändert sich üblicherweise auch die Kommunikation des Shops mit ERP, PIM, CRM, Lagerverwaltung und individuellen Lösungen.
Zuerst klären wir, welche Prozesse die aktuelle Integration unterstützt und welche erhalten bleiben müssen. Erst danach entscheiden wir, ob sich die bestehende technische Lösung wiederverwenden lässt oder die Integration für Magento neu konzipiert werden sollte.
Für jeden Datenfluss – Produkte, Preise, Bestände, Kunden, Bestellungen und Status – definieren wir Richtung und Häufigkeit der Synchronisierung, die Fehlerbehandlung und das führende System. Gerade diese letzte Entscheidung ist bei älteren Implementierungen häufig nicht dokumentiert. Ihr Fehlen verursacht dann Datenabweichungen.
Wir haben Erfahrung mit SAP, Comarch, Microsoft Dynamics und Enova sowie mit individuellen Systemen auf Kundenseite.
Systemintegrationen →Eines der größten Risiken beim Plattformwechsel ist der Verlust organischer Sichtbarkeit nach Änderungen an URLs und Seitenstruktur. Die technische SEO-Migration gehört ins Projekt und darf nicht bis zum Tag vor dem Launch aufgeschoben werden.
Wir erstellen Zuordnungen alter zu neuen URLs, 301-Weiterleitungen, Canonicals, Sitemaps und weitere Elemente für die Indexierung. Wo sinnvoll, erhalten wir die bestehende URL-Struktur. Wir können auch die Empfehlungen Ihres SEO-Teams oder Ihrer Agentur umsetzen.
Es wäre unseriös, nach einem größeren Plattformwechsel unveränderte Rankings zu garantieren. Wir können die Migration jedoch sorgfältig vorbereiten und das Risiko technischer Fehler reduzieren.
Wir migrieren Daten vor dem endgültigen Launch, damit sich Vollständigkeit und Korrektheit prüfen lassen, bevor die neue Plattform Bestellungen verarbeitet.
Den Go-live bereiten wir als kontrollierte Umschaltung vor: Wir bestimmen den Zeitpunkt für den Änderungsstopp im Altsystem, führen den abschließenden inkrementellen Datenimport und Tests durch, schalten die Domain um, prüfen Integrationen unter Produktionsbedingungen und überwachen die ersten Bestellungen.
Das Rückfallszenario wird im Voraus vorbereitet, nicht erst während der Umschaltung.
Das Altsystem wird in der Regel nicht sofort abgeschaltet. Es kann eine Zeit lang als Archiv historischer Daten oder als Rückfalllösung verfügbar bleiben.
Migration, Validierung und Datenbereinigung
~500.000
Produkte
Bei großen Migrationen ist der Import von Datensätzen nur ein Teil der Aufgabe.
Bei einem unserer Migrationsprojekte umfasste der Umfang etwa 500.000 Produkte. Vor und während der Migration mussten die Daten validiert, bereinigt und fehlende Informationen ergänzt werden.
Zu den Arbeiten gehörten:
Bei dieser Größenordnung reicht die Frage nicht aus, ob Produkte importiert wurden. Es muss auch geprüft werden, ob die migrierten Daten vollständig und konsistent sind und von Magento, Suche, Integrationen und Shopkunden zuverlässig genutzt werden können.
UX/UI
Ein Technologiewechsel ist eine gute Gelegenheit für ein UX/UI-Redesign. Nicht jedes Projekt benötigt es jedoch.
Funktioniert die aktuelle Oberfläche gut, können wir ihre gestalterische Richtung beibehalten und uns auf Technologie, Architektur und Integrationen konzentrieren. Das reduziert die Zahl der Projektvariablen und erleichtert es, die Auswirkungen des reinen Technologiewechsels zu beurteilen.
Benötigt der alte Shop auch Änderungen am Nutzererlebnis, können wir den vollständigen UX/UI-Prozess durchführen und eine neue Oberfläche gestalten.
Das sind zwei unabhängige Entscheidungen. Eine Migration auf Magento sollte nicht automatisch ein Redesign bedeuten, nur weil eine neue Plattform entsteht.
Option 01
Technologiewechsel bei Beibehaltung der bisherigen gestalterischen Richtung.
Option 02
Neue Technologie und eine neue UX/UI.
Prozess
Analyse der aktuellen Plattform: Funktionen, Prozesse, Daten und Integrationen. Definition der Anforderungen an die neue Lösung.
Entscheidung, was erhalten, neu umgesetzt, durch Magento-Standardfunktionen ersetzt oder entfernt wird. Fachliche und technische Dokumentation sowie Zielarchitektur.
Aufbau der Plattform, individueller Funktionen und Integrationen. UX/UI, sofern Teil des Projekts.
Datenmigration vor dem Launch und Prüfung von Vollständigkeit und Korrektheit in einer funktionsfähigen Umgebung.
Abschließender inkrementeller Datenimport, Tests, Umschaltung und Prüfung der zentralen Prozesse.
Überwachung von Bestellungen, Integrationen und Performance nach dem Launch.
Einzelne Bereiche können parallel umgesetzt werden. Wir behandeln den Prozess nicht als starres Wasserfallmodell.
Risiken
URL-Zuordnung, Weiterleitungen und Indexierungskontrolle planen wir vor dem Launch, nicht erst nach sinkenden Rankings.
Wir migrieren vor der Umschaltung und prüfen die Vollständigkeit auf der neuen Plattform. Importierte Datensätze bedeuten noch nicht, dass ihre Verknüpfungen korrekt sind.
Wir identifizieren die Prozesse, die tatsächlich neu umgesetzt werden müssen. Wird dieser Bereich unterschätzt, können Umfang und Kosten während der laufenden Entwicklung steigen.
Die neue Plattform sollte die Grenzen des Altsystems nicht erben. Für jeden wichtigen Bestandteil wird bewusst entschieden: beibehalten, neu umsetzen, durch Standardfunktionen ersetzen oder entfernen.
Technologie
Magento ist nicht für jeden Shop die richtige Wahl.
Seine Vorteile zeigen sich, wenn E-Commerce Kontrolle über die Technologie, individuelle Prozesse, zahlreiche Integrationen oder Vertrieb auf mehreren Märkten erfordert.
Für neue Projekte arbeiten wir meist mit Magento Open Source und Hyvä. Adobe Commerce empfehlen wir, wenn konkrete Anforderungen die zusätzlichen Funktionen und Lizenzkosten rechtfertigen.
Wir beginnen nicht mit der Lizenz, sondern mit den Anforderungen.
Eignung
Es gibt keinen bestehenden Shop und keine zu migrierenden Daten.
Magento-Implementierung →Das Problem liegt in der Umsetzungsqualität, Architektur oder fehlenden Projektkontrolle und nicht in der Plattform selbst.
Rettung und Übernahme von Magento-Projekten →In diesem Fall ist ein Plattformwechsel selten die kostengünstigste Lösung.
Magento-Performanceoptimierung →Den größten Nutzen bringen wir in Projekten, bei denen die Migration auch Gelegenheit bietet, bestehende Prozesse zu prüfen. Wenn die bisherige Lösung grundsätzlich nicht hinterfragt werden darf, sind wir vermutlich nicht der passende Umsetzungspartner.
Fragen
Ja. Das ist kein normales Versionsupdate: Die Architekturen unterscheiden sich grundlegend. M1 → M2 bedeutet deshalb eine neue Plattform mit geplanter Datenmigration sowie die Neuimplementierung oder Neukonzeption von Funktionen und Integrationen.
Ja. Produkte, Kunden und Bestellungen lassen sich meist gut planbar übertragen. Plugin-basierte Funktionen und individuelle Logik benötigen mehr Analyse: Wir müssen entscheiden, was in Magento neu umgesetzt und was durch Standardfunktionen ersetzt werden kann.
Nein, das ist meist auch nicht sinnvoll. Einige Funktionen lassen sich durch Magento-Standard ersetzen, andere neu umsetzen oder entfernen, wenn sie keinen Nutzen mehr bringen. Für jeden wesentlichen Bestandteil treffen wir während der Discovery eine bewusste Entscheidung.
Nein. Entscheidend ist, wie die Daten tatsächlich genutzt werden: im Kundenservice, bei Reklamationen, im Reporting oder in anderen Geschäftsprozessen. Einige Unternehmen übernehmen die gesamte Historie, andere belassen ältere Daten als zugängliches Archiv im Altsystem.
Zuerst klären wir, was die aktuelle Integration tatsächlich leistet und welche Prozesse erhalten bleiben müssen. Danach bewerten wir, ob die vorhandene Lösung nachgebaut oder für Magento neu konzipiert werden sollte. Für jeden Datenfluss bestimmen wir Richtung und Häufigkeit der Synchronisierung, Fehlerbehandlung und die maßgebliche Datenquelle.
Jeder größere Plattformwechsel birgt Risiken, die sich jedoch reduzieren lassen. Korrekte URL-Zuordnungen, 301-Weiterleitungen, Indexierungskontrolle und die Vorbereitung der technischen SEO-Migration vor dem Launch sind entscheidend – nicht erst nach einem Rankingverlust.
Nein. Wir können die aktuelle UX/UI-Richtung beibehalten oder ein vollständiges Redesign durchführen. Das sind zwei unabhängige Entscheidungen.
Es kann abgeschaltet werden oder eine Zeit lang als Archiv historischer Daten beziehungsweise als Rückfalllösung erhalten bleiben. Das Vorgehen vereinbaren wir bei der Planung der Umschaltung.
Hinterlassen Sie einige Angaben zu Ihrer aktuellen Plattform, damit wir uns auf das erste Gespräch vorbereiten können.
Wir melden uns innerhalb von 12 Stunden nach dem Absenden bei Ihnen.