Magento-Ablösung planen: Hyvä, Shopware oder Shopify – der richtige Weg für Ihr System

Ihr Magento-Shop läuft, aber jede Änderung dauert länger als früher, Schnittstellen brechen bei Updates und nur noch eine Person im Team versteht wirklich, warum bestimmte Module so gebaut sind, wie sie gebaut sind. Wer eine Magento-Ablösung planen muss, steht vor einer Entscheidung mit hoher Tragweite – und vor der Frage, ob tatsächlich das ganze System ausgetauscht werden muss oder ob ein gezielter Eingriff reicht. Dieser Artikel liefert IT-Leitern ein sachliches Raster, um technische Schulden im eigenen System zu bewerten und daraus eine begründete Entscheidung abzuleiten.

Magento-Ablösung planen: Woran Sie technische Schulden erkennen

Technische Schulden sind der Rückstand, der entsteht, wenn Systeme über Jahre gewachsen sind, ohne dass Architektur und Dokumentation mitgewachsen sind. Jede schnelle Lösung, die damals funktioniert hat, zahlt sich heute als Mehraufwand zurück. Bei Magento-Systemen zeigen sich technische Schulden meist an vier Stellen.

Fragile Schnittstellen. Wenn die Anbindung an Ihr Warenwirtschaftssystem (ERP) bei jedem Magento-Update manuell nachgezogen werden muss oder Bestelldaten gelegentlich nicht ankommen, ist das kein Zufall, sondern ein Architekturproblem. Schnittstellen, die über direkte Datenbankzugriffe statt über definierte APIs laufen, sind besonders anfällig – sie brechen bei Versionswechseln, ohne dass vorher ein Test anschlägt.

Abhängigkeit von Einzelpersonen. Ein klassisches Warnsignal: Nur ein interner Entwickler oder ein externer Freelancer kennt die individuellen Erweiterungen im System. Fällt diese Person aus oder verlässt das Unternehmen, steht das Projekt. In unseren Projekten begegnet uns dieses Muster regelmäßig bei gewachsenen Magento-1- und frühen Magento-2-Installationen, die über Jahre von wechselnden Dienstleistern erweitert wurden.

Veraltete Codebasis. Individuelle Module, die gegen längst abgelöste Magento-Versionen programmiert wurden, lassen sich oft nicht einfach aktualisieren. Jedes Update wird zum Risiko, weil niemand mit Sicherheit sagen kann, welche Abhängigkeiten brechen.

Sicherheitslücken bei fehlendem Support. Für ältere Magento-Versionen stellt Adobe den offiziellen Support irgendwann ein – dann gibt es keine Sicherheitspatches mehr. Ein System ohne Patches ist nicht sofort unsicher, aber jede neu entdeckte Lücke bleibt dauerhaft offen. Das ist der Kern des Themas Magento End of Life: Es geht nicht um ein plötzliches Abschalten, sondern um einen wachsenden, unsichtbaren Risikoberg.

Drei Wege aus der Magento-Falle: Hyvä, Shopware oder Shopify im Überblick

Bevor Sie Vor- und Nachteile abwägen, lohnt sich eine saubere Einordnung der drei Optionen – denn sie liegen auf unterschiedlichen Ebenen.

Hyvä ist keine eigene Plattform, sondern eine Frontend-Technologie für Magento 2. Sie ersetzt das Standard-Theme und die Template-Engine, lässt Backend, Datenbank und Schnittstellen aber unverändert. Shopware und Shopify dagegen sind vollständige Plattformwechsel: Das gesamte System – Backend, Datenmodell, Schnittstellen, Hosting – wird ersetzt. Shopware ist ein deutsches System mit hoher Flexibilität für individuelle Anforderungen und B2B-Prozesse, oft als Composable-Commerce-Ansatz betrieben, bei dem einzelne Komponenten frei kombiniert werden. Shopify ist eine Software-as-a-Service-Lösung (SaaS) mit geringerem Individualisierungsaufwand, aber auch weniger Eingriffsmöglichkeiten in die Architektur.

Die Konsequenz: Hyvä behebt ein Performance- und Wartbarkeitsproblem im Frontend. Shopware oder Shopify beheben ein strukturelles Problem im Backend. Wer beides durcheinanderwirft, trifft die falsche Entscheidung – deshalb braucht jede Magento-Ablösung zuerst eine klare Diagnose, wo das eigentliche Risiko sitzt.

Hyvä-Migration: Modernisierung ohne das Backend anzufassen

Eine Hyvä-Migration ersetzt das träge Standard-Frontend von Magento 2 durch ein schlankes, auf Tailwind CSS und Alpine.js basierendes Theme-Framework. Der Effekt ist in der Regel spürbar: weniger JavaScript, weniger CSS-Overhead, kürzere Ladezeiten. Für IT-Leiter ist entscheidend, dass Backend, Datenbank, API-Struktur und bestehende ERP-Anbindung unangetastet bleiben – es handelt sich um einen Austausch der Präsentationsschicht, nicht um einen Systemwechsel.

Das macht Hyvä zur richtigen Wahl, wenn Ihr Kernproblem die Performance ist: schlechte Werte bei Ladezeit (LCP-Metrik) oder Interaktionsverzögerung, ein Frontend, das auf mobilen Geräten lahmt, oder ein veraltetes Theme, das kaum noch wartbar ist. Die Grenzen sind ebenso klar: Hyvä löst keine fragilen Schnittstellen, keine veraltete Codebasis im Backend und kein EOL-Risiko. Wenn das eigentliche Problem im Datenmodell oder in der Schnittstellen-Architektur liegt, bringt die schönste Oberfläche keine strukturelle Entlastung.

Wer prüfen möchte, ob eine Hyvä-Migration im eigenen System sinnvoll ist, bekommt im Hyvä-Migration-Workshop eine technische Einschätzung, die konkret auf die vorhandene Magento-Installation eingeht, statt pauschal zu empfehlen.

Wann sich ein struktureller Umstieg auf Shopware oder Shopify lohnt

Ein Frontend-Fix reicht nicht mehr, wenn das Backend selbst zum Risiko geworden ist. Das ist typischerweise dann der Fall, wenn mehrere der folgenden Punkte zutreffen:

Die Magento-Version befindet sich außerhalb des Herstellersupports, und Sicherheitsupdates sind nicht mehr verfügbar. Die Schnittstellen zu ERP, PIM oder Versanddienstleistern wurden über Jahre individuell zusammengeflickt und sind bei jedem Update ein Risiko. Es gibt kaum noch internes oder externes Know-how für die spezifische Magento-Version im Team. Neue Anforderungen – etwa B2B-Preislogiken, Mehrmandantenfähigkeit oder internationale Expansion – lassen sich im bestehenden System nur mit unverhältnismäßigem Aufwand umsetzen.

In diesen Fällen spricht man von Replatforming: dem strukturierten Wechsel auf eine neue technologische Basis, bei dem Daten, Schnittstellen und Prozesse neu aufgesetzt statt nur optisch modernisiert werden. Die Wahl zwischen Magento-zu-Shopware-Migration und Magento-Shopify-Umstieg hängt stark vom Individualisierungsbedarf ab: Shopware passt gut, wenn Sie komplexe B2B-Logiken, individuelle ERP-Integrationen oder viel Eigenentwicklung brauchen. Shopify eignet sich, wenn Standardprozesse überwiegen und der Betriebsaufwand möglichst gering bleiben soll, weil Hosting und Infrastruktur im SaaS-Modell mitgeliefert werden.

Entscheidungskriterien: Welcher Weg passt zu Ihrem System

Statt einer Bauchentscheidung empfiehlt sich eine strukturierte Prüfung anhand von vier Kriterien, die Sie in Ihrem System konkret nachvollziehen können.

Alter und Zustand der Codebasis. Prüfen Sie, auf welcher Magento-2-Version Sie laufen und wie viele individuelle Erweiterungen eingebaut sind. Eine aktuelle Version mit wenigen, sauber dokumentierten Modulen spricht für Hyvä. Eine Version kurz vor oder nach Support-Ende mit zahlreichen undokumentierten Anpassungen spricht für einen Plattformwechsel.

Anzahl und Zustand der Schnittstellen. Zählen Sie die aktiven Integrationen – ERP, PIM, Payment, Versand, Marketing-Tools. Laufen diese über stabile REST-Schnittstellen (API) oder über direkte, fragile Eingriffe in die Datenbank? Viele fragile Schnittstellen sind ein starkes Argument gegen einen reinen Frontend-Fix.

Team-Know-how. Haben Sie intern noch Magento-Expertise, oder hängt alles an einem externen Dienstleister? Sinkendes Know-how im Markt für ältere Magento-Versionen erhöht das Risiko, selbst wenn das System heute noch läuft.

Zeitdruck durch EOL. Wie viel Zeit bleibt realistisch, bis Sicherheitsupdates ganz ausbleiben? Je näher dieser Punkt rückt, desto eher lohnt sich eine Entscheidung für den strukturellen Weg, da eine Hyvä-Migration das zugrunde liegende Supportproblem nicht löst.

Treffen bei Ihnen vor allem Punkt eins und zwei zu, während Team und Zeitdruck unkritisch sind, ist Hyvä oft die wirtschaftlichere Zwischenlösung. Kommen Schnittstellenprobleme, sinkendes Know-how und EOL-Druck zusammen, ist ein strukturierter Umstieg meist die nachhaltigere Entscheidung.

So gehen wir eine Magento-Ablösung in der Praxis an

Ein Big-Bang-Wechsel – alles auf einmal, mit hartem Stichtag – ist der häufigste Fehler bei Plattformwechseln. Er bündelt sämtliche Risiken auf einen einzigen Zeitpunkt und lässt kaum Raum für Korrekturen. In über 40 E-Commerce-Projekten hat sich ein schrittweises Vorgehen bewährt:

Erstens eine technische Bestandsaufnahme: Code-Audit der individuellen Module, Mapping aller Schnittstellen und Bewertung, welche davon stabil über definierte APIs laufen und welche fragil sind. Zweitens eine Risikobewertung anhand der vier genannten Kriterien, die eine klare Empfehlung liefert – Hyvä oder struktureller Umstieg. Drittens, bei Entscheidung für den Plattformwechsel, eine Priorisierung: Welche Funktionen und Schnittstellen sind geschäftskritisch und müssen zuerst sauber abgebildet werden? Viertens eine Pilotphase mit klar abgegrenztem Funktionsumfang, bevor der komplette Shop umgestellt wird.

Wie ein strukturierter Umstieg in der Praxis aussehen kann, zeigt unsere Referenz zur Shop-Migration bei eReTail Store. Wer sich grundsätzlich noch unsicher ist, welches System überhaupt zum eigenen Geschäftsmodell passt, findet eine vertiefende Einordnung im Beitrag zur agnostischen Systemempfehlung für Onlineshops.