Migration von Magento Open Source zu Adobe Commerce: Abnahme und Portabilität
Der Shop wurde migriert, der Katalog lässt sich öffnen — doch ein Händler sieht den Endkundenpreis, und eine wiederholte Anfrage erzeugt einen zusätzlichen Auftrag im Warenwirtschaftssystem. Genau deshalb sollte eine Migration zu Adobe Commerce von Magento Open Source nicht mit einer Vorführung der neuen Cloud enden, sondern mit der Prüfung der Handelsabläufe. Vereinbaren Sie vor Beginn der Arbeiten, wer die Richtigkeit von Preisen, Zahlungen, Beständen und Kaufhistorie bestätigt und wie das Unternehmen seine Daten und seinen Code für einen späteren Wechsel erhält.
Sie benötigen die genaue Bezeichnung des Zielprodukts, fachliche Abnahmeszenarien und eine Generalprobe der Umschaltung. Eine Agenturrangliste ersetzt keines dieser Dokumente.
Klären Sie zuerst, welche Cloud Sie genau abnehmen
Die Bezeichnung Adobe Commerce Cloud ist nicht präzise genug. Adobe Commerce on cloud infrastructure ist Platform as a Service (PaaS), Adobe Commerce as a Cloud Service hingegen Software as a Service (SaaS). Hier betrachten wir Magento Open Source → Adobe Commerce on cloud infrastructure. Für SaaS ist ein anderer Plan erforderlich.
Im offiziellen Modellvergleich von Adobe wird für PaaS eine geteilte Verantwortung beschrieben: Adobe verwaltet die Hostingplattform, während der Händler für Anwendungspatches, eigenen Code, Konfiguration und unterstützte Abhängigkeiten verantwortlich ist. Bei SaaS verwaltet Adobe den Kern und dessen Updates; der Kerncode darf nicht verändert werden, Erweiterungen werden über unterstützte Schnittstellen und Dienste entwickelt. Ein bestehendes PHP-Modul sollte daher nicht automatisch als für beide Modelle geeignet gelten.
| Abnahmekriterium | Ziel: on cloud infrastructure | Wenn Cloud Service angeboten wird |
|---|---|---|
| Eigene Anpassungen | Kompatibilität von Code, Modulen und Theme mit der Zielversion prüfen | Den Umbau der Anpassungen für das unterstützte Erweiterungsmodell vereinbaren |
| Updates | Eine verantwortliche Person für Anwendungspatches und Abhängigkeiten benennen | Von Adobe verwaltete Kernupdates und die Prüfung eigener Integrationen berücksichtigen |
| Übergabe der Lösung | Repository, Bereitstellungskonfiguration und wiederherstellbare Daten erhalten | Die Übergabe von Anwendungen, Konfiguration und verfügbaren Exporten gesondert beschreiben |
| Nachweis der Betriebsbereitschaft | Durchgängige Tests der Handelsabläufe in der Zielumgebung bestehen | Von der Architekturänderung betroffene Szenarien erneut bestätigen |
Halten Sie Produkt, Modell, zutreffende Versionen und erworbene Funktionen fest: Lizenzen und B2B-Erweiterungen sind gesondert zu bestätigen. Wenn lediglich zuverlässigeres Hosting benötigt wird, prüfen Sie Verbesserungen an der bestehenden Magento-Open-Source-Lösung.
Machen Sie aus dem Versprechen „Alles funktioniert“ fachliche Abnahmekriterien
Fachliche Abnahmekriterien beschreiben das erwartete Ergebnis anhand konkreter Abläufe. Geben Sie für jede kritische Aktion die Ausgangsdaten, Schritte, den erwarteten Zustand im Shop und im angebundenen System, die verantwortliche Person und den Nachweis an. Ein Video eines erfolgreichen Bestellabschlusses reicht nicht aus, wenn es nicht zeigt, was beim Zahlungsdienst, in der Buchhaltung und im Lager angekommen ist.
Prüfen Sie Regeln, nicht nur Seiten
Beim Katalog sind die Beziehungen zwischen Produktvarianten, Verkaufseinheiten und Kundengruppen wichtig. Beim Preis geht es um Währung, Steuer, Rundung, Rabatt und individuelle Konditionen. Bei der Bestellung geht es um Positionen, Betrag, Zahlung, Reservierung und Bearbeitungsstatus. Ergänzen Sie jedes positive Szenario um einen Fehlerfall: einen nicht verfügbaren Artikel, ein abgelaufenes Angebot, einen Zahlungsfehler oder ein nicht erreichbares Warenwirtschaftssystem.
Ordnen Sie Fehler nach ihren Folgen ein. Ein falsch abgebuchter Betrag, der individuelle Preis eines anderen Kunden oder eine doppelte Bestellung müssen den Start verhindern. Ein unkritischer Darstellungsfehler kann in eine vereinbarte Liste nachgelagerter Anpassungen aufgenommen werden, sofern er den Kauf nicht blockiert. Diese Unterscheidung wird vor den Tests getroffen, nicht am letzten Abend vor der Umschaltung.
Benennen Sie für jede Bestätigung eine verantwortliche Person
Der Vertrieb prüft die kaufmännischen Regeln, das Finanzteam Beträge und Erstattungen, das Lager Reservierungen und Auslieferungen. Das technische Team bestätigt, dass Störungen reproduziert und behoben werden können. Das Protokoll muss Ergebnisse und noch bestehende Einschränkungen enthalten, nicht ein kollektives „Keine Einwände“.
Trennen Sie Datenübernahme, Editionswechsel und Modulkompatibilität
Erstellen Sie ein Modulverzeichnis: Welche geschäftliche Aktion unterstützt jedes Modul, wo speichert es Daten, wird es unterstützt und was passiert nach seiner Deaktivierung? Prüfen Sie besonders Preise, Bestellabschluss, Versand und Datenaustausch mit dem ERP — dem System zur Planung und Erfassung der Unternehmensressourcen.
Der Datenabgleich beschränkt sich nicht auf die Gesamtzahl der Datensätze. Eine identische Produktanzahl beweist nicht, dass Varianten, Attribute und Fotozuordnungen erhalten geblieben sind. Prüfen Sie Kundengruppen, Adressen, historische Bestellungen, Rückgabebelege und interne Integrationskennungen gesondert. Vereinbaren Sie für nicht übernommene Daten, wie sie im Archiv gefunden werden können und wer für den Zugriff verantwortlich ist.
Die Update-Empfehlungen von Adobe sehen die Prüfung von Themes, Erweiterungen und Abhängigkeiten sowie eine Benutzerabnahme vor. Eine automatische Kompatibilitätsanalyse prüft keine Vereinbarungen mit Händlern: Dafür sind konkrete Testbestellungen erforderlich.
Nehmen Sie kein optionales Redesign und keinen Austausch des Warenwirtschaftssystems hinzu: Das erschwert die Suche nach Fehlerursachen. Übergreifende Abhängigkeiten gehören in einen Plan zur Vorbereitung der Infrastruktur auf die Cloud-Migration.
Hypothetisches Beispiel: Die Auftragsbestätigung geht zwischen Shop und ERP verloren
Betrachten wir einen hypothetischen Ersatzteilshop mit individuellen Händlerpreisen. Ein Käufer bestellt zwei Packungen eines Artikels, während das Warenwirtschaftssystem ihn in Stück führt. Die Integration übermittelt die vereinbarte Menge, das ERP legt einen Auftrag an, doch die Antwort erreicht den Shop nicht. Dies ist ein Übungsszenario für die Abnahme, keine Beschreibung eines Kunden oder Ergebnisses von GL.ua.
Ein einfaches Wiederholen der Anfrage kann einen zweiten Beleg erzeugen. Das vereinbarte Ergebnis sieht anders aus: Die Integration verwendet eine beständige Vorgangskennung, ermittelt den Status der ersten Anfrage und verknüpft die Website mit dem bereits erstellten Beleg. Dieses Verhalten entsteht nicht allein durch den Umzug in die Cloud: Es muss implementiert oder im bestehenden Datenaustausch bestätigt werden. Unterstützt das ERP die erforderliche Prüfung nicht, muss das Team einen anderen Mechanismus zum Schutz vor Duplikaten vereinbaren.
Halten Sie im Test die Bestellkennung, den Händlerpreis, die Umrechnung von Packungen in Stück und den Reservierungsstatus fest. Unterbrechen Sie gezielt die Antwort und wiederholen Sie die Aktion. Die Abnahme ist bestanden, wenn kein zusätzlicher Beleg und keine zusätzliche Reservierung vorliegen, die Beträge übereinstimmen, der Käufer einen verständlichen Status erhalten hat und die zuständige Person erkennt, wie sie die Bearbeitung fortsetzen kann. Prüfen Sie auch die Stornierung: Sie darf keine versteckte Bestandsbindung im Lager hinterlassen.
Prüfen Sie außerdem eine verspätete Zahlungsbenachrichtigung: Wer ändert den Bestellstatus auf Grundlage welcher Bestätigung? Eine „Vielen Dank“-Seite beweist nicht, dass die gesamte Prozesskette abgeschlossen ist.
Proben Sie die Umschaltung mit festgelegten Abbruchbedingungen
Die Generalprobe überprüft Reihenfolge und Dauer der Arbeiten anhand Ihrer Daten. Die Adobe-Anleitung zur Bereitstellung in Staging und Production sieht Tests vor dem Produktivbetrieb vor. Die Testumgebung darf kein echtes Geld abbuchen und keine Übungsnachrichten an Kunden senden.
- Halten Sie den Zustand des Quellsystems fest: Codeversion, Konfiguration, einen Referenzbestand an Datensätzen und die Liste aktiver Datenaustauschprozesse.
- Führen Sie eine Probemigration durch und gleichen Sie nicht nur Datensätze ab, sondern auch den vollständigen Bestellablauf, Fehlerfall, Rückgabe und wiederholte Anfrage.
- Prüfen Sie die abschließende Datenaktualisierung: Welche Änderungen sind seit dem Probeimport hinzugekommen, und wie gelangen sie ins Zielsystem?
- Vereinbaren Sie den Zeitpunkt für den Schreibstopp und die Umschaltung der Integrationen, damit alter und neuer Shop nicht gleichzeitig unvereinbare Änderungen annehmen.
- Spielen Sie eine kritische Störung und die Rollback-Entscheidung durch: Wer trifft sie, was wird wiederhergestellt und wie werden neue Transaktionen abgeglichen?
- Prüfen Sie nach der testweisen Öffnung Kontrollkäufe, Austauschprotokolle, Hintergrundaufgaben und die für den Bereitschaftsdienst verantwortlichen Personen.
Legen Sie für den Rollback den Grenzzeitpunkt fest, ab dem die bloße Wiederherstellung der alten Datenbank nicht mehr ausreicht. Hat der neue Shop bereits eine Zahlung angenommen, storniert die Wiederherstellung einer alten Kopie diese Zahlung nicht automatisch. Dafür ist ein Verfahren zum Abgleich solcher Vorgänge erforderlich. Dies ist einer der Gründe, das Versprechen „Rollback auf Knopfdruck“ nicht ohne Generalprobe zu akzeptieren.
Eine gesonderte SEO-Prüfung umfasst URLs, Weiterleitungen, Canonical-Tags und Indexierung. Der Plan für eine Website-Migration mit Erhalt der SEO enthält eine umfassendere Liste; benennen Sie eine verantwortliche Person für deren Prüfung.
Belegen Sie Portabilität durch Wiederherstellung, nicht durch die Übergabe eines Archivs
Portabilität eines Onlineshops bedeutet, die erforderlichen Daten und das benötigte Verhalten unter Berücksichtigung der Lizenzen in einer vereinbarten anderen Umgebung reproduzieren zu können. Sie bedeutet nicht, dass lizenzierte Funktionen von Adobe Commerce kostenlos in Magento Open Source oder einem anderen CMS betrieben werden dürfen. Plant das Unternehmen einen Ausstieg, benötigt jede solche Funktion einen Ersatz oder eine gesonderte Lösung.
Nehmen Sie in das Übergabepaket das Repository mit Änderungshistorie, eine Liste der Abhängigkeiten und Nutzungsrechte, die Bereitstellungskonfiguration, eine Beschreibung der Integrationen, das Schema eigener Tabellen und ein Verfahren für den Datenexport auf. Zugangsdaten werden über einen vereinbarten sicheren Kanal übertragen, nicht in der Dokumentation festgehalten. Der Unternehmensinhaber muss die Organisationskonten, die Domain und das Recht kontrollieren, einen anderen Dienstleister zu beauftragen.
Laut Adobes Dokumentation zu Sicherungskopien enthält ein Snapshot keinen Code, und eine Kopie davon kann nicht heruntergeladen werden. Das ist kein fertiges Ausstiegspaket. Prüfen Sie den Export von Datenbank, Mediendateien und Code sowie deren Wiederherstellung gesondert entsprechend Ihrem Plan und Umgebungstyp.
Lassen Sie eine andere autorisierte Fachkraft ohne Hinweise des Erstellers die Testumgebung reproduzieren und die benötigte Bestellung finden. Fehler aus dieser Übung werden zu konkreten Übergabepunkten.
Schätzen Sie Zeitplan und Budget anhand ungeklärter Abhängigkeiten
Die Dauer hängt von der Verfügbarkeit des Quellcodes, dem Zustand der Module, Datenmenge und -qualität, der Komplexität der Integrationen und der Beteiligung der Fachabteilungen an den Tests ab. Planen Sie Bestandsaufnahme, Anpassung, Probemigration, Korrekturen, erneute Generalprobe und Start getrennt. Der Umschalttermin wird nach einem zeitlich gemessenen Probelauf präzisiert, nicht allein anhand der Produktanzahl im Katalog.
Trennen Sie bei den Kosten Lizenzen und Clouddienste, Audit und Konzeption, Modulanpassung, Datenbereinigung und -übernahme, Integrationen, SEO-Prüfung, Testumgebungen, fachliche Abnahme, Start und Support. Der Parallelbetrieb und die Vorbereitung des Ausstiegspakets müssen eigene Positionen sein. So wird sichtbar, welche Kosten nach dem Start entfallen und welche zu laufenden Ausgaben werden.
Bezahlen Sie nicht für die Übernahme unnötiger Funktionen. Wenn die Vorteile der Zieledition nicht mit einem benötigten Geschäftsszenario zusammenhängen, verschieben Sie den Wechsel.
Die Startentscheidung muss auf Nachweisen beruhen
Öffnen Sie den Shop, nachdem die Szenarien bestanden, kritische Fehler behoben und das Übergabepaket geprüft wurden. Der Wiederherstellungsplan muss neue Transaktionen berücksichtigen. Das ist ein kontrollierter Wechsel, keine Garantie für einen störungsfreien Betrieb.
Ziehen Sie eine andere Architektur in Betracht? Übermitteln Sie GL.ua (Глянець) Ihre Handelsregeln, Integrationen und Anforderungen an die Portabilität. Besprechen Sie im Rahmen der Entwicklung von Websites und Onlineshops mit Drupal die Alternative und den Arbeitsumfang, bevor Sie einen Migrationsvertrag abschließen.
Nur ein Schritt zu Ihrer perfekten Website



