Wovon Kosten und Dauer eines Shopware-Shops abhängen
Drei Treiber bestimmen, was ein Shopware-6-Shop kostet: die B2B-Preislogik, die ERP-Anbindung und der Umfang der Datenmigration. Preislogik heißt: Gilt ein Preis für alle, oder rechnet der Shop je Kunde, Kundengruppe und Menge — mit Staffeln, Sonderpreisen auf Artikelebene und Konditionen, die aus dem ERP kommen? ERP-Anbindung heißt: Welche Daten fließen in welche Richtung, wie oft, und was passiert, wenn ein Abgleich abbricht? Datenmigration heißt: Wie viele Artikel, Varianten, Kundenkonten und Bestellungen kommen mit, und in welchem Zustand sind sie? Die Artikelzahl allein treibt den Preis selten. Die Qualität der Daten schon.
Sharpness (Oldenburg) kalkuliert in Personentagen, nicht in Paketpreisen. Audit, Konzept, Theme, Schnittstellen, Datenmigration und Test stehen als getrennte Posten im Angebot, damit Sie sehen, wofür Sie bezahlen, und einzelne Posten verschieben oder streichen können. Neben dem Projekt stehen laufende Kosten, die in keinem Projektangebot auftauchen, aber in jedes Budget gehören: die Shopware-Lizenz je nach Edition, Erweiterungen aus dem Shopware Store, die es seit dem 28. Dezember 2023 nur noch als Mietlizenz gibt, Hosting und Wartung, Transaktionsgebühren der Zahlungsanbieter und die interne Zeit für Datenpflege, Tests und Schulung. Ein Shop ist erst dann günstig, wenn er es auch im dritten Betriebsjahr noch ist.
Für die Dauer gilt dieselbe Logik, ergänzt um einen Faktor, den nur Sie steuern: wie schnell Daten, Entscheidungen und Freigaben auf Ihrer Seite vorliegen. Ein Shop-Projekt plant man in Monaten. Einen belastbaren Zeitplan und einen Preis nennen wir nach der Bestandsaufnahme, nicht am Telefon. Für bestehende Shops ist das ein Befundbericht zu Daten, Erweiterungen und Schnittstellen — ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen. Für Neubauten ist es ein Anforderungsworkshop mit anschließendem Konzept. Den Stundensatz und den Preis des Befundberichts nennen wir auf Anfrage.
Edition, Hosting und Betrieb: wer was trägt
Die kostenfreie Community Edition genügt, solange der Standard plus eigene Plugins Ihre Anforderungen trägt. Das gilt auch für manchen B2B-Shop: Kundengruppen, Staffel- und Kundengruppenpreise und der Rule Builder für Konditionen stecken im offenen Kern. Ein kostenpflichtiger Plan lohnt sich, wenn Sie Firmenkonten, Bestellfreigaben und Angebotsprozesse als Produktbestandteil wollen statt als Eigenentwicklung — Shopware liefert sie als B2B Components — oder wenn Herstellersupport vertraglich gefordert ist. Die Pläne beginnen laut Shopware-Preisübersicht mit Rise ab 600 Euro und Evolve ab 2.400 Euro monatlich, zuzüglich Mehrwertsteuer. Die B2B Components stecken nicht in jedem kostenpflichtigen Plan; prüfen Sie den Umfang vor der Buchung. Verglichen wird Lizenz gegen Eigenentwicklung, über die Laufzeit.
Shopware Cloud nimmt Ihnen Server und Updates ab und zieht dafür eine Grenze: keine Shell, keine klassischen Plugins. Erweiterungen laufen dort ausschließlich als App: Die Logik liegt auf einem eigenen Server und erreicht den Shop über Admin API, Store API und Webhooks. Für einen Shop nah am Standard ist das eine Entlastung. Für einen Shop mit tiefen Eingriffen in Checkout, Preisfindung oder Datenmodell ist es eine harte Grenze, die vor der Entscheidung bekannt sein sollte, nicht danach.
Selbst gehostet heißt: Jemand betreibt PHP, Datenbank, Cache, Suchindex, Message Queue, Staging-System und Backups — dauerhaft, nicht nur zum Launch. Bei Sharpness läuft das auf eigenen Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, jede Kundenumgebung für sich, mit Valkey beziehungsweise Redis und OpenSearch dort, wo Katalog und Last es rechtfertigen. Nach dem Go-live übernehmen wir die Wartung mit Service-Level-Vereinbarung — 24, 8, 4 oder 2 Stunden Reaktionszeit, als Monatspauschale netto je Shop. Betrieb und Wartung liegen dann in einer Hand. Am Telefon sind wir Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr; Rufbereitschaft außerhalb dieser Zeiten gibt es nur mit SLA.
Theme, Plugins, Zahlung: Standard nutzen, Abweichung bauen
Ein gutes Shopware-Theme erweitert die Standard-Storefront, statt sie zu ersetzen. Farben, Typografie und Komponenten liegen in einem eigenen Theme; geändert wird über gezielt überschriebene Twig-Blöcke mit sw_extends, nicht über kopierte Templates und nie im Core. Der Grund ist das nächste Major-Update: Jeder überschriebene Block muss dann gegen das neue Original gelesen werden. Was ein Theme kostet, bemisst sich deshalb an der Zahl der Eingriffe, nicht am Aussehen. Ein Design, das gegen die Storefront arbeitet, bezahlen Sie einmal beim Bau und bei jedem Update wieder.
Für Zahlarten, Versanddienstleister, Bewertungen, Rechnungslayouts und Marktplatz-Anbindungen gibt es gepflegte Erweiterungen im Shopware Store; eine Eigenentwicklung daneben wäre Verschwendung. Selbst gebaut wird dort, wo Ihr Ablauf vom Standard abweicht: Preisfindung, Bestellfreigaben, Konfiguratoren, Logik aus dem ERP. Jede Erweiterung, gekauft oder gebaut, ist eine Position im Betrieb, die bei jedem Update mitgeprüft wird. Eine Erweiterung, die nicht installiert ist, bricht beim Update nicht. Sharpness — 250+ Projekte seit 1999 — ist Shopware Extension Partner mit eigenen Erweiterungen im Shopware Store und entwickelt Plugins gegen die vorgesehenen Erweiterungspunkte: Events, Service-Dekoration, Entity-Extensions.
Zahlungsarten bringen die Anbieter als eigene Erweiterungen mit — PayPal, Kreditkarte, SEPA-Lastschrift, Klarna, dazu Sammeldienste wie Mollie, Stripe oder Unzer. Im B2B zählen vor allem Rechnungskauf und Vorkasse, häufig mit einem Kreditlimit, das aus dem ERP kommt. Wichtiger als die Auswahl sind zwei Dinge: Kartendaten berühren Ihren Server nie, sondern landen direkt beim Zahlungsdienstleister, und der Zahlungsstatus kommt sauber in der Warenwirtschaft an — sonst entsteht Nacharbeit in der Buchhaltung. Versandarten und Versandkosten steuert der Rule Builder, etwa nach Lieferland, Kundengruppe oder Warenkorbwert. Vor dem Go-live läuft eine Testbestellung über jede Zahlungs- und jede Versandart.
ERP, PIM und B2B: wo sich das Projekt entscheidet
Eine ERP-Anbindung entscheidet sich an der Richtungsfrage, nicht an der Technik: Welches System führt Preise, Bestände, Artikeltexte und Kunden, und welches liest nur? Ist das geklärt, ist die Anbindung Handwerk. Technisch läuft sie über die Admin API von Shopware, für Massendaten über deren Sync-Endpunkt, mit Abgleichen, die jeden Lauf protokollieren und nach einem Abbruch ohne Datenschaden neu starten. Welches ERP dahintersteht, ist zweitrangig, solange es seine Daten über eine Schnittstelle, einen Export oder die Datenbank hergibt. Der Aufwand steckt im Zustand der Daten: Artikelnummern, Varianten, Mengeneinheiten, Preislisten und Merkmale, die heute nur als Fließtext im Produkttext stehen.
Bei M&S Armaturen, einem B2B-Shop für Industriearmaturen auf Shopware 6, sind Merkmale wie Nennweite, Druckstufe und Werkstoff als filterbare Attribute modelliert, nicht als Text. Artikelstammdaten, Preise und Verfügbarkeiten kommen aus den führenden Systemen, Bestellungen gehen strukturiert zurück. Das ist das Muster eines B2B-Shops, den Einkäufer tatsächlich nutzen: Der Katalog zeigt denselben Stand wie das Backoffice, und niemand pflegt Preise doppelt.
B2B ist mehr als ein Login vor dem Katalog. Dazu gehören kundenindividuelle Preise — Staffel- und Kundengruppenpreise über den Rule Builder, Preise je Kunde aus dem ERP über die dafür vorgesehenen Wege statt über eine eigene Kundengruppe pro Kunde —, Firmenkonten mit mehreren Bestellern, Freigaben und Budgets. Bei Diderk Heinje Pflanzenhandel sind Sortiment und Preise erst nach einer geprüften Registrierung sichtbar. Bei Lijnco bestellen Einkäufer per OCI-Punch-out direkt aus ihrem Beschaffungssystem; der Warenkorb geht dorthin zurück, statt im Shop als Bestellung ausgelöst zu werden. Punch-out per OCI oder cXML ist kein Core-Feature, sondern eine Erweiterung oder eigene Entwicklung — und gehört deshalb von Anfang an in den Umfang.
Relaunch und Umstieg: Daten, Weiterleitungen, Barrierefreiheit
Der Umstieg von Shopware 5, WooCommerce oder Magento auf Shopware 6 ist immer ein Neubau mit Datenübernahme. Produkte, Kunden, Bestellhistorie und Medien kommen mit; Theme, Erweiterungen und Schnittstellen entstehen neu. Aus Shopware 5 überträgt der kostenlose Migrations-Assistent von Shopware die Daten — und nur die Daten. Für jede Altfunktion wird neu entschieden: Standard, Store-Erweiterung, Eigenentwicklung oder weglassen, weil sie niemand mehr benutzt. Wer das Altsystem eins zu eins nachbaut, baut seine alten Probleme gleich mit. Der alte Shop verkauft weiter, bis der neue nachweislich funktioniert; nach jedem Probelauf werden Kunden und Bestellungen gegen den Altbestand gezählt.
Rankings überstehen einen Relaunch, wenn jede alte Adresse, die Google kennt, per 301 auf die Seite mit dem passenden Inhalt weiterleitet. Die Liste dafür entsteht aus einem Crawl des kompletten Altshops — Adressen, Titel, Texte —, nicht aus dem Gedächtnis. Am meisten geht über Kategorie- und Filterseiten verloren, denn deren Pfade ändern sich mit dem System. Die Weiterleitungsliste wird vor dem Go-live auf dem Testsystem geprüft; danach werten wir Logfiles und Search Console aus und schließen 404-Reste. Platz 1 garantiert niemand. Die Liste sorgt nur dafür, dass Sie nicht verlieren, was Sie schon haben.
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für Onlineshops, über die Verbraucher kaufen; geprüft wird nach der EN 301 549 und damit nach WCAG 2.1 in Stufe AA. Reine B2B-Shops fallen grundsätzlich nicht darunter, für Dienstleistungen gilt eine Ausnahme für Kleinstunternehmen; die verbindliche Einstufung im Einzelfall gehört zu einer Anwältin oder einem Anwalt. Technisch ist ein Neubau der günstigste Zeitpunkt: Kontraste im Farbsystem festgelegt, jede Komponente per Tastatur bedienbar, Formulare mit Beschriftung und verständlichen Fehlermeldungen. Die Storefront von Shopware 6.7 hat ihren Barrierefreiheits-Umbau zum Standard gemacht; ein eigenes Theme darf ihn nicht wieder zerlegen. Ein Overlay-Skript ersetzt nichts davon.