Magento-Entwicklung
Ob eine Magento-Erweiterung gut gebaut ist, zeigt sich selten am Tag der Abnahme, sondern beim nächsten Update. Die Sharpness Solutions GmbH aus Oldenburg entwickelt für Magento Open Source: eigene Module über Plugins, Observer und Dependency Injection statt Eingriffen in den Core, Schnittstellen zu ERP, PIM und Versand, B2B-Funktionen wie Kundenpreise und Bestellfreigaben, Themes und Performance-Arbeit. Bestehenden Code und fremde Extensions übernehmen wir ebenfalls, prüfen sie und machen sie update-fest. Diese Seite erklärt, wie ein Magento-Modul gebaut sein sollte, was Open Source von Haus aus mitbringt und was nicht, und woran Sie eine Umsetzung erkennen, die auch in drei Jahren noch wartbar ist. Wo bereits eine Adobe-Commerce-Lizenz besteht, arbeiten wir auch damit.
Manche Projekte beginnen neu, die meisten mit einem Shop, der seit Jahren verkauft: Module aus mehreren Händen, eine Warenwirtschaft dahinter, eine Liste von Wünschen aus Vertrieb und Einkauf. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam haben sie eins: Was beim Bau gespart wurde, kommt beim Update zurück.
Eine Datei in vendor/ wurde direkt bearbeitet, eine Core-Klasse kopiert und angepasst. Das funktioniert, bis Composer beim nächsten Update die Originaldatei zurückschreibt. Dann ist die Änderung entweder still verschwunden, oder das Update bricht ab — beides fällt meist erst im Live-Shop auf.
Module aus dem Marketplace, von früheren Dienstleistern, aus kopierten Codebeispielen. Mehrere Plugins hängen an derselben Methode, zwei Extensions ersetzen per preference dieselbe Klasse. Jedes Modul für sich läuft. Zusammen entscheidet die Ladereihenfolge, welches gewinnt.
Mit 2.4.9 hat Adobe Zend_Cache durch symfony/cache und Laminas MVC durch eine eigene MVC-Implementierung ersetzt; freigegeben ist nur noch PHP 8.5. Extensions, die auf diesen Bausteinen aufsetzen, müssen angepasst werden. Wer das erst im Update-Fenster merkt, verschiebt das Update.
Ein Import-Skript läuft nachts per Cron, schreibt kein Protokoll und bricht beim ersten fehlerhaften Datensatz ab. Am nächsten Morgen stimmen Preise oder Bestände nicht, und niemand weiß, seit wann. Eine Schnittstelle ohne Protokoll ist eine Vermutung.
Kundenpreise, Firmenkonten mit mehreren Bestellern, Freigaben vor der Bestellung. Das B2B-Modul von Adobe gehört zu Adobe Commerce und braucht eine eigene Lizenz. In Magento Open Source entstehen diese Funktionen als eigene Module — und gehören deshalb von Anfang an in den Umfang.
Mehr Artikel, mehr Varianten, mehr Store Views. Indexer laufen hinterher, Message-Queue-Consumer stehen still, der HTTP-Cache liefert kaum Treffer, weil ein Modul jede Seite als nicht cachebar markiert. Mehr Server lösen davon nichts. Eine Maßnahme lohnt sich erst, wenn klar ist, wo die Zeit verloren geht.
Magento ist modular aufgebaut, und eigene Funktionen gehören in eigene Module, nicht in den Core. Für Eingriffe in bestehendes Verhalten gibt es zwei vorgesehene Wege. Plugins, auch Interceptors genannt, ändern öffentliche Methoden vor, nach oder um ihren Aufruf herum — before, after, around — und werden in der di.xml deklariert; die Interceptor-Klassen erzeugt Magento selbst. Observer reagieren auf Events, die Magento oder ein anderes Modul auslöst, und werden in der events.xml zugeordnet, global oder je Bereich wie Storefront oder Admin. Wir wählen den Weg, der am wenigsten berührt: lieber ein after-Plugin als ein around-Plugin, lieber ein Observer, wenn ein passendes Event existiert. Je kleiner der Eingriff, desto kleiner die Prüfung beim nächsten Update.
Abhängigkeiten bekommt ein Modul über Dependency Injection: Der Object Manager setzt ein, was in der di.xml konfiguriert ist. Den Object Manager selbst injizieren wir nicht, auch wenn das in gewachsenem Code oft zu finden ist — es versteckt Abhängigkeiten und erschwert Tests. Eine preference, also eine eigene Standardimplementierung für ein Interface oder eine Klasse, setzen wir nur dort ein, wo kein Plugin reicht. Sie ersetzt das Original vollständig, und von mehreren preferences auf dieselbe Klasse gewinnt nur eine. Nach außen spricht ein gutes Modul über Service Contracts: PHP-Interfaces, getrennt in Data Interfaces für die Datenstrukturen und Service Interfaces für die Operationen. Andere Module, Schnittstellen und spätere Erweiterungen hängen dann an einem Vertrag, nicht an einer Implementierung.
Tabellen und Spalten beschreibt ein Modul über Declarative Schema statt über die alten Upgrade-Skripte. Inhalte, die mit dem Modul kommen — Attribute, Konfiguration, Stammdaten —, legen Data Patches an, Änderungen, die sich nicht deklarativ ausdrücken lassen, Schema Patches; beide lassen sich bei Bedarf revertierbar bauen. Jedes Modul prüfen wir gegen den Magento Coding Standard, einen Regelsatz für PHP_CodeSniffer. Ausgerollt wird über Composer und Git, mit bin/magento setup:upgrade, setup:di:compile und setup:static-content:deploy im Produktionsmodus, nie per Upload von Hand. Der Code liegt in einem Git-Repository, das Ihnen gehört, und jede Änderung ist nachvollziehbar. Fertig ist ein Modul erst, wenn ein anderer Entwickler es ohne Rückfrage lesen kann.
Die meisten Magento-Shops, die zu uns kommen, haben eine Geschichte: Extensions aus dem Adobe Commerce Marketplace, kostenlos oder gekauft, Module früherer Dienstleister, kleine Anpassungen direkt im Code. Am Anfang steht deshalb eine Bestandsaufnahme jedes Moduls. Woher kommt es, pflegt es noch jemand, und auf welche Magento- und PHP-Versionen ist es ausgelegt? Welche Plugins, Observer und preferences bringt es mit, welche Klassen ersetzt es, wo kollidiert es mit anderen Modulen? Gibt es Änderungen in vendor/ oder kopierte Core-Dateien? Dazu läuft der Coding Standard über den eigenen Code, und setup:di:compile zeigt, ob sich das Ganze sauber kompilieren lässt. Das Ergebnis ist eine Liste, keine Meinung.
Für jedes Modul fällt dann eine Entscheidung: behalten, aktualisieren, durch eine gepflegte Alternative ersetzen, als eigenes Modul sauber neu bauen oder entfernen, weil niemand die Funktion mehr nutzt. Core-Änderungen ziehen wir in eigene Module heraus, als Plugin oder Observer, damit Composer bei Updates wieder freie Hand hat. Zur Werkzeugfrage: Das Upgrade Compatibility Tool von Adobe ist laut Hersteller nur für Adobe-Commerce-Instanzen verfügbar. In Magento Open Source prüfen wir deshalb mit Coding Standard, Compiler, vorhandenen Tests und einem Durchlauf auf einem Staging-System mit einer Kopie der Live-Daten. Auch die Zugangsschlüssel des Marketplace sind editionsgebunden; ein Schlüssel für Open Source funktioniert nicht für Adobe Commerce. Die günstigste Update-Prüfung gilt einer Extension, die nicht mehr installiert ist.
Wie viel Arbeit ein Update für Ihre Extensions bedeuten kann, zeigt der Schritt auf 2.4.9. Adobe hat dort Zend_Cache durch symfony/cache ersetzt, Laminas MVC durch eine eigene MVC-Implementierung, die Symfony-Abhängigkeiten auf 7.4 LTS gehoben und im WYSIWYG-Editor TinyMCE durch HugeRTE abgelöst. Extensions, die Zend_Cache nutzen, müssen laut Adobe angepasst werden; wer den Editor erweitert hat, prüft gegen HugeRTE. Freigegeben ist für 2.4.9 nur PHP 8.5. Wir passen eigene und übernommene Module an und klären mit den Herstellern gekaufter Extensions, wann kompatible Versionen kommen. Wie Updates, Sicherheitspatches und Betrieb insgesamt laufen, beschreibt unsere Seite zu Magento Open Source. Hier geht es um den Code, der dabei mitmuss.
Eine Schnittstelle entscheidet sich an der Richtungsfrage: Welches System führt Artikelstamm, Preise, Bestände, Kunden und Bestellungen, und welches liest nur? Ist das je Feld geklärt, ist die Technik Handwerk. Magento bringt dafür die Commerce Web API mit, als REST- und als GraphQL-Schnittstelle, beide auch in Magento Open Source. REST nutzen wir meist für den Datenaustausch zwischen Systemen, GraphQL dort, wo ein Frontend oder eine App gezielt Daten abfragt. Bietet das ERP keine Schnittstelle, sondern exportiert Dateien, liest ein eigenes Modul diese Dateien ein, mit denselben Regeln für Protokoll und Fehlerbehandlung. Welches ERP oder PIM dahintersteht, ist zweitrangig. Der Aufwand steckt im Zustand der Daten, nicht im Protokoll.
Große Datenmengen gehören nicht in einen einzelnen Aufruf, der so lange läuft, bis etwas abbricht. Magento verarbeitet Massenvorgänge über Message Queues: Die REST-Bulk-Endpunkte etwa legen Aufträge in eine Warteschlange, die Consumer abarbeiten, gestartet mit bin/magento queue:consumers:start. Als Broker unterstützt Magento RabbitMQ und ActiveMQ Artemis; für den Dauerbetrieb empfiehlt Adobe in den Release Notes zu 2.4.9 ActiveMQ Artemis. Regelmäßige Abgleiche laufen als geplante Jobs über den Magento-Cron. Jeder Lauf schreibt ein Protokoll, ein fehlerhafter Datensatz landet in einer Fehlerliste, statt den ganzen Abgleich anzuhalten, und ein abgebrochener Lauf lässt sich wiederholen, ohne Daten doppelt anzulegen. Stehen die Consumer still, soll das die Überwachung melden, nicht ein Kunde.
Ein Beispiel aus unserer Arbeit ist der Magento-Shop der Manotura GmbH & Co. KG für Bewässerungstechnik: Beregnungsanlagen, Rohrsysteme und Zubehör, ein Sortiment, das sich nur über technische Merkmale sinnvoll filtern lässt. Artikelstamm, Preise und Bestände kommen aus der Warenwirtschaft, Bestellungen gehen dorthin zurück. Die Übertragungen laufen als geplante Jobs mit Protokollierung und Wiederholungslogik, sodass ein einzelner Fehlschlag nicht den ganzen Abgleich blockiert. Über 12.000 Artikel stehen im synchronisierten Katalog, Preise und Bestände werden stündlich abgeglichen, und der Pflegeaufwand liegt rund 40 Prozent unter dem einer Doppelerfassung. Für den Versand bringt 2.4.9 eine Anbindung an DHL über die MyDHL-REST-API mit; andere Dienstleister binden wir über deren Schnittstellen an. Gepflegt wird an einer Stelle, und der Shop folgt.
Das B2B-Modul von Adobe gehört zu Adobe Commerce und braucht laut Adobe eine eigene Lizenz. Ebenfalls nur in Adobe Commerce enthalten sind unter anderem Customer Segments und Content Staging. Wer Magento Open Source nutzt, baut B2B-Funktionen deshalb als eigene Module — auf einer Grundlage, die Open Source bereits mitbringt: Kundengruppen, Staffelpreise, Katalog- und Warenkorbpreisregeln, mehrere Websites, Shops und Store Views mit eigenen Sprachen und Währungen, dazu das standardmäßig installierte Inventory Management. Das ist mehr, als viele erwarten, und für manchen B2B-Shop schon genug. Der Rest ist Entwicklung, die zu Ihrem Vertrieb passt statt zu einem fertigen Funktionspaket. Wo bereits eine Adobe-Commerce-Lizenz besteht, nutzen wir das B2B-Modul und ergänzen es dort, wo es nicht reicht.
Typische Module, die wir für B2B in Open Source bauen: Preise je Kunde aus dem ERP statt einer eigenen Kundengruppe pro Kunde, Firmenkonten mit mehreren Bestellern und Rollen, Bestellfreigaben ab einem Betrag oder für bestimmte Warengruppen, Budgets je Kostenstelle, Schnellbestellung über Artikelnummer und Menge, Angebotsanfragen aus dem Warenkorb und ein Katalog, der Preise erst nach geprüfter Registrierung zeigt. Bestellen Einkäufer aus einem Beschaffungssystem, kommt ein Punch-out per OCI dazu; der Warenkorb geht dann zurück in das System des Kunden. Jede dieser Funktionen nutzt die vorgesehenen Erweiterungspunkte, also Plugins, Observer und Service Contracts, und bekommt eigene Tabellen über Declarative Schema. Gebaut wird, was Ihr Vertrieb tatsächlich braucht, nicht alles, was ein B2B-Paket enthalten könnte.
Kundenpreise haben eine technische Seite, die oft unterschätzt wird. Ein Preis, der nur für einen Kunden gilt, darf nicht im HTTP-Cache für alle landen, muss beim Indexieren berücksichtigt werden und in Suche, Filtern und Suchvorschlägen genauso gelten wie auf der Produktseite. Bei vielen Kunden und häufigen Preisänderungen ist die Frage, ob Preise vorab berechnet oder beim Aufruf ermittelt werden, eine Architekturentscheidung mit Folgen für Indexer und Ladezeit. Wir treffen sie vor der Entwicklung, anhand Ihrer Zahl an Kunden, Artikeln und Preisänderungen. Wie Sichtbarkeiten und Kundenpreise in der Shopsuche gelten, beschreibt unsere Seite zur Shopsuche mit OpenSearch. Eine langsame Seite verzeiht ein Geschäftskunde eher als einen Preis, der nicht seiner ist.
Ein eigenes Theme erbt von einem bestehenden und überschreibt gezielt Layout-Dateien und Templates, statt sie im Ganzen zu kopieren. Jede überschriebene Datei muss beim Update gegen das neue Original gelesen werden; die Zahl der Eingriffe bestimmt deshalb die Wartungskosten, nicht das Aussehen. Seit dem 10. November 2025 ist das Hyvä Theme kostenlos und quelloffen, unter denselben Lizenzen wie Magento Open Source, OSL-3.0 und AFL-3.0. Kostenpflichtig bleiben Hyvä UI, Hyvä Checkout sowie die Pakete Hyvä Commerce und Hyvä Enterprise. Ob Hyvä für Ihren Shop passt, hängt weniger am Theme als an den Extensions: Jedes Modul, das eigenes Frontend mitbringt, muss mit dem gewählten Theme funktionieren. Das prüfen wir vor der Entscheidung, Modul für Modul.
Performance beginnt mit Messen. Bei langsamen Kategorie- und Produktseiten liegt die Ursache selten an der Hardware, meist an Indexern, Cache und Modulen. Indexer halten berechnete Daten wie Preise, Kategoriezuordnungen und Bestände aktuell; bin/magento indexer:reindex baut sie einmalig neu auf, laufend aktuell bleiben sie nur mit einem funktionierenden Cron. Davor steht Varnish als HTTP-Cache, der fertige Seiten ausliefert, ohne PHP zu starten — solange kein Modul eine Seite unnötig als nicht cachebar markiert. Valkey übernimmt Cache und Sessions, Message-Queue-Consumer arbeiten Hintergrundaufgaben ab. Fällt einer dieser Bausteine aus oder ist er falsch eingestellt, wird der ganze Shop langsam, und das Symptom zeigt selten auf die Ursache.
Wir suchen deshalb zuerst die Stelle, an der die Zeit verloren geht: in der Datenbank, in einem Plugin, das bei jedem Produkt eine externe Abfrage stellt, in einem Template, in einem Indexer, der hinterherläuft, oder in der Suche. Für Suche und Filter mit OpenSearch gibt es eine eigene Seite; hier geht es um den Code. Im Produktionsmodus, gesetzt mit bin/magento deploy:mode:set production, laufen Kompilierung und Static Content Deploy mit; ein Live-Shop im Entwicklermodus verschenkt Zeit bei jedem Aufruf. Den Betrieb der Dienste dahinter — Server, Varnish, Valkey, OpenSearch, Staging — beschreibt unsere Seite zu Magento Open Source. Eine Optimierung, die niemand gemessen hat, ist eine Vermutung mit Rechnung.
Ablauf
Schicken Sie uns ein paar Sätze zum Vorhaben: welches Modul, welche Schnittstelle oder welche B2B-Funktion, welche Magento-Version heute läuft und welche Extensions installiert sind. Sie bekommen eine erste, unverbindliche Einordnung, wie sich das sauber umsetzen lässt und wovon der Aufwand in Ihrem Fall abhängt. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Wir arbeiten bundesweit remote, Termine in Oldenburg und im Nordwesten nach Absprache.
Sie schildern das Vorhaben: neues Modul, Schnittstelle, B2B-Funktion, Übernahme von bestehendem Code oder ein Shop, der langsam geworden ist. Wir sagen, ob und wie sich das in Magento sauber umsetzen lässt — unverbindlich und bevor über ein Angebot gesprochen wird.
Wir sehen in Module, Extensions, Konfiguration und Schnittstellen, lassen Coding Standard und Compiler laufen und suchen Eingriffe in den Core. Ergebnis ist ein schriftlicher Befund mit Risiken, Reihenfolge und Aufwand in Personentagen.
Sie bekommen eine Funktionsliste mit einer Entscheidung je Punkt: Standard, Extension, eigenes Modul oder weglassen. Dazu bei Schnittstellen die Datenhoheit je Feld, der Aufwand in Personentagen je Posten und ein Zeitplan. Klar abgegrenzte Teile bieten wir zum Festpreis an.
Entwickelt wird in eigenen Modulen, versioniert in einem Git-Repository, das Ihnen gehört, und ausgerollt auf ein Staging-System mit einer Kopie der Live-Daten. Sie geben am laufenden System frei, nicht anhand von Screenshots.
Schnittstellen laufen in Probeläufen mit Protokoll und Abgleich gegen das führende System, B2B-Funktionen prüfen wir mit Testkonten je Kundengruppe, Ladezeiten messen wir vor und nach der Änderung. Coding Standard und Kompilierung laufen ohne Fehler durch.
Ausgerollt wird über Composer und bin/magento im vereinbarten Wartungsfenster, mit Backup davor. Danach betreiben und warten wir den Shop auf unseren Servern in Deutschland, auf Wunsch mit Service-Level-Vereinbarung, und entwickeln ihn weiter.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Das hängt am Umfang des Moduls und am Code, in den es sich einfügen muss, deshalb gibt es bei uns keine Paketpreise. Ein Modul, das eine Funktion an einer klar definierten Stelle ergänzt, ist eine andere Größenordnung als eine ERP-Anbindung mit Massendaten oder ein B2B-Modul mit Freigaben und Kundenpreisen. Kalkuliert wird in Personentagen, mit getrennten Posten für Konzept, Entwicklung, Test und Deployment. Bei bestehenden Shops steht eine Code-Bestandsaufnahme davor, weil fremde Extensions und Core-Eingriffe den Aufwand oft stärker bestimmen als die neue Funktion. Einen Preis nennen wir nach Befund oder Konzept, den Stundensatz auf Anfrage.
Weil eine Änderung am Core beim nächsten Update verloren geht oder das Update blockiert. Composer installiert Magento und seine Pakete in den vendor-Ordner und schreibt die Originaldateien bei einem Update neu; eine dort geänderte Zeile ist dann still verschwunden. Magento sieht für Eingriffe eigene Wege vor: Plugins vor, nach oder um öffentliche Methoden, Observer auf Events und, wo nötig, eine preference über die di.xml. Diese Eingriffe liegen in eigenen Modulen, sind nachvollziehbar und lassen sich beim Update gezielt prüfen. Ein Core-Eingriff spart beim Bau Stunden und kostet sie bei jedem Update wieder.
Ja, das ist der häufigste Fall. Am Anfang steht eine Bestandsaufnahme jedes Moduls: Herkunft, Pflegestand, Plugins und preferences, Kollisionen mit anderen Modulen, Eingriffe in den Core. Coding Standard und Compiler laufen über den Code, und auf einem Staging-System mit Ihren Daten sehen wir, was tatsächlich passiert. Danach entscheiden wir je Modul, ob es bleibt, aktualisiert, ersetzt, neu gebaut oder entfernt wird. Zugänge zu Repository, Servern und Marketplace-Konto klären wir vorher, nicht im Störfall. Was wir finden, steht in einem schriftlichen Befund — auch das, was gut gelöst ist.
Das lässt sich nur je Extension beantworten, aber 2.4.9 bringt Änderungen, die viele Module betreffen. Adobe hat Zend_Cache durch symfony/cache und Laminas MVC durch eine eigene MVC-Implementierung ersetzt, die Symfony-Abhängigkeiten auf 7.4 LTS gehoben und TinyMCE durch HugeRTE abgelöst; freigegeben ist PHP 8.5. Extensions, die Zend_Cache nutzen, müssen laut Adobe angepasst werden. Wir prüfen jede Extension auf einem Staging-System mit 2.4.9, passen eigene und übernommene Module an und klären bei gekauften Extensions, ob der Hersteller eine kompatible Version liefert. Den Ablauf des Updates selbst beschreibt unsere Seite zu Magento Open Source.
Nein, laut Adobe ist das Upgrade Compatibility Tool nur für Adobe-Commerce-Instanzen verfügbar. In Magento Open Source prüfen wir deshalb auf anderen Wegen: mit dem Magento Coding Standard über PHP_CodeSniffer, mit bin/magento setup:di:compile, das Fehler in Abhängigkeiten und generiertem Code früh sichtbar macht, mit vorhandenen Tests und mit einem vollständigen Durchlauf auf einem Staging-System mit einer Kopie der Live-Daten. Dazu lesen wir die Liste der rückwärts inkompatiblen Änderungen, die Adobe veröffentlicht, gegen den eigenen Code. Das ist mehr Handarbeit, aber nicht weniger gründlich.
Nein, B2B-Shops lassen sich auch mit Magento Open Source bauen; nur das fertige B2B-Modul gehört zu Adobe Commerce und braucht eine eigene Lizenz. Open Source bringt Kundengruppen, Staffelpreise, Katalog- und Warenkorbpreisregeln sowie mehrere Shops, Sprachen und Währungen mit. Was darüber hinausgeht — Preise je Kunde aus dem ERP, Firmenkonten, Freigaben, Schnellbestellung, Punch-out —, entsteht als eigenes Modul, zugeschnitten auf Ihre Abläufe. Ob das günstiger ist als eine Lizenz, rechnen wir über die Laufzeit gegeneinander. Wo bereits eine Adobe-Commerce-Lizenz besteht, nutzen wir das B2B-Modul und ergänzen es, wo es nicht reicht.
Über die Web API von Magento, REST oder GraphQL, und für Massendaten über Message Queues — nachdem geklärt ist, welches System welche Daten führt. Regelmäßige Abgleiche laufen als geplante Jobs: Jeder Lauf schreibt ein Protokoll, fehlerhafte Datensätze landen in einer Fehlerliste, und ein abgebrochener Lauf lässt sich wiederholen, ohne Daten doppelt anzulegen. Exportiert das ERP nur Dateien, liest ein eigenes Modul sie nach denselben Regeln ein. Bei Manotura kommen so über 12.000 Artikel mit stündlich abgeglichenen Preisen und Beständen aus der Warenwirtschaft, Bestellungen gehen zurück. Welches ERP dahintersteht, ist zweitrangig; entscheidend ist der Zustand der Daten.
REST nutzen wir meist für den Austausch zwischen Systemen, GraphQL vor allem dort, wo ein Frontend oder eine App gezielt Daten abfragt. Beide gehören zur Commerce Web API und stehen in Magento Open Source zur Verfügung. REST bietet für Massenvorgänge Bulk-Endpunkte, die Aufträge über eine Message Queue abarbeiten; das passt zu ERP- und PIM-Abgleichen. GraphQL liefert genau die Felder, die eine Seite braucht, und setzt seit 2.4.9 Grenzen für Aliase und die Länge einer Abfrage. Eigene Endpunkte bauen wir auf Service Contracts auf, damit dieselbe Logik über beide Wege erreichbar bleibt und nicht zweimal geschrieben wird.
Das hängt vor allem an Ihren Extensions, weniger am Theme. Das Hyvä Theme ist seit dem 10. November 2025 kostenlos und quelloffen, unter OSL-3.0 und AFL-3.0; Lizenzkosten für das Theme selbst sind damit kein Argument mehr. Kostenpflichtig bleiben Hyvä UI, Hyvä Checkout und die Pakete Hyvä Commerce und Hyvä Enterprise. Jedes Modul, das eigenes Frontend mitbringt, muss mit dem Theme funktionieren, sonst wird es angepasst oder ersetzt. Wir prüfen das Modul für Modul, bevor Sie sich entscheiden, und nennen den Aufwand in Personentagen. Ein Theme-Wechsel ist ein Projekt, kein Schalter.
Meist wegen Indexern, Cache oder einzelner Module, selten wegen zu kleiner Server. Indexer bleiben nur mit funktionierendem Cron aktuell, Varnish hilft nur, wenn Seiten cachebar sind, und Message-Queue-Consumer müssen laufen, sonst stauen sich Hintergrundaufgaben. Dazu kommen Plugins, die bei jedem Seitenaufruf externe Abfragen stellen, Templates mit teuren Schleifen und Shops, die im Entwicklermodus statt im Produktionsmodus laufen. Wir messen zuerst, wo die Zeit verloren geht, und ändern dann gezielt. Langsame Suche und Filter behandelt unsere Seite zur Shopsuche mit OpenSearch. Mehr Hardware hilft erst, wenn der Code keine Zeit mehr verschenkt.
Magento passt, wenn große Kataloge, viele Varianten, mehrere Shops, Sprachen und Währungen oder viel eigene Geschäftslogik zusammenkommen, oft im B2B. Für solche Vorhaben bauen wir auch neue Shops auf Magento Open Source, ohne Lizenzkosten und betrieben auf eigenen Servern in Deutschland. Für ein mittleres Sortiment mit überschaubarer Sonderlogik ist Shopware 6 oft die wirtschaftlichere Wahl — günstiger im Betrieb und näher am deutschen Markt. Auch das setzen wir um, ebenso die Migration von Magento auf Shopware 6. Welcher Weg passt, klären wir im Erstgespräch an Ihrem Sortiment und Ihren Abläufen, nicht an einer Vorliebe.
Der Code gehört Ihnen: Eigene Module liegen in einem Git-Repository, das Ihnen gehört, die Domain ist immer auf Ihren Namen registriert, Lizenzen und Marketplace-Konto laufen auf Ihr Unternehmen. Betrieb und Wartung übernimmt Sharpness auf eigenen Servern in Deutschland, auf Wunsch mit einer Service-Level-Vereinbarung von 24, 8 oder 4 Stunden Reaktionszeit, für ein Jahr gebucht; die Arbeit selbst rechnen wir nach Aufwand oder im vereinbarten Rahmen ab. Ohne SLA bearbeiten wir Anfragen innerhalb von 48 Stunden in den Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Mehr zum Betrieb steht auf unserer Seite zu Magento Open Source.
Anfrage
Ein paar Sätze genügen: Funktion, Schnittstelle oder Problem, Magento-Version und Edition, wichtige Extensions. Wir melden uns mit Rückfragen und einer ersten Einordnung — unverbindlich und bevor über ein Angebot gesprochen wird.