Das Bild, das wir uns von einer Magento-Migration machen, ist oft das eines gigantischen Projekts, das den IT-Abteilungen großer Konzerne vorbehalten ist, mit monatelanger Entwicklungszeit, unerreichbaren Budgets und der Mobilisierung eines ganzen Teams. Diese Darstellung entspricht nicht der Realität der allermeisten Projekte. Bei den meisten E-Commerce-Websites, die heute migrieren, handelt es sich um KMU, mittelständische Marken oder Pure Player, die einfach an die Grenzen ihrer aktuellen Version gestoßen sind. Die Entscheidung für eine Migration ist oft auf ein technisches Detail zurückzuführen, dessen Wartung letztendlich zu viel kostet, und nicht auf eine große digitale Transformation.
Verstehen Sie, warum wir migrieren
Der häufigste Grund bleibt das Ende des Supports Magento 1. Adobe hat die Sicherheitsupdates für diese Version im Juni 2020 offiziell eingestellt, was bedeutet, dass jede Website, die noch unter Magento 1 läuft, seit mehreren Jahren ohne Sicherheitspatches läuft. Es ist keine Frage des Komforts, sondern eine echte Gefährdung durch Schwachstellen. Kunden, die ihre Bestellungen auf einer nicht gepflegten Plattform aufgeben, gehen ein Risiko ein, ebenso wie die E-Händler, die diese Daten hosten. Der Übergang von Magento 1 zu Magento 2 ist daher für diese Websites keine Option, sondern eine betriebliche Notwendigkeit, die schon lange hätte angegangen werden müssen.
Aber Migration ist nicht auf diesen speziellen Fall beschränkt. Einige Projekte beginnen mit einer anderen CMS-Plattform und entscheiden sich für Magento 2 aufgrund seiner nativen Funktionen zur Verwaltung komplexer Kataloge, zur Verwaltung mehrerer Geschäfte oder zur Headless-Kompatibilität. Andere wiederum wechseln von Magento zu Shopify, oft um den internen Entwicklungsaufwand zu reduzieren und die Codeaktualisierung zu vereinfachen. Es gibt diese beiden Richtungen, und sie beinhalten nicht die gleichen Kompromisse.
Unterschätzen Sie die Datenmigration nicht
Hier geraten Projekte am häufigsten aus den Fugen. Dort Migration von Kundendaten, BestellhistorienProduktkataloge und benutzerdefinierte Attribute ist technisch gesehen der schwierigste Teil. Auf einer Website mit mehrjähriger Aktivität enthält die Datenbank Strukturen, die sich im Laufe der installierten Erweiterungen, Codeanpassungen und aufeinanderfolgenden Importe entwickelt haben. Die Migration dieser Daten auf eine neue Plattform ohne Verlust oder Beschädigung erfordert eine ernsthafte Mapping-Phase, bevor überhaupt eine einzige Zeile Migrationscode geschrieben wird.
L’Datenmigrationstool von Adobe Denn der Übergang von Magento 1 zu Magento 2 übernimmt einen Teil der Arbeit, deckt jedoch nicht Daten aus Erweiterungen von Drittanbietern oder individuell hinzugefügte benutzerdefinierte Felder ab. Diese Elemente müssen manuell oder über dedizierte Skripte verarbeitet werden, und jedes Skript muss in einer Rezeptumgebung getestet werden, bevor es in der Produktion ausgeführt wird. Wenn Sie diesen Schritt auslassen, besteht das Risiko, dass Sie zum Go-Live-Termin mit verwaisten Bestellungen oder unvollständigen Kundenkonten ankommen.
Die Agentur Antadis veröffentlicht regelmäßig Rückmeldungen zu Projekten dieser Art, insbesondere dazu, wie die Akzeptanzphase die Qualität der endgültigen Migration bestimmt. Diese Art der Felddokumentation ist nützlich, um Zeitschätzungen vor dem Start eines Projekts zu kalibrieren.
Denken Sie von Beginn des Projekts an an SEO
Eine schlecht vorbereitete E-Commerce-Migration kann in wenigen Wochen SEO zerstören, das über mehrere Jahre hinweg aufgebaut wurde. URLs ändern sich, Seitenstrukturen entwickeln sich weiter, Titel und Meta-Tags müssen für die neue Plattform neu geschrieben werden. Wenn die 301 Weiterleitungen nicht richtig zwischen der alten und der neuen URL platziert werden, verliert Google den Überblick und die Positionen sinken. Dies ist keine Hypothese, sondern ein Szenario, das in Hunderten von E-Commerce-Migrationen dokumentiert ist.
Eine bewährte Vorgehensweise besteht darin, alle indizierten URLs vor der Migration zu prüfen, die vollständige Umleitungszuordnung zu exportieren und jede Umleitungsregel in der Rezeptumgebung zu validieren, bevor sie live geht. Mit Magento 2-Erweiterungen können Sie diese Umleitungen nativ verwalten, sie können jedoch nicht alleine konfiguriert werden. Ein Entwickler, der sich mit SEO-Problemen nicht auskennt, kann eine technisch funktionierende Website liefern, die in den Wochen nach dem Start 40 % ihres organischen Traffics verliert. SEO muss in die Projektspezifikationen integriert werden und darf nicht als Option behandelt werden.
Wahl zwischen Magento 2 und einer anderen Plattform
Die Frage nach der Migration zu Shopify anstelle von Magento 2 wird häufig gestellt und verdient eine ehrliche Antwort. Shopify vereinfacht die tägliche Verwaltung, verringert die Abhängigkeit vom Entwickler für Updates und bietet ein umfangreiches App-Ökosystem. Doch diese Einfachheit hat ihren Preis, und zwar nicht nur finanziell. Die Möglichkeiten zur Anpassung des Codes sind im Vergleich zu Magento, dessen Community-Version weiterhin Open Source ist, begrenzt. Eine Website mit einem Katalog von mehreren tausend Referenzen, komplexen Preisregeln oder spezifischen Anforderungen an die Bestandsverwaltung stößt schnell an die Grenzen von Shopify, wo Magento 2 diese Komplexität ohne zusätzliche Architekturkosten bewältigen kann.
Die Wahl der Plattform muss sich daher an den tatsächlichen Bedürfnissen der Website orientieren und nicht an einem aktuellen Trend. Magento 2 bleibt für Projekte relevant, die eine genaue Kontrolle über den Code, eine umfassende Verwaltung mehrerer Filialen oder eine komplexe ERP-Integration erfordern. Shopify eignet sich am besten für Unternehmen, die ihre technische Abhängigkeit reduzieren und sich auf den Handel statt auf die Infrastruktur konzentrieren möchten. Diese beiden Positionen sind gültig, sie beziehen sich jedoch nicht auf dieselben betrieblichen Realitäten.
Vorausschauendes Erweiterungsmanagement
Einer der blinden Flecken bei Migrationsprojekten ist der Erweiterungskompatibilität. Unter Magento 1 läuft eine durchschnittliche Site mit etwa zehn bis zwanzig installierten Modulen, manchmal auch mehr. Nicht alle dieser Module sind in Magento 2 verfügbar und die vorhandenen wurden oft von Grund auf neu geschrieben, was bedeutet, dass Konfigurationsdaten und Einstellungen nicht automatisch migriert werden. Für jede Erweiterung müssen Sie prüfen, ob ein Magento 2-Äquivalent vorhanden ist, ob die zugehörigen Daten migrierbar sind und ob das Funktionsverhalten identisch ist. Diese Mapping-Arbeit nimmt Zeit in Anspruch, vermeidet aber unangenehme Überraschungen am Ende des Projekts, wenn das Budget aufgebraucht ist und die Online-Veröffentlichung naht. Ein schlecht migriertes Retourenmanagement- oder Treueprogrammmodul kann am Tag der Einführung ganze Geschäftsprozesse zum Stillstand bringen.
SEO-Traffic gesunken
Fehlgeschlagene SEO-Migration