Magento Open Source
Magento Open Source kostet keine Lizenz, verlangt aber einen Betrieb, der mitdenkt: monatliche Sicherheitspatches, feste Support-Enden je Version und einen Unterbau aus PHP, Datenbank, OpenSearch, Valkey, Varnish und Message Queue, der mit jeder Version mitwandert. Mit 2.4.9 ist das wieder sichtbar geworden — PHP 8.5, MariaDB 12.3, OpenSearch 3. Die Sharpness Solutions GmbH aus Oldenburg baut neue Magento-Shops dort, wo Magento passt, übernimmt bestehende Installationen, hält sie aktuell und betreibt sie auf eigenen Servern in Deutschland. Diese Seite erklärt, was Magento Open Source von Adobe Commerce und Mage-OS unterscheidet, wie eine Übernahme abläuft, wie Patches und Upgrades geplant werden und was der Betrieb dauerhaft verlangt. Und sie sagt, wann Shopware 6 die bessere Wahl ist. Ein Magento-Shop ist so sicher wie sein zuletzt eingespielter Patch.
Die meisten Magento-Shops laufen seit Jahren und machen Umsatz. Die Fragen kommen trotzdem, meist mit einem Termin: ein Support-Ende, ein kritisches Bulletin, ein Update, das am Server scheitert. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam haben sie eins: Bei Magento kommt der Aufwand nicht überraschend, sondern nach Kalender.
Für Magento 2.4.6 endete der reguläre Support am 11. August 2026, für 2.4.4 und 2.4.5 schon 2025. Einen verlängerten Support beschreibt Adobe ausdrücklich für Kunden von Adobe Commerce; wer Magento Open Source betreibt, plant mit dem regulären Datum. Ein Shop ohne Supportzusage ist nicht kaputt — er wird nur mit jedem Monat aufwendiger abzusichern.
Im September 2026 hat Adobe mit APSB26-146 eine kritische Lücke geschlossen, die laut Adobe bereits ausgenutzt wurde, mit eigenem Hotfix. Das Oktober-Bulletin APSB26-153 enthält diesen Hotfix nicht; er muss separat eingespielt werden. Wer nur das jeweils neueste Paket installiert, hat genau diese Lücke noch offen.
Nach den Systemanforderungen von Adobe läuft 2.4.9 mit PHP 8.5, MariaDB 12.3 oder MySQL 8.4, OpenSearch 3 und Valkey 9. Vor dem Update steht also ein Umbau des Servers, nicht nur ein Composer-Befehl. Wer das Upgrade als Versionssprung kalkuliert, bekommt eine Zahl, die im Projekt kippt.
Der Shop wurde vor Jahren gebaut, die Entwickler von damals sind nicht mehr greifbar, die Dokumentation ist dünn. Ob jemand im Core geändert hat, welche Extension was überschreibt und welcher Cronjob wofür läuft, weiß keiner genau. Das lässt sich herausfinden — vor der ersten Änderung, nicht danach.
Mit 2.4.9 ersetzt Adobe Zend_Cache durch symfony/cache und die Laminas-MVC-Schicht durch eine eigene Implementierung. Extensions, die darauf bauen, müssen angepasst werden, bevor das Update produktiv gehen kann. Ob der Hersteller das rechtzeitig tut, steht in keinem Vertrag; ob es nötig ist, zeigt ein Test auf dem Staging-System.
Preise im Shop hängen hinter der Warenwirtschaft her, Massenaktionen bleiben stehen, Bestände stimmen nicht. Hinter solchen Symptomen stecken bei Magento oft Cronjobs, die nicht laufen, oder Queue-Consumer, die niemand gestartet hat. Ein Magento-Shop ohne Überwachung meldet solche Fehler nicht, er zeigt sie Ihren Kunden.
Magento Open Source ist die frei verfügbare Edition von Magento 2. Der Quellcode steht unter der Open Software License 3.0, im Repository liegt zusätzlich die Academic Free License 3.0; Lizenzkosten fallen nicht an. Installiert wird per Composer aus dem Paketrepository von Adobe, für das auch Open-Source-Shops Zugangsschlüssel aus dem Commerce Marketplace brauchen. Betrieben wird der Shop auf eigener Infrastruktur: Server, Hosting und Wartung liegen beim Betreiber. Im Lieferumfang steckt mehr, als viele erwarten — Page Builder, Inventory Management (MSI), REST- und GraphQL-API, Zwei-Faktor-Anmeldung für den Admin und reCAPTCHA. Keine Lizenz heißt allerdings nicht kein Aufwand. Die Kosten verschieben sich von der Lizenz in den Betrieb.
Adobe Commerce ist die lizenzierte Edition mit zusätzlichen Funktionen. Nur dort gibt es laut Adobe unter anderem Content Staging für zeitgesteuerte Inhaltsänderungen, Kundensegmente, Reward Points, Retouren über RMA, Live Search, Product Recommendations und das B2B-Modul, das zusätzlich eine eigene Lizenz verlangt. Auch Adobes Cloud-Infrastruktur und das SaaS-Angebot Adobe Commerce as a Cloud Service gehören zu Adobe Commerce. Für viele Shops ist das mehr, als sie nutzen; Kundenpreise, Freigaben oder Retourenabläufe lassen sich in Open Source als eigene Module bauen, wie unsere Seite zur Magento-Entwicklung beschreibt. Wo bereits eine Adobe-Commerce-Lizenz besteht, arbeiten wir auch damit. Entscheidend ist nicht die Edition, sondern ob ihre Funktionen gebraucht werden.
Mage-OS ist eine unabhängige, von der Community getragene Distribution von Magento Open Source. Dahinter steht die Mage-OS Association, eine gemeinnützige, in Polen eingetragene Organisation, deren Vorstand die Mitglieder jährlich wählen. Mage-OS bleibt mit Magento Open Source kompatibel, ein Rückweg zum Original ist vorgesehen. Die Linie 3.x basiert auf 2.4.9; die Version 3.6.0 vom 14. Oktober 2026 enthält die Sicherheitskorrekturen aus dem Oktober-Bulletin von Adobe. Für einen Shop ist Mage-OS damit keine andere Plattform, sondern ein anderer Lieferweg für denselben Code. Ob er Ihnen Vorteile bringt, prüfen wir an Extensions und gewünschtem Update-Takt. Betrieb, Patches und Entwicklung laufen bei uns für beide gleich.
Magento spielt seine Stärken dort aus, wo Kataloge groß und Regeln zahlreich sind: viele Artikel mit vielen Varianten, mehrere Shops, Sprachen und Währungen in einer Installation, viel Sonderlogik in Preisfindung, Checkout und Bestellprozess, B2B mit Kundenpreisen und Freigaben. Das Attributmodell trägt technische Sortimente, deren Merkmale gefiltert werden müssen. Für solche Vorhaben bauen wir neue Shops auf Magento Open Source, ohne Lizenzkosten und auf eigenen Servern in Deutschland. Ein neuer Shop startet auf 2.4.9, der aktuellen Linie mit regulärem Support bis zum 31. Mai 2029. Fürs Frontend kommt das Hyvä Theme infrage, seit dem 10. November 2025 kostenlos und unter denselben Lizenzen wie Magento. Magento ist die richtige Wahl, wenn ein Shop mehr als den Standard tragen muss.
Ein Beispiel ist der Magento-Shop der Manotura GmbH & Co. KG für Bewässerungstechnik. Das Sortiment ist erklärungsbedürftig — Beregnungsanlagen, Rohrsysteme, Zubehör —, und das Attributmodell bildet die technischen Merkmale ab, sodass Kunden nach echten Auswahlkriterien filtern statt nach Kategorienamen. Varianten, Staffelpreise und Zubehörverweise gehören zur Datenstruktur. Artikelstamm, Preise und Bestände kommen aus der Warenwirtschaft, Bestellungen gehen dorthin zurück, über geplante Jobs mit Protokollierung und Wiederholungslogik. Über 12.000 Artikel werden synchronisiert, Preise und Bestände stündlich abgeglichen, und der Pflegeaufwand liegt rund 40 % unter dem einer Doppelerfassung. Betrieben wird der Shop mit Docker auf unseren Servern in Deutschland, inklusive Updates, Backups und Monitoring. Gepflegt wird an einer Stelle, nicht an zweien.
Magento ist mächtig, und das hat seinen Preis: mehr Dienste im Betrieb, ein enger Takt aus Patches und Upgrades, Entwicklung, die Erfahrung mit dem Framework verlangt. Für einen mittelständischen Shop mit überschaubarem Sortiment und wenig Sonderlogik ist Shopware 6 meist die wirtschaftlichere Wahl — schlanker im Betrieb und nah am deutschen Markt. Auch das bauen wir: Sharpness ist Shopware Extension Partner, und die Migration von Magento auf Shopware 6 mit Daten, Weiterleitungen und getesteter Umschaltung gehört zu unseren Projekten. Gegen einen Wechsel spricht ein gepflegter Magento-Shop mit Sonderlogik, die teuer nachzubauen wäre. Ein funktionierendes System ist kein Grund für ein Neubauprojekt. Diese Rechnung machen wir vor dem Projekt auf, nicht mittendrin.
Die Übernahme eines Magento-Shops, den jemand anders gebaut hat, ist bei uns der Normalfall. Sie beginnt mit einer Bestandsaufnahme: Magento-Version und Patchstand, PHP, Datenbank, Suchdienst und Cache im Abgleich mit den Systemanforderungen von Adobe, installierte Extensions mit Herkunft und Versionsstand, eigene Module in app/code und die Frage, ob jemand im Core oder im vendor-Verzeichnis geändert hat. Dazu kommen Cronjobs, Queue-Consumer, Schnittstellen und die Serverumgebung. Ergebnis ist ein schriftlicher Befund mit Risiken, Reihenfolge und Aufwand in Personentagen. Ein Befund kostet weniger als der erste Ausfall, der ihn sonst ersetzt.
Aus dem Befund ergibt sich, was sofort passieren muss und was geplant werden kann. Sofort heißt: fehlende Sicherheitspatches einspielen, Backups prüfen, die noch nie zurückgespielt wurden, Admin-Zugänge aufräumen, Zwei-Faktor-Anmeldung erzwingen und Monitoring einrichten. Geplant heißt: Extensions ohne Pflege ersetzen, Core-Änderungen in eigene Module überführen, den Unterbau auf einen unterstützten Stand heben. Das Upgrade Compatibility Tool stellt Adobe nur für Adobe Commerce bereit; bei Magento Open Source prüfen wir Extensions und eigenen Code gegen die Zielversion selbst, mit dem Magento Coding Standard und Tests auf dem Staging-System. Wer dringend und wichtig auseinanderhält, muss nicht alles auf einmal bezahlen.
Zur Übernahme gehören Zugänge und Eigentum. Wir klären vorher, nicht im Störfall, wo Code, Datenbank und Medien liegen, wer die Zugangsschlüssel für das Composer-Repository von Adobe besitzt und auf wen Domain, Zahlungsanbieter und Extension-Lizenzen laufen. Der Code kommt in ein Git-Repository, das Ihnen gehört, die Domain bleibt auf Ihren Namen registriert, die Marketplace-Schlüssel laufen über Ihr Unternehmen. Auf Wunsch ziehen wir den Shop auf unsere Server um, zuerst als Staging-Kopie, dann im vereinbarten Wartungsfenster. Läuft noch Magento 1, ist die Lage eine andere: Seit Juni 2020 gibt es dafür keine Sicherheitsupdates mehr, und der Weg führt über einen Neuaufbau mit Datenübernahme. Übernommen ist ein Shop erst, wenn alle Zugänge geklärt sind.
Adobe liefert Sicherheitskorrekturen für Magento auf zwei Wegen. Die -p-Releases wie 2.4.8-p5 sind kumulative Stände einer Linie und werden per Composer installiert; laut Adobe erscheint mindestens einmal im Jahr eines für jede unterstützte Linie. Dazwischen kommen monatlich am Patch Tuesday, dem zweiten Dienstag im Monat, die Isolated Security Patches — ausdrücklich auch für Magento Open Source. Sie sind Code-Diffs statt Composer-Pakete, bauen nicht aufeinander auf und werden der Reihe nach eingespielt, ausgehend vom neuesten -p-Stand. Dazu kommen Notfälle wie der Hotfix aus APSB26-146. Den eingespielten Stand prüft das Commerce Version Tool. Wir spielen jeden Patch erst auf Staging, dann im Live-Shop ein und dokumentieren ihn. Ein Patch, der nur heruntergeladen wurde, schützt nichts.
Jede Linie hat nach dem Adobe-Lifecycle ein festes Ende des regulären Supports: 2.4.6 am 11. August 2026, 2.4.7 am 31. Mai 2027, 2.4.8 am 31. Mai 2028, 2.4.9 am 31. Mai 2029. Einen verlängerten Support über ein weiteres Jahr beschreibt Adobe ausdrücklich für Kunden von Adobe Commerce; für Magento Open Source planen Sie mit dem regulären Datum. Hinzu kommen die Lebenszyklen der Dienste darunter. MySQL 8.0 hat sein Support-Ende am 30. April 2026 erreicht, Elasticsearch 7.17 am 15. Januar 2026, und für Drittkomponenten nach deren Lebensende liefert Adobe keine Fixes. Wer Upgrades nach Kalender plant, muss sie nicht unter Druck machen.
Magento 2.4.9 ist seit dem 12. Mai 2026 verfügbar. Nach der Tabelle der Systemanforderungen läuft es mit PHP 8.5, MariaDB 12.3 oder MySQL 8.4, OpenSearch 3, Valkey 9, Varnish 8, nginx 1.30, Composer 2.10 sowie RabbitMQ 4.3 oder ActiveMQ Artemis 2; Redis und Elasticsearch stehen nicht mehr darin. Adobe nennt als Beispiel ausdrücklich, vor dem Upgrade zuerst MariaDB auf 12.3 zu heben. Im Code ersetzt 2.4.9 Zend_Cache durch symfony/cache, hebt Symfony auf 7.4 LTS und tauscht im Admin den Editor TinyMCE gegen HugeRTE. Die Reihenfolge — Unterbau, Extensions, eigener Code, Magento — legen wir im Befund fest und testen sie vollständig auf Staging. Wie der Wechsel des Suchdienstes abläuft, beschreibt unsere Seite zur OpenSearch-Shopsuche. Ein Upgrade ist ein Vorhaben mit Termin, kein Klick im Admin.
Ein Magento-Shop ist kein einzelnes Programm, sondern ein Verbund von Diensten: PHP hinter nginx, MariaDB oder MySQL, OpenSearch für Katalog und Suche, Valkey für Cache und Sessions, Varnish als HTTP-Cache davor, dazu RabbitMQ oder ActiveMQ Artemis für die Message Queue. Fällt einer davon aus, merkt das der Shop sofort. Bei Sharpness laufen diese Dienste auf eigenen Servern — Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, Deutschland —, containerisiert mit Docker, jede Kundenumgebung für sich. Staging und Live laufen mit denselben Versionen, und ein Update wird dort getestet, wo es später auch läuft. Suchdienst und Cache sind nur für ihren Shop erreichbar. Ein Staging-System, das anders aufgebaut ist als der Live-Shop, testet etwas anderes.
Vieles in Magento passiert im Hintergrund. Cronjobs halten die Indexer aktuell — ein einmaliger Reindex ersetzt sie nicht —, versenden E-Mails und räumen auf. Queue-Consumer arbeiten Massenaktionen, Bestandsänderungen aus Inventory Management und Bulk-Aufrufe der REST-API ab; laufen sie nicht, bleibt die Arbeit liegen, ohne dass jemand eine Fehlermeldung sieht. Wir überwachen deshalb nicht nur Server und Antwortzeiten, sondern auch Indexer-Status, Cron-Läufe und die Länge der Warteschlangen. Deployments laufen über Composer im Produktionsmodus mit setup:upgrade, setup:di:compile und setup:static-content:deploy, mit versionierter Konfiguration und einem Backup unmittelbar davor. Content Staging aus Adobe Commerce ist übrigens etwas anderes als dieses Staging-System. Ein Fehler, den das Monitoring findet, kostet weniger als einer, den ein Kunde meldet.
Nach der Übernahme oder dem Go-live betreiben und warten wir den Shop mit einer Service-Level-Vereinbarung. Es gibt drei Stufen: BASIC mit 24, STANDARD mit 8 und ADVANCED mit 4 Stunden Reaktionszeit. Ein SLA ist eine Vorhaltung — die Reaktionszeit wird für ein Jahr gebucht, die Arbeit selbst nach Aufwand abgerechnet oder in einem individuell vereinbarten Rahmen, der bereits Stunden enthält. Der Stundensatz ist gestaffelt: werktags in der Arbeitszeit, werktags außerhalb sowie am Wochenende und an Feiertagen; die Sätze nennen wir auf Anfrage. Ohne SLA bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr; Rufbereitschaft gibt es nur mit SLA. Patches, Upgrades, Betrieb und Weiterentwicklung kommen so aus einer Hand.
Ablauf
Schicken Sie uns Magento-Version, Hosting und ein paar Sätze dazu, was ansteht: ein Support-Ende, ein Bulletin, ein Upgrade, eine Übernahme oder ein neuer Shop. Sie bekommen eine erste, unverbindliche Einordnung, welcher Weg passt 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 die Lage: Magento-Version, Hosting, was drängt — ein Support-Ende, ein Bulletin, ein Upgrade — oder was der neue Shop leisten soll. Wir sagen, ob Magento Open Source passt, ob Adobe Commerce oder Mage-OS eine Rolle spielt und wann Shopware 6 die bessere Wahl wäre. Unverbindlich und vor jedem Angebot.
Bei einem bestehenden Shop sehen wir in Code, Extensions, Patchstand, Serverumgebung, Cron und Queues und schreiben einen Befund mit Risiken, Reihenfolge und Aufwand in Personentagen. Bei einem Neuaufbau klären wir im Workshop Sortiment, Shops, Sprachen, Währungen, Preislogik und angebundene Systeme.
Was der Befund als dringend markiert, kommt zuerst: fehlende Sicherheitspatches, geprüfte Backups, aufgeräumte Admin-Zugänge, Monitoring für Dienste, Indexer und Warteschlangen. Der Code kommt in ein Git-Repository, das Ihnen gehört, die Zugänge werden dokumentiert.
Wir bauen die Umgebung mit Docker auf unseren Servern in Deutschland auf, zuerst als Staging-System mit einer Kopie der Live-Daten. Dort testen wir Checkout, Schnittstellen und Hintergrundjobs; umgezogen wird im vereinbarten Wartungsfenster, mit Backup davor und einem Rückweg.
Patches spielen wir im monatlichen Takt ein. Upgrades auf eine neue Linie wie 2.4.9 planen wir als eigenes Vorhaben: erst der Unterbau, dann Extensions und eigener Code, dann Magento — jeweils vollständig auf Staging getestet, bevor es produktiv geht.
Danach betreiben und warten wir den Shop mit SLA, beobachten Dienste, Indexer und Queues und halten den Lifecycle im Blick. Neue Funktionen und Schnittstellen entstehen als eigene Module; wie das aussieht, beschreibt unsere Seite zur Magento-Entwicklung.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Magento Open Source ist die lizenzkostenfreie Edition unter der Open Software License 3.0, Adobe Commerce die lizenzierte Edition mit zusätzlichen Funktionen. Nur in Adobe Commerce gibt es laut Adobe unter anderem Content Staging, Kundensegmente, Reward Points, Retouren über RMA, Live Search, Product Recommendations und das B2B-Modul, das eine eigene Lizenz verlangt; auch Adobes Cloud-Infrastruktur und das SaaS-Angebot gehören dazu. Open Source enthält dagegen Page Builder, Inventory Management, REST- und GraphQL-API und Zwei-Faktor-Anmeldung. Vieles, was Adobe Commerce mitbringt, lässt sich in Open Source als eigenes Modul bauen. Wo bereits eine Adobe-Commerce-Lizenz besteht, arbeiten wir auch damit.
Eine Lizenz kostet Magento Open Source nicht; die Kosten entstehen in Aufbau, Betrieb und Pflege. Ein Shop braucht neben PHP und Datenbank OpenSearch, Valkey, Varnish und eine Message Queue, dazu monatliche Sicherheitspatches und alle paar Jahre ein Upgrade auf eine neue Linie. Diese Posten fallen unabhängig davon an, wie viele Bestellungen eingehen. Hinzu kommen Extensions aus dem Marketplace und eigene Module. Wir kalkulieren in Personentagen, mit getrennten Posten für Befund, Umsetzung, Upgrades und Betrieb. Konkrete Zahlen nennen wir nach Bestandsaufnahme oder Workshop, den Stundensatz auf Anfrage.
Mage-OS ist eine unabhängige, von der Community getragene Distribution von Magento Open Source, keine eigene Plattform. Getragen wird sie von der Mage-OS Association, einer gemeinnützigen, in Polen eingetragenen Organisation. Mage-OS bleibt mit Magento Open Source kompatibel und sieht einen Rückweg zum Original vor; die Linie 3.x basiert auf 2.4.9, und die Version 3.6.0 vom 14. Oktober 2026 enthält die Sicherheitskorrekturen aus Adobes Oktober-Bulletin. Ob Mage-OS für Ihren Shop Vorteile bringt, hängt an Extensions und gewünschtem Update-Takt. Betrieb, Patches und Entwicklung laufen bei uns für beide gleich.
Nach dem Adobe-Lifecycle endet der reguläre Support für 2.4.7 am 31. Mai 2027, für 2.4.8 am 31. Mai 2028 und für 2.4.9 am 31. Mai 2029; für 2.4.6 endete er am 11. August 2026, für 2.4.4 und 2.4.5 bereits 2025. Einen verlängerten Support beschreibt Adobe ausdrücklich für Kunden von Adobe Commerce, für Magento Open Source planen wir deshalb mit dem regulären Datum. Dazu kommen die Lebenszyklen von PHP, Datenbank und Suchdienst, für die Adobe nach deren Ende keine Fixes liefert. Wir legen Upgrades so, dass sie vor dem Support-Ende fertig sind, nicht danach.
Monatlich: Am Patch Tuesday, dem zweiten Dienstag im Monat, veröffentlicht Adobe Isolated Security Patches, ausdrücklich auch für Magento Open Source. Sie sind nicht kumulativ, werden der Reihe nach eingespielt und setzen den neuesten -p-Stand der Linie voraus. Mindestens einmal im Jahr kommt zusätzlich ein kumulatives -p-Release per Composer, in das die Korrekturen einfließen. Dazu kommen Notfälle: Im September 2026 schloss APSB26-146 eine Lücke, die laut Adobe bereits ausgenutzt wurde, mit eigenem Hotfix, der im Oktober-Patch nicht enthalten ist. Wir testen jeden Patch auf Staging und dokumentieren den Stand je Shop.
Vor allem der Unterbau: Laut Systemanforderungen läuft 2.4.9 mit PHP 8.5, MariaDB 12.3 oder MySQL 8.4, OpenSearch 3 und Valkey 9; Elasticsearch und Redis stehen nicht mehr darin. Im Framework ersetzt Adobe Zend_Cache durch symfony/cache und die Laminas-MVC-Schicht durch eine eigene Implementierung, Symfony steigt auf 7.4 LTS, und im Admin löst HugeRTE den Editor TinyMCE ab. Für die Message Queue empfiehlt Adobe langfristig ActiveMQ Artemis. Extensions, die auf die ersetzten Bibliotheken bauen, müssen angepasst werden. Deshalb steht vor dem Upgrade ein Test aller Extensions und eigenen Module auf dem Staging-System.
Ein Upgrade planen, und zwar in der richtigen Reihenfolge: Für 2.4.6 endete der reguläre Support am 11. August 2026. Wer auf 2.4.4 oder 2.4.5 steht, nutzt laut Adobe OpenSearch 2.19 und braucht für OpenSearch 3 zuerst eine Version, die beide Linien kennt, also 2.4.6 oder 2.4.7. Ob der Weg in einem oder mehreren Schritten zu 2.4.9 führt, hängt an Extensions, eigenem Code und Server. Bis dahin sichern wir den bestehenden Stand mit den verfügbaren Patches ab. Den Wechsel des Suchdienstes beschreibt unsere Seite zur OpenSearch-Shopsuche.
Ja, das ist bei uns der Normalfall. Am Anfang steht eine Bestandsaufnahme: Version und Patchstand, Extensions, eigene Module, mögliche Änderungen im Core, Cronjobs, Queues, Schnittstellen und Serverumgebung. Daraus entsteht ein schriftlicher Befund, was sofort abgesichert werden muss und was geplant werden kann, mit Aufwand in Personentagen. Zugänge, Composer-Schlüssel und Lizenzen klären wir vorher, nicht im Störfall. Auf Wunsch ziehen wir den Shop auf unsere Server in Deutschland um, zuerst als Staging-Kopie, dann im vereinbarten Wartungsfenster. Der Code liegt danach in einem Git-Repository, das Ihnen gehört, die Domain bleibt auf Ihren Namen registriert.
Auf unseren eigenen Servern: Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, Deutschland, containerisiert mit Docker. Zu einem Magento-Shop gehören PHP hinter nginx, MariaDB oder MySQL, OpenSearch, Valkey für Cache und Sessions, Varnish als HTTP-Cache und eine Message Queue mit RabbitMQ oder ActiveMQ Artemis, dazu Cronjobs und Queue-Consumer. Jede Kundenumgebung läuft für sich, mit Staging-System, Backups und einem Monitoring, das auch Indexer und Warteschlangen beobachtet. Suchdienst und Cache sind nur für ihren Shop erreichbar. Staging und Live laufen mit denselben Versionen, damit ein Test prüft, was später tatsächlich läuft.
Das SLA sichert Ihnen eine Reaktionszeit: BASIC 24, STANDARD 8 oder ADVANCED 4 Stunden. Es ist eine Vorhaltung, die für ein Jahr gebucht wird; die Arbeit selbst rechnen wir nach Aufwand ab oder in einem individuell vereinbarten Rahmen, der bereits Stunden enthält. Der Stundensatz ist gestaffelt nach Arbeitszeit, Werktagen außerhalb der Arbeitszeit sowie Wochenende und Feiertagen; die Sätze nennen wir auf Anfrage. Ohne SLA bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Rufbereitschaft außerhalb dieser Zeiten gibt es nur mit SLA.
Magento passt, wenn der Shop viel tragen muss: große Kataloge mit vielen Varianten, mehrere Shops, Sprachen und Währungen, viel Sonderlogik oder B2B mit Kundenpreisen und Freigaben. Für einen mittelständischen Shop mit überschaubarem Sortiment ist Shopware 6 meist die wirtschaftlichere Wahl, weil der Betrieb schlanker ist. Beides bauen wir: Neue Magento-Shops starten auf 2.4.9, Shopware-Shops auf dem aktuellen Stand von Shopware 6, und Sharpness ist Shopware Extension Partner. Auch die Migration eines bestehenden Magento-Shops auf Shopware 6 gehört zu unseren Projekten. Welcher Weg sich rechnet, klären wir im Erstgespräch, bevor ein Angebot entsteht.
Ablösen, und zwar geplant: Für Magento 1 gibt es seit Juni 2020 keine Sicherheitsupdates mehr. Ein Update von Magento 1 auf Magento 2 gibt es nicht; der Weg ist ein Neuaufbau mit Datenübernahme, bei dem Produkte, Kunden und Bestellungen mitkommen, Theme, Extensions und Schnittstellen aber neu entstehen. Ob das Ziel Magento Open Source 2.4.9 oder Shopware 6 heißt, entscheiden Sortiment, Sonderlogik und Betriebsaufwand. Bis zur Umschaltung halten wir den Altshop so gut abgesichert, wie es ohne Herstellerpatches möglich ist. Jeder Monat ohne Plan verlängert die Zeit, in der bekannte Lücken offen bleiben.
Anfrage
Ein paar Sätze genügen: Magento-Version, Hosting, was drängt oder was der neue Shop leisten soll. Wir melden uns mit Rückfragen und einer ersten Einordnung — unverbindlich und bevor über ein Angebot gesprochen wird.