Weil die meisten Plattformen immer noch in Silos funktionieren. Man holt sich eine Commerce Architektur und denkt, die Suche sei ein Feature, das einfach dabei ist. Aber B2B-Daten sind wild: unstrukturierte Attribute, hunderte SKUs mit minimalen Unterschieden, komplexe Abhängigkeiten. Wir bei BatteryIncluded haben den Framework-Gedanken perfektioniert. Wir sind kein geschlossenes System, sondern der Data Discovery Core, der sich nahtlos in die bestehende Architektur einfügt. Das Problem heute ist nicht der Mangel an Technologie, sondern die mangelnde Fähigkeit, Daten zu nutzen, so dass sie dem Nutzer Orientierung bieten. Wir lösen das mit unserem Relevance Stream, der User-Metadaten mit den harten Produktdaten verheiratet und selbstlernend automatisch bessere Relevanz liefert.

Wie unterscheidet sich das Suchverhalten im B2B fundamental vom B2C?

Im B2C suchen Sie zur Inspiration. Im B2B ist die Suche ein Arbeitswerkzeug. Ein Einkäufer will nicht „shoppen“, er will „finden und weitermachen“.

• Technisch: Wir müssen Einheiten verstehen (10mm = 1cm), Synonyme wie „Inbus“ vs. „Innensechskant“ auflösen und Bauteile anhand von Teile-Fragmenten finden.

• Funktional: Die Fehlertoleranz muss extrem hoch sein, während die Präzision bei technischen Parametern absolut sein muss. Wer bei uns nach einer DIN 912 sucht, darf keine DIN 913 sehen, nur weil der Algorithmus „ähnlich“ denkt.

Ab welcher Komplexität macht eine native Suche keine Freude mehr?

Spätestens ab 10.000 SKUs oder wenn Sie mehr als 20 technische Attribute pro Artikel haben. Sie erkennen das konkret an zwei Dingen: Erstens, Ihre Null-Treffer-Quote steigt bei Fachbegriffen. Zweitens, die Ladezeiten der Filter explodieren. Wenn ein Einkäufer drei Sekunden warten muss, bis die Facetten links nachladen, haben Sie ihn verloren. Wir sehen bei Kunden wie Office Partner oder Wurm, dass durch die Entkopplung der Suche vom Shop-Kern die Performance massiv steigt. Wir reden hier von einer bis zu 3x schnelleren Integration im Vergleich zu monolithischen Lösungen.

Kundenindividuelle Preise und Sortimente: Darf ein Kunde wirklich nur sehen, was für ihn freigegeben ist?

Absolut. Das ist die Königsdisziplin im B2B. Viele Standard-Suchen scheitern daran, weil wenn Usergruppen, Embargologiken und eine große Datenmenge durch kundenspezifische Preise, Sichtbarkeits- oder Verfügbarkeitslogiken zu indexieren sind. Ändert sich ein Preis im ERP, ist der Index veraltet. Unsere Engine geht hier einen anderen Weg: Wir verarbeiten Echtzeit-Rohdaten als Delta-Updates. Wir können kundenindividuelle Sortimente und Preise in den Suchprozess einweben, ohne den Index aufzublähen. Wir haben hierfür abseits von “scoped API keys” mit einer eigens entwickelten Varianten- bzw. Locale-Logik ein mächtiges Werkzeug zum maximal effizienten Datenhandling ins Leben gerufen. Ein Einkäufer bei uns sieht nur das, was er kaufen darf, zu seinem Preis. Das ist kein „Nice-to-have“, sondern die Basis für Vertrauen im digitalen Vertrieb.

Ihr habt Hybrid LLM Search eingeführt. Eine Kombination aus eurem Core und Gemini. Was war der konkrete Auslöser? Habt ihr gesehen, dass User anfangen, in natürlicher Sprache zu suchen?

Absolut. Der Auslöser war der „ChatGPT-Effekt“ im B2B. Die Erwartungshaltung hat sich massiv verschoben: Einkäufer wollen keine Keywords mehr jonglieren, sie wollen Antworten auf komplexe Fragen. Wir haben uns deshalb gegen eine einfache „Drüberstülp-Lösung“ entschieden. Stattdessen nutzen wir eine native Hochleistungs-Schnittstelle, die unseren Such-Core direkt mit Gemini verheiratet. Das ist kein loses Aneinanderketten von Tools, sondern eine tiefe Integration. Warum der Aufwand? Herkömmliche Suchen, auch viele moderne Vektorsuchen,  sind stumm, wenn es um echte Konversation geht. Wenn ein Nutzer fragt: „Was brauche ich für eine Außenmontage bei Frost?“, dann ist das kein Suchbegriff, sondern ein technisches Problem. Durch unseren nativen Connector versteht das System die Absicht hinter der Frage in Echtzeit. Gemini fungiert hier als das „Gehirn“, das die natürliche Sprache präzise in technische Filterparameter für unseren extrem schnellen Index übersetzt. Wir kombinieren die brachiale Geschwindigkeit unserer Engine mit der semantischen Tiefe von Gemini. So verwandeln wir den Suchschlitz in einen digitalen Fachberater, der versteht, dass „Frost“ im Kontext von Schrauben zwangsläufig Edelstahl oder eine spezielle Verzinkung bedeutet.

LLMs halluzinieren. Ein bekanntes Problem. Wie verhindert ihr in der Praxis, dass ein nicht-existentes Produkt empfohlen oder eine falsche Spezifikation ausgegeben wird?

Das ist ein Punkt, bei dem wir uns ganz klar vom Markt abheben. Viele setzen auf den klassischen RAG-Ansatz (Retrieval Augmented Generation), bei dem die KI am Ende einen Antworttext „würfelt“. Das ist im B2B-E-Commerce brandgefährlich.

Wir bei BatteryIncluded nutzen kein RAG.

Stattdessen verwenden wir Gemini über einen nativen Connector als intelligenten Übersetzer. Die KI agiert bei uns wie ein fachkundiger Lotse: Sie übersetzt die natürliche Sprache (Natural Language Query) des Nutzers in Millisekunden in hochpräzise, strukturierte Filterbefehle für unseren Such-Core.

Der Clou dabei: Die Produktdaten, Spezifikationen und Preise kommen niemals „aus dem Gedächtnis“ der KI. Sie kommen immer unverfälscht und direkt aus unserem autoritativen Index. Die KI „erfindet“ also keine Antwort, sondern sie bedient die Suchmaschine so perfekt, wie es ein Mensch niemals könnte. Halluzinationen sind damit technisch ausgeschlossen, weil die KI keine inhaltliche Freiheit hat, Produktdaten neu zu schreiben. Sie steuert nur die Auswahl. Die Fakten bleiben zu 100 % in Ihrem System.

SaaS aus Deutschland? Wie konkret ist diese Aussage bei euch, und was bedeutet das für Datenhaltung und Verarbeitung?

Das ist für uns eine Frage der Haltung. Während US-Anbieter oft Blackboxes sind, bei denen Daten quer über den Globus fließen, verbleibt bei uns alles in einem geschlossenen, DSGVO-konformen Kreislauf. Da wir Gemini über Enterprise-Schnittstellen an unseren Core anbinden, stellen wir sicher, dass wertvolle Katalogdaten und das Suchverhalten der Endkunden nicht zum Training öffentlicher Modelle verwendet werden. Wir nutzen die Intelligenz des Sprachmodells, ohne Ihre Daten preiszugeben. Das ist „AI made in Germany“ mit der Power der weltbesten Modelle. Sicher, skalierbar und ohne rechtliche Grauzonen.

Was ist der Unterschied zwischen einer gut konfigurierten Suche und einer selbstlernenden Engine wie eurer? Ist dieser Unterschied für einen Mittelständler spürbar?

Eine klassische Suche ist wie ein statisches Regal: Wenn Sie nicht exakt wissen, wo was steht, suchen Sie ewig. Eine selbstlernende Engine wie unsere ist ein Framework, das versteht, wie Ihre Kunden arbeiten. Der Unterschied ist massiv, gerade für den Mittelstand: Sie müssen nicht mehr tausende Synonym-Listen händisch pflegen. Unser System lernt durch die native Verzahnung von Sprachverständnis und Klick-Daten, was gemeint ist. Für einen Mittelständler mit 200 Bestellungen am Tag bedeutet das: Weniger Abbruchraten, zufriedenere Einkäufer und ein Shop, der sich anfühlt, als würde er mitdenken. Das ist Data Discovery auf einem Level, das früher nur den Top-5-Playern im Markt vorbehalten war.

Wo endet die KI und beginnt der Fachberater?

Die KI ist der Vorsortierer. Sie kann 500.000 Schrauben auf die 3 reduzieren, die für „Stahlkonstruktion bis -20°C“ technisch geeignet sind. Das spart dem Fachberater die Zeit für die Katalog-Wälzerei. Der Fachberater übernimmt dann dort, wo es um Haftung, Projektplanung oder komplexe Systemberatung geht. Die KI macht den Weg frei für das wirklich wertvolle Gespräch.

SaaS vs. Eigenbau: Warum sollte ich nicht selbst etwas mit Elasticsearch bauen?

Weil Sie ein Handelsunternehmen sind und kein Softwarehaus für Suchalgorithmen. Ein „Marke Eigenbau“ sieht am Anfang günstig aus, wird aber zur Wartungsfalle. Wer pflegt die Synonyme? Wer optimiert das Ranking? Wer integriert das LLM? Wir sind ein Framework, das „Ready to go“ ist. Wir übernehmen das „Heavy Lifting“ der Datenverarbeitung, damit Ihr Team sich auf das Merchandising konzentrieren kann. Unsere Kunden wie GoldSilberShop oder Shop4Runners beweisen, dass die Zeitersparnis bei der Verwaltung den Preis für die SaaS-Lösung bei Weitem aufwiegt. Wir haben auch einen dedizierten Artikel hierzu released: https://batteryincluded.ai/blog/ai-search/saas-vs-eigenentwicklung-ecommerce-suche/

Conversion-Raten: Habt ihr konkrete Zahlen?

Wir sehen regelmäßig, dass Nutzer mit Suche 3-mal häufiger konvertieren als „Browser“. Aber der eigentliche Hebel ist der Warenkorbwert. Durch Features wie AI Recommendations und Volt Merch (unsere Lösung für intelligentes Merchandising) konnten wir bei Kunden den Average Order Value (AOV) nachhaltig steigern. Wenn die Suche nicht nur findet, was gesucht wurde, sondern intelligent ergänzt („Andere kauften auch...“), dann arbeitet die Suche als Ihr bester Verkäufer.

Wie lange dauert die Implementierung?

Dank unseres API-First-Ansatzes sind wir zumeist innerhalb von 4 bis 8 Wochen live. Wer Zeit einplanen muss? Primär das E-Commerce-Team für die Definition der Business-Logik (Ranking-Regeln) und die IT für die initiale Datenanbindung. Da wir aber fertige Konnektoren für Systeme wie Shopware 6 oder Emporix haben, ist der technische Aufwand überschaubar.

Ihr übernehmt auf Wunsch sogar PDPs und Listings. Warum dieser tiefe Eingriff?

Weil wir die Performance-Hoheit sicherstellen wollen. Wenn wir die Produktdetailseiten (PDP) direkt aus unserem Core rendern, entfällt der „Flaschenhals“ des oft langsamen Shop-Backends. Das Ergebnis ist eine User Experience, die sich so schnell anfühlt wie eine lokale App. Betreiber sollten dabei im Kopf haben: Sie geben nicht die Kontrolle ab, Sie gewinnen Geschwindigkeit und Flexibilität für globale Rollouts.

Ihr Tipp für einen Head of E-Commerce, den er morgen umsetzen kann?

Der Dolmetscher-Check: Setzen Sie sich morgen für eine Stunde mit Ihren Kollegen aus dem technischen Vertrieb oder dem Telefon-Support zusammen. Fragen Sie sie nicht nach Umsätzen, sondern nach den Vokabeln, die Kunden am Telefon nutzen, um Produkte zu beschreiben. Vergleichen Sie diese Begriffe danach mit den Attributen in Ihrem PIM oder ERP. Sie werden feststellen: Ihre Kunden sprechen oft eine ganz andere Sprache als Ihre Datenbank.

Diesen Language Gap zu erkennen, ist der erste Schritt zu einer funktionierenden Suche. Völlig egal, welche Technologie Sie am Ende einsetzen.“

Dabei lohnt sich der Aufwand: Laut einer Studie von commercetools verzeichneten 90 % der Unternehmen nach einem Plattformwechsel Umsatz- und Verkaufssteigerungen.1 Gleichzeitig berichten nur 14 % der Unternehmen, mit ihrer aktuellen E-Commerce-Plattform zufrieden zu sein – und 77 % fühlen dringenden Handlungsbedarf.1

Was trennt erfolgreiche Replatforming-Projekte von gescheiterten? Vor allem eines: strukturierte Vorbereitung in klar definierten Phasen. Dieser Beitrag beschreibt die vier zentralen Phasen eines B2B-Replatformings – von der ersten strategischen Entscheidung bis zum erfolgreichen Go-Live – und benennt die wichtigsten Do's und Don'ts für jede Phase.

Phase 1: Entscheidungsphase – Das Fundament des Projekts

Die Entscheidungsphase ist das strategische Herzstück des gesamten Projekts. Hier wird nicht nur entschieden, ob ein Replatforming stattfindet – sondern auch wie, womit und mit wem. Wer diese Phase überstürzt oder mit unklaren Zielen beginnt, zahlt den Preis in jeder nachfolgenden Phase.

Am Anfang steht die ehrliche Auseinandersetzung mit den Signalen mit den Signalen: Kundenbeschwerden, steigende Total Cost of Ownership, technische Schulden oder End-of-Life-Szenarien sind typische Auslöser. Diese Signale müssen jedoch nicht nur erkannt, sondern auch quantifiziert werden – denn ohne belastbare Zahlen fehlt die Grundlage für eine fundierte Entscheidung. Gleichermaßen gehört die ernsthafte Prüfung von Alternativen dazu: Manchmal ist eine gezielte Optimierung der bestehenden Plattform wirtschaftlicher als ein vollständiger Wechsel.

Steht der grundsätzliche Entschluss, folgt die Definition konkreter Projektziele. Das klingt trivial, wird aber regelmäßig unterschätzt. Ziele wie „schnellerer Shop" oder „bessere User Experience" sind wertlos, wenn sie nicht messbar gemacht werden. Bewährt hat sich das SMART-Prinzip: Ein Ziel wie „Reduktion der durchschnittlichen monatlichen TCO um 20 % innerhalb von sechs Monaten nach Go-Live" lässt sich nach Projektabschluss klar evaluieren – ein vages Ziel nicht.

Parallel dazu werden die funktionalen Anforderungen erhoben: Was muss das neue System leisten? Diese Anforderungen entstehen nicht im Vakuum, sondern im Dialog mit allen betroffenen Abteilungen – von Marketing über Vertrieb und Fulfillment bis zur Buchhaltung. Im B2B-Kontext kommen typischerweise Anforderungen wie kundenindividuelle Preislisten, mehrstufige Bestellfreigabe-Workflows und tiefe ERP-Integration hinzu, die von standardisierten Plattformen nicht immer nativ abgedeckt werden.

Die Wahl der Technologie und des Implementierungspartners schließt die Phase ab. Beide Entscheidungen sind eng verknüpft: Eine Plattform, für die es regional kaum erfahrene Agenturen gibt, erhöht das Projektrisiko erheblich. Der gesamte Prozess wird durch die Erstellung eines Business Cases untermauert, der die wirtschaftliche Sinnhaftigkeit transparent und konservativ kalkuliert – idealerweise in drei Szenarien (Best Case, Base Case, Worst Case).

Do's und Don'ts

✅ Ziele messbar formulieren – SMARTe Ziele sind die einzige belastbare Messlatte für den Projekterfolg.

✅ Plattform-Reife und Ökosystem berücksichtigen – Eine starke Community, reife Agenturlandschaft und ein breites Extension-Angebot (wie bei Shopware 6 oder Magento 2) reduzieren Risiken erheblich.

✅ Agenturwahl auf Basis von Expertise treffen – nicht ausschließlich nach dem günstigsten Stundensatz (in einem vorherigen Beitrag wird geschildert, welche Aspekte zwischen In-house Entwicklung vs Agentur berücksichtigt werden sollen).

❌ Sich von Technologie-Trends blenden lassen – Headless Commerce oder Microservices sind nicht per se besser. Für viele mittelständische B2B-Unternehmen mit klar definiertem Geschäftsmodell ist eine bewährte Monolith-Plattform die kostengünstigere und stabilere Wahl. Technologie ist Mittel zum Zweck, kein Selbstzweck.

❌ Zu viele Agenturen involvieren – Mehr Beteiligte bedeuten mehr Koordinationsaufwand, mehr Abstimmungsprobleme und längere Entscheidungswege. Ein breites Leistungsportfolio aus einer Hand reduziert Reibungsverluste.

❌ Den Business Case schönrechnen – Ein Business Case, der das Projekt um jeden Preis rechtfertigt, ist gefährlich. Unrealistische Annahmen gefährden die Wirtschaftlichkeit des Projekts, lange bevor das System live ist.

Phase 2: Analysephase – Fakten statt Bauchgefühl

Die Analysephase ist oft die ressourcenintensivste Phase des gesamten Projekts – und die am häufigsten unterschätzte. Hier wird der aktuelle Zustand des E-Commerce-Systems ganzheitlich dokumentiert, um eine fundierte Grundlage für alle nachfolgenden Entscheidungen zu schaffen. Was hier nicht erhoben wird, fehlt später in der Konzeption – und wird entweder teuer nachgeholt oder gar nicht umgesetzt.

Im Zentrum steht die Ist-Analyse des bestehenden Systems aus drei Perspektiven. Technologisch geht es um Performance-KPIs wie Ladezeiten, Core Web Vitals und Uptime, aber auch um die Stabilität der Hosting-Infrastruktur, die Skalierbarkeit bei Traffic-Spitzen und die DSGVO-Konformität der eingesetzten Komponenten. Funktional werden Storefront, Admin-Bereich und Transaktions-E-Mails systematisch durchleuchtet: Welche Features existieren, welche werden tatsächlich genutzt, und was fehlt im Vergleich zu den definierten Anforderungen? Auf Business-Ebene liefern Umsatzentwicklung, Conversion Rates, Retouren und Kundenfeedback wertvolle Einblicke in die wirtschaftliche Performance des Systems.

Besonders aufwändig – und im B2B-Kontext besonders kritisch – ist die Analyse der Systemlandschaft. ERP, PIM, CRM, Payment-Provider und Logistiksysteme sind in einem B2B-Shop selten lose gekoppelt, sondern tief integriert. Diese Integrationen müssen auf technischer Ebene vollständig dokumentiert werden: API-Spezifikationen, XML- und CSV-Strukturen, Validierungsmechanismen, Geschäftslogik und Datenfelder. Was hier lückenhaft bleibt, führt in der Implementierungsphase zu bösen Überraschungen.

Ergänzt wird die Ist-Analyse durch eine Stakeholder-Analyse, die alle betroffenen internen und externen Akteure mit ihren Interessen und Erwartungen erfasst, sowie durch eine Wettbewerber- und Zielgruppenanalyse. Gerade im B2B-Bereich, wo Kaufentscheidungen komplex und Kundenbeziehungen langfristig sind, bieten diese Analysen wertvolle Hinweise darauf, welche Features und Prozesse wirklich differenzierend wirken.

Do's und Don'ts

✅ Mit Daten und Fakten arbeiten – Tools wie Hotjar (Heatmaps, Session Recordings), Google Analytics und Business-Intelligence-Systeme liefern objektive Grundlagen. Bauchgefühl ist kein Ersatz.

✅ Technische Integrationen tief analysieren – API-Spezifikationen, Datenfelder und Validierungslogiken müssen vollständig dokumentiert sein. Was hier fehlt, führt später zu teuren Nacharbeiten.

✅ Bestehende Features kritisch hinterfragen – Nicht jede vorhandene Funktion verdient es, migriert zu werden. Welchen Kosten-Nutzen-Effekt hat sie? Gibt es eine bessere oder günstigere Alternative? Ein Sparring mit externen Experten kann helfen, blinde Flecken aufzudecken.

✅ Alle Stakeholder-Gruppen einbeziehen – Nicht nur Führungskräfte. Mitarbeiter aus Fulfillment, Buchhaltung, Marketing und Kundensupport bringen praxisnahe Perspektiven, die im Konzept Niederschlag finden müssen.

❌ Analyse oberflächlich behandeln – Eine Ist-Analyse, die nur auf Screenshots und groben Beschreibungen basiert, ist wertlos. Besonders Integrationen brauchen technische Tiefe.

❌ Kunden- und Mitarbeiterbedürfnisse der Führungsebene unterordnen – Die Wünsche des Managements zu priorisieren und dabei Kunden- und Mitarbeiteranforderungen zu vernachlässigen, führt auf kurze Sicht zu ruhigeren Meetings – auf lange Sicht zu enttäuschenden Umsätzen.

❌ Web Vitals und SEO-Performance ignorieren – Ladezeiten und Core Web Vitals beeinflussen direkt Conversion Rate, SEO-Ranking und damit den Umsatz. Diese Baseline muss vor dem Replatforming erhoben werden, um den Erfolg nach dem Launch messen zu können.

Phase 3: Konzeption & Umsetzung – Das operative Herzstück

In der Konzeptions- und Umsetzungsphase werden Analyse-Ergebnisse und strategische Ziele in konkrete Konzepte und lauffähige Software übersetzt. Es ist die längste Phase – und die, in der die meisten Planungsfehler aus den Vorphasen sichtbar werden.

Die erste grundlegende Entscheidung betrifft den Projektmanagement-Ansatz. Agiles Vorgehen nach Scrum hat sich bei E-Commerce-Projekten gegenüber dem klassischen Wasserfallmodell bewährt, weil es schnellere Feedbackzyklen ermöglicht und verhindert, dass man monatelang auf ein Ergebnis hinarbeitet, das an den tatsächlichen Anforderungen vorbeientwickelt wurde. Kern des agilen Vorgehens ist ein priorisierter Product Backlog: Features werden nach Business Value geordnet – also danach, ob sie Umsatz steigern, Kosten senken oder die Effizienz für Mitarbeiter und Kunden verbessern. Der erste Go-Live folgt dem MVP-Prinzip: so viel wie nötig, so wenig wie möglich.

Parallel zur Entwicklung entstehen das Integrations- und das Migrationskonzept. Das Integrationskonzept legt fest, wie ERP, PIM, CRM, Payment-Provider und Logistiksysteme an die neue Plattform angebunden werden – mit klaren Verantwortlichkeiten für jeden Integrationspunkt. Das Migrationskonzept regelt, wie Bestell-, Kunden- und Produktdaten überführt werden und – mindestens ebenso wichtig – wie die Vollständigkeit und Korrektheit der migrierten Daten geprüft wird. Fehlerhafte Datenmigration ist einer der häufigsten Gründe für Projektverzögerungen: 83 % der Datenmigrations-Misserfolge entstehen durch unterschätzte Datenkomplexität und unzureichendes Testing.2

Ein oft unterschätzter Aspekt dieser Phase ist das Change Management. Ein Replatforming ist immer auch ein Veränderungsprojekt. Mitarbeiter, die nicht verstehen, warum die neue Plattform besser ist, werden Workarounds erfinden oder das System offen kritisieren – bewusst oder unbewusst. Wer die Betroffenen frühzeitig einbindet, deren Ängste ernst nimmt und die Vorteile verständlich kommuniziert, investiert in eine der entscheidendsten Erfolgsvariablen des Projekts.

Do's und Don'ts

✅ Verantwortlichkeiten klar definieren – Wer schreibt den Backlog? Wer nimmt Features ab? Wer koordiniert externe Integratoren wie ERP- oder CRM-Spezialisten? Unklare Rollen führen zu Missverständnissen, Frustration im Entwicklerteam und Zeitverzug.

✅ Nach Business Value priorisieren – Features, die Umsatz steigern, Kosten senken oder Effizienz verbessern, kommen zuerst. Nicht das, was der lauteste Stakeholder sich wünscht.

✅ Migrierte Daten sorgfältig validieren – Bestellungen, Kundendaten und Produktbewertungen müssen auf Vollständigkeit und korrekte Relationen geprüft werden. Viele Shopsysteme bieten Report- und Exportfunktionen, mit denen sich Summen leicht mit dem Quellsystem abgleichen lassen.

✅ Hosting und Entwicklung aus einer Hand – Die Trennung von Entwicklungsagentur und Hosting-Anbieter führt bei Produktionsproblemen zu zeitaufwändiger Fehlersuche zwischen zwei Parteien – mit direkten Auswirkungen auf Downtimes und Kundenzufriedenheit.

❌ Wasserfall-Planung für ein komplexes Projekt – Feste Lasten- und Pflichtenhefte zu Projektbeginn decken zwangsläufig nicht alle Anforderungen ab. Neue Erkenntnisse, die während der Implementierung entstehen, müssen ins Projekt einfließen können.

❌ Design-Diskussionen ohne Datenbasis – Langwierige Debatten über Farben, Layouts und UI-Details sind Zeitverschwendung, solange echte Nutzerdaten fehlen. Die sinnvollere Alternative: MVP live bringen, Daten sammeln, dann A/B-Tests planen.

❌ Change Management ignorieren – Wer das Team nicht abholt, riskiert Demotivation und im schlimmsten Fall aktiven Widerstand. Frühzeitige Kommunikation und Einbindung sind keine Soft-Skill-Übung, sondern handfestes Risikomanagement.

Phase 4: Testing & Go-Live – Kein Spielraum für Überraschungen

Die Testing- und Go-Live-Phase entscheidet darüber, ob die harte Arbeit der vorherigen Phasen in einem stabilen, vertrauenswürdigen Launch mündet – oder in einem Krisen-Marathon. Sie ist die letzte Gelegenheit, Fehler zu finden, bevor echte Kunden sie finden.

Das Testing erfolgt in aufeinander aufbauenden Stufen. Smoketests prüfen schnell und gezielt, ob die Grundfunktionen intakt sind: Shop lädt, Warenkorb funktioniert, Bestellabschluss ist möglich. Integrationstests überprüfen, ob alle Systemanbindungen korrekt funktionieren – werden Bestelldaten vollständig ins ERP übergeben, stimmen Preise und Lagerbestände, fließen Kundendaten korrekt ins CRM? End-to-End-Tests spielen schließlich realistische Geschäftsprozesse vollständig durch: von der Produktsuche über den Checkout bis zur Auftragsbestätigung. Im B2B-Kontext bedeutet das auch: Bestellfreigabe-Workflows, kundenindividuelle Sortimente und Konditionenlogiken müssen unter realen Bedingungen funktionieren.

Parallel dazu müssen zwei Bereiche sichergestellt werden, die in der Hektik des Launches leicht vergessen werden: SEO und Analytics. Ein sorgfältiger SEO-Audit – mit Prüfung aller 301-Redirects, Meta-Daten, Sitemaps und URL-Strukturen – ist Pflicht, bevor der DNS-Wechsel erfolgt. Ein SEO-Ranking-Verlust nach einem Relaunch ist schwer reparierbar und kann Monate dauern. Ebenso müssen alle Tracking-Mechanismen vor dem Go-Live vollständig validiert sein – ohne funktionierende Analytics-Daten ist datengetriebenes Optimieren nach dem Launch schlicht nicht möglich.

Die Go-Live-Agenda selbst muss klar strukturiert, mit allen Beteiligten abgestimmt und realistisch kalkuliert sein. Zugang zum Domain-Hosting, Deployment-Berechtigungen und ein definierter Rollback-Plan gehören zwingend dazu – nicht als Absicherung für den Worst Case, sondern als Zeichen professioneller Vorbereitung. Nach dem Launch schließt sich eine Hypercare-Phase an, in der dedizierte Support-Ressourcen bereitstehen, um dringende Bugs und Anpassungen schnell zu adressieren. Dass nach einem Go-Live kleinere Fehler auftreten, ist normal und kein Versagen – entscheidend ist, dass klare Prozesse für ihre Priorisierung und Behebung vorhanden sind.

Do's und Don'ts

✅ Umfassenden SEO-Crawl vor dem Go-Live durchführen – URL-Mappings, Redirects und Meta-Daten müssen geprüft sein, bevor der DNS-Wechsel erfolgt.

✅ Rollen und Verantwortlichkeiten beim Testing klar definieren – Wer testet was? Integrations- und End-to-End-Tests erfordern ausreichend Ressourcen aus IT, Vertrieb, Buchhaltung und Kundenservice – nicht nur aus der Entwicklungsagentur.

✅ Projektdokumentation vollständig und aktuell halten – Mappings, Konfigurationen, Workarounds und Systemdiagramme müssen gepflegt sein. Eine lückenhafte Dokumentation verlängert die Fehlersuche und gefährdet den stabilen Betrieb.

✅ Hypercare-Phase fest einplanen – Nach jedem Go-Live treten Bugs und Edge Cases auf. Entscheidend ist, dass Ressourcen und Prozesse für die schnelle Behebung vorhanden sind.

❌ Testing-Freigabe ohne interne QA-Vorabprüfung – Der E-Commerce Owner sollte erst dann mit eigenem Testing beginnen, wenn das QA-Team der Agentur seinen Teil abgeschlossen hat. Andernfalls entstehen unnötige Rückfragen und Verwirrung über Prioritäten.

❌ Offene Fragen in der Go-Live-Agenda – Zugang zu DNS-Hosting, Berechtigungen und Rollback-Verfahren müssen vor dem Go-Live-Tag vollständig geklärt sein. Missverständnisse in dieser Phase kosten Stunden, in denen der Shop nicht erreichbar ist.

❌ Nach dem Go-Live in Panik verfallen – Kleinere Fehler nach dem Launch sind kein Versagen, sondern die Regel. Klare Priorisierungs- und Bugfixing-Prozesse sind wichtiger als der Anspruch auf Perfektion am ersten Tag.

Fazit: Replatforming als strukturiertes Projekt, nicht als Ad-hoc-Entscheidung

Ein E-Commerce Replatforming ist keine technische Übung – es ist eine strategische Transformation. Die vier Phasen Entscheidung, Analyse, Konzeption & Umsetzung sowie Testing & Go-Live sind nicht willkürlich, sondern aufeinander aufbauend: Fehler in der Entscheidungsphase ziehen sich durch alle nachfolgenden Schritte. Eine oberflächliche Analyse rächt sich spätestens in der Implementierung. Und ein überstürzter Go-Live ohne solides Testing gefährdet Kundenzufriedenheit und Umsatz.

Wer die Leitlinien dieser vier Phasen konsequent verfolgt, Verantwortlichkeiten klar definiert und auf datenbasierte Entscheidungen setzt, schafft die Grundlage für ein Projekt, das nicht nur liefert – sondern das Unternehmen langfristig wettbewerbsfähiger macht.

Die gute Nachricht: **92 % der Unternehmen, die auf eine neue Plattform migriert haben, sind mit dem Ergebnis zufrieden oder sehr zufrieden.**1 Der Aufwand lohnt sich – wenn er strukturiert erfolgt.

Quellenverzeichnis

1. commercetools: State of eCommerce: Replatforming and Migration Trends 2024 (September 2024). 90 % der Unternehmen, die kürzlich migriert sind, verzeichneten Umsatz- und Verkaufssteigerungen; nur 14 % sind mit ihrer aktuellen Plattform zufrieden; 92 % der Migrierten sind zufrieden oder sehr zufrieden. Quelle: commercetools.com ↩

2. Swell: 25 Ecommerce Replatforming Statistics That Drive Growth in 2026. 83 % der Datenmigrations-Misserfolge entstehen durch unterschätzte Datenkomplexität und unzureichendes Testing.Quelle: swell.is ↩

Die Digitalisierung des B2B-Vertriebs ist kein Nice-to-have mehr, sondern geschäftskritisch. Doch die Realität sieht ernüchternd aus: Etwa zwei Drittel aller großen Tech-Projekte verfehlen ihre Ziele in Bezug auf Zeit, Budget oder Umfang.[^1] Bei B2B E-Commerce-Projekten kommen noch spezifische Herausforderungen hinzu – komplexe ERP-Integrationen, individuelle Kundenbeziehungen und vielschichtige Geschäftsprozesse.

Fast die Hälfte aller befragten C-Level-Führungskräfte berichtet, dass mehr als 30% ihrer Tech-Projekte über Budget und außerhalb der Timeline liegen.[^2] Doch was bedeutet "Scheitern" eigentlich konkret? Ein Projekt gilt als gescheitert, wenn es nicht innerhalb des vereinbarten Budgets und Zeitrahmens abgeschlossen wird oder wenn die Qualität des Ergebnisses die Erwartungen der Stakeholder nicht erfüllt. Oft zeigt sich das Scheitern auch darin, dass die neue Plattform nach dem Go-Live nicht die erhoffte Akzeptanz findet oder strategische Geschäftsziele verfehlt werden.

Im Folgenden beleuchten wir die kritischsten Gründe, warum B2B E-Commerce-Projekte scheitern – und zeigen konkrete Ansätze, wie Sie diese Fallstricke vermeiden können.

Strategische und konzeptionelle Defizite

Fehlende strategische Roadmap und unklare Ziele

Ein E-Commerce-Projekt ohne klare strategische Ausrichtung gleicht einer Seereise ohne Kompass. 37% aller Projekte scheitern aufgrund fehlender klarer Ziele.[^3] Viele Unternehmen starten ihre digitale Transformation, ohne zu definieren, welche konkreten Geschäftsziele erreicht werden sollen. Geht es um Umsatzsteigerung? Effizienzgewinne im Vertrieb? Bessere Customer Experience? Die Skalierung in neue Märkte?

Ohne messbare Ziele und eine dokumentierte Roadmap mit definierten Meilensteinen wird geraten statt geplant. Die Konsequenz: Das Projekt verliert an Fokus, Ressourcen werden ineffizient eingesetzt, und am Ende weiß niemand mehr genau, ob das Projekt erfolgreich war oder nicht.

Was Sie anders machen sollten: Definieren Sie vor Projektstart klare, messbare KPIs und Business-Ziele. Erstellen Sie eine strategische Roadmap, die nicht nur technische Meilensteine, sondern auch Geschäftsziele abbildet. Stellen Sie sicher, dass alle Stakeholder diese Ziele verstehen und mittragen. Wenn Sie unsicher sind, ob Ihr Unternehmen überhaupt reif für ein Replatforming ist, hilft unser Artikel "Anzeichen für ein E-Commerce Replatforming" bei der Orientierung.

Kostengetriebene Entscheidungen statt Value-orientierte Auswahl

Ein weiterer häufiger Fehler: Die Wahl der E-Commerce-Plattform und der Implementierungspartner erfolgt primär aus Kostensicht. Der günstigste Anbieter bekommt den Zuschlag, ohne dass die langfristigen Implikationen berücksichtigt werden. Diese Kostenoptimierung führt oft zu falschen Ankerpunkten bei der Schätzung von Projektaufwänden und Epics.

Das Problem dabei: Eine Plattform, die nicht zum Geschäftsmodell passt, verursacht später erhebliche Folgekosten. B2B-Commerce hat spezifische Anforderungen – von komplexen Preisstrukturen über mehrstufige Genehmigungsprozesse bis hin zu kundenindividuellen Katalogen. Wird eine B2C-Lösung auf B2B-Anforderungen aufgepfropft, sind Probleme vorprogrammiert.

Was Sie anders machen sollten: Evaluieren Sie Plattformen und Partner nicht nur nach Kosten, sondern nach strategischem Fit. Welche Plattform unterstützt Ihr Geschäftsmodell am besten? In unserem Artikel "B2B Portal-Archetypen" zeigen wir die unterschiedlichen B2B-Geschäftsmodelle und ihre technischen Anforderungen. Lesen Sie auch unseren Artikel über "das richtige technologische Fundament" für weitere Orientierung.

Unzureichende Anforderungsanalyse und Konzeption

Inadäquate Projektplanung ist der häufigste Grund für Projektscheitern.[^4] Viele Projekte starten mit unzureichender Anforderungsanalyse. Requirements werden nicht sauber dokumentiert, Abhängigkeiten zwischen Systemen nicht erkannt, und komplexe Integrationen – etwa mit ERP, PIM oder CRM – werden unterschätzt.

Besonders kritisch: Viele Projekte verzichten auf Proof of Concepts (PoCs) für kritische Integrationen, obwohl diese frühzeitig technische Risiken identifizieren könnten. Moderne Integration-Plattformen wie n8n[^13] ermöglichen es, Integrations-Szenarien kostengünstig zu testen, bevor sie in der produktiven Umgebung implementiert werden.

Was Sie anders machen sollten: Investieren Sie Zeit in eine gründliche Konzeptionsphase. Erstellen Sie detaillierte Systemarchitektur-Charts (IST vs. SOLL), dokumentieren Sie Datenflüsse und führen Sie PoCs für kritische Integrationen durch. Diese initiale Investition zahlt sich vielfach aus, indem sie teure Überraschungen in späteren Projektphasen vermeidet.

Politisch getriebene statt bedarfsorientierte Projekte

Ein unterschätztes Problem: Projekte, die top-down aus politischen Gründen initiiert werden, ohne dass ein echter Business-Need besteht. Das Management fordert einen schnellen Go-to-Market, das Budget wird knapp gehalten, und die tatsächlichen Anforderungen der Anwender werden nicht erhoben. Das Ergebnis sind Projekte, die zwar pünktlich gelauncht werden, aber an den echten Bedürfnissen der Nutzer vorbeigehen.

Was Sie anders machen sollten: Stellen Sie sicher, dass E-Commerce-Projekte bottom-up legitimiert sind. Holen Sie die relevanten Stakeholder ab – sowohl Kunden als auch Mitarbeiter, die täglich mit dem System arbeiten. Ein echter Business-Need sollte die Grundlage jeder Investition sein.

Organisatorische Herausforderungen und Governance-Probleme

E-Commerce als IT-Projekt statt als Change Management

Der vielleicht gravierendste Fehler: Ein E-Commerce-Projekt wird als rein technisches IT-Projekt verstanden, nicht als organisatorischer Change-Prozess. Etwa 70% der Change-Management-Initiativen scheitern, und McKinsey berichtet, dass 70% aller digitalen Transformationen ihre Ziele aufgrund mangelnder Berücksichtigung der menschlichen Dimension verfehlen.[^5] Deloitte fand heraus, dass 82% aller Transformationsprojekte aufgrund von Mitarbeiterwiderstand scheitern.[^6]

Die Symptome sind vielfältig: Das Vertriebsteam fürchtet, dass der neue Shop ihnen Provisionen wegnimmt. Der Kundenservice hat Angst vor der neuen Software. Produktmanager wehren sich gegen neue Workflows. Ohne aktives Change Management wird selbst die beste Technologie scheitern, weil die User Adoption ausbleibt.

Studien zeigen, dass Unternehmen, die Change-Management-Techniken anwenden, die Adoption um 72% steigern und die Mitarbeiterfluktuation um fast 10% reduzieren können.[^7] Der Schlüssel liegt darin, dass Mitarbeiter nicht nur technisch geschult werden, sondern auch emotional auf die Veränderung vorbereitet werden.

Was Sie anders machen sollten: Behandeln Sie E-Commerce-Projekte als Change-Management-Initiativen. Kommunizieren Sie frühzeitig und transparent, warum die Veränderung notwendig ist. Involvieren Sie Mitarbeiter in Entscheidungen, bieten Sie umfassende Schulungen an und schaffen Sie Change Agents in verschiedenen Abteilungen. Planen Sie ausreichend Zeit für Training und Onboarding ein – nicht nur technisch, sondern auch für die Prozessumstellung.

Fehlende Stakeholder-Alignment und unklare Verantwortlichkeiten

Mangelnde Ausrichtung zwischen Business und IT bezüglich operationaler Ziele, unrealistische Timelines und unzureichende Ressourcen sind die drei Hauptgründe für IT-Projekt-Fehlschläge.[^8] E-Commerce betrifft alle Abteilungen – Marketing, Vertrieb, Operations, IT, Kundenservice. Wenn diese Bereiche nicht auf gemeinsame Ziele ausgerichtet sind und ihre Verantwortlichkeiten nicht klar definiert sind, entstehen Konflikte.

Besonders problematisch wird es, wenn Ownership unklar ist: Wer ist verantwortlich für Requirements Engineering? Wer nimmt implementierte Features ab? Wer entscheidet bei Change Requests? Ohne klare Governance-Strukturen und Entscheidungswege entsteht Bürokratie, die das Projekt lähmt.

Hinzu kommt: Wenn unterschiedliche Parteien unterschiedliche Anreize haben – etwa eine Design-Agentur auf Time & Material-Basis und eine Development-Agentur mit Fixpreis – sind Interessenskonflikte vorprogrammiert.

Was Sie anders machen sollten: Etablieren Sie von Anfang an klare Governance-Strukturen. Definieren Sie eindeutig, wer für welche Entscheidungen verantwortlich ist. Nutzen Sie RACI-Matrizen (Responsible, Accountable, Consulted, Informed), um Verantwortlichkeiten zu klären. Stellen Sie sicher, dass alle Partner – intern wie extern – aufeinander abgestimmte Anreize haben.

Unrealistische Timelines und fehlende Puffer

78% der Projekte erleben Zeitüberschreitungen, und 58% überschreiten ihr Budget.[^9] Ein häufiges Problem: Die Timeline wird vom Business vorgegeben, nicht von der technischen Realität. Es wird zu wenig Zeit für Testing eingeplant, Schulungen werden auf das absolute Minimum reduziert, und Puffer für unvorhergesehene Probleme fehlen komplett.

Das Ergebnis: Stress im Team, Qualitätsprobleme beim Launch und ein unausgereiftes System, das nach Go-Live massive Nacharbeiten erfordert.

Was Sie anders machen sollten: Planen Sie realistisch und bauen Sie Puffer ein – mindestens 20-30% für Unvorhergesehenes. Priorisieren Sie ausreichend Zeit für Testing (Unit-Tests, Integrationstests, User Acceptance Tests) und Schulungen. Lassen Sie die Timeline von den technischen Experten mitbestimmen, nicht nur vom Business.

Fehlende MVP-Mentalität und zu großer Scope

Ein klassischer Fehler: Man versucht, von Anfang an alles perfekt zu machen. Der initiale Scope ist riesig, alle denkbaren Features werden geplant, und das Projekt wird monolithisch aufgesetzt. Das Problem: Je größer der Scope, desto höher die Komplexität und das Risiko.

Die MVP-Mentalität (Minimum Viable Product) hat sich im E-Commerce als erfolgreicher Ansatz etabliert, weil sie es ermöglicht, schnell Kundenfeedback zu sammeln und iterativ zu verbessern.[^10] Statt zwei Jahre an einer Komplett-Lösung zu arbeiten, launchen erfolgreiche Unternehmen in 3-4 Monaten ein funktionales MVP und bauen es dann kontinuierlich aus.

Was Sie anders machen sollten: Starten Sie schlank mit einer MVP-Mentalität. Identifizieren Sie die absolut notwendigen Kernfunktionalitäten (Must-Haves) und trennen Sie diese von Nice-to-Haves. Launchen Sie schnell, sammeln Sie Feedback von echten Nutzern und iterieren Sie. Planen Sie von Anfang an mit Skalierung – sowohl technisch als auch organisatorisch.

Post-Go-Live-Phase nicht geregelt

Viele Projekte enden offiziell mit dem Go-Live. Doch die Realität sieht anders aus: Der Go-Live ist nicht das Ende, sondern der eigentliche Beginn der produktiven Phase. Erst jetzt "arbeitet" das System wirklich – mit echten Kunden, realen Bestellungen und tatsächlichen Geschäftsprozessen.

In der Testphase lassen sich nicht alle Szenarien abbilden. Erst wenn echte B2B-Kunden mit individuellen Konditionen bestellen, wenn komplexe Preisregeln unter Realbedingungen greifen und wenn die Integration mit ERP und Logistik im Live-Betrieb läuft, zeigen sich die tatsächlichen Herausforderungen. Edge Cases, die im Testing nicht auffielen, werden plötzlich sichtbar. Prozesse, die auf dem Papier funktionierten, müssen in der Praxis nachgeschärft werden.

Wenn nicht klar ist, wer das System in dieser kritischen Phase wartet, wie Support organisiert wird und wie kontinuierliche Weiterentwicklung erfolgt, gerät das Projekt schnell in Schieflage. Das Team, das das Projekt umgesetzt hat, ist oft bereits beim nächsten Projekt, und niemand fühlt sich verantwortlich für die notwendigen Anpassungen und Optimierungen.

Was Sie anders machen sollten: Definieren Sie bereits vor dem Go-Live, wie die Post-Launch-Phase aussieht. Wer ist verantwortlich für Monitoring, Bugfixes und Weiterentwicklung? Welches Budget steht für kontinuierliche Optimierung zur Verfügung? Planen Sie eine intensive Betreuungsphase für die ersten 3-6 Monate nach Go-Live ein, in der das Team verfügbar bleibt, um auf Erkenntnisse aus dem Live-Betrieb zu reagieren. Etablieren Sie regelmäßige Reviews basierend auf echten Nutzungsdaten und Kundenfeedback – ein E-Commerce-System ist nie "fertig", sondern entwickelt sich kontinuierlich weiter.

Technische und Delivery-Probleme

Internes Team ohne Skills und Erfahrung

Viele Unternehmen versuchen, E-Commerce-Projekte mit internen Teams umzusetzen, die weder über die notwendigen technischen Skills noch über Projekterfahrung verfügen. Ein Projektmanager ohne E-Commerce-Erfahrung oder ein Developer-Team ohne Kenntnisse der gewählten Plattform – das führt unweigerlich zu Problemen.

Was Sie anders machen sollten: Investieren Sie in Expertise – entweder durch gezieltes Upskilling interner Mitarbeiter oder durch die Zusammenarbeit mit erfahrenen Partnern. In unserem Artikel "E-Commerce Replatforming: Inhouse-Entwicklung vs. externe Agentur" beleuchten wir die Vor- und Nachteile beider Ansätze.

Unterschätzte und schlecht konzipierte Integrationen

50% aller ERP-Integrationen verfehlen den erwarteten ROI aufgrund mangelhafter Planung. Gartner berichtet, dass 70% aller ERP-Projekte ihre Geschäftsziele verfehlen, weil kritische Datenschnittstellen zusammenbrechen.[^11] Integrationen – sei es mit ERP, PIM, CRM oder Payment-Providern – werden in ihrer Komplexität chronisch unterschätzt.

Das Problem liegt oft in fehlender Datenkompatibilität, unzureichender Standardisierung und schwachen Synchronisationsmechanismen. Wenn die Datenarchitektur nicht sauber konzipiert ist, führt das zu Problemen: Man weiß nicht genau, wo welche Daten "geboren" werden, wo Stammdaten liegen und wie Prozesse abgebildet werden sollen.

Was Sie anders machen sollten: Nehmen Sie Integrationen ernst. Erstellen Sie detaillierte Datenfluss-Diagramme und definieren Sie klar, welches System "Source of Truth" für welche Daten ist. Testen Sie Integrationen früh und umfassend, nicht erst kurz vor dem Go-Live. Verwenden Sie moderne Integration-Patterns und -Plattformen, die Flexibilität und Skalierbarkeit bieten.

Plattform passt nicht zum Geschäftsmodell

Ein fundamentales Problem: Die gewählte E-Commerce-Plattform passt nicht zu den tatsächlichen Geschäftsanforderungen. B2B-Unternehmen benötigen Features wie Gated Login, Account-Hierarchien, komplexe Preisregeln und ERP-Integration – Features, die viele Standard-B2C-Plattformen nicht bieten.

Was Sie anders machen sollten: Wählen Sie die Plattform basierend auf Ihrem Geschäftsmodell. Unser Artikel über "Open-Source Software als Gamechanger für B2B Commerce" zeigt, warum gerade im B2B-Bereich flexible, anpassbare Plattformen oft die bessere Wahl sind.

Unzureichende Go-Live-Vorbereitung

Der Go-Live ist ein kritischer Moment – und wird oft unterschätzt. Fehlende umfassende Integrationstests, keine Berücksichtigung von Edge Cases und unzureichende Datenmigration führen zu katastrophalen Live-Fehlern. Wenn der Cutover nicht sauber geplant ist, drohen Datenverluste, System-Ausfälle und frustrierte Kunden.

Was Sie anders machen sollten: Planen Sie den Go-Live minutiös. Führen Sie umfassende Tests durch – nicht nur Happy-Path-Szenarien, sondern auch Edge Cases. Erstellen Sie einen detaillierten Cutover-Plan mit Rollback-Strategie. Testen Sie die Datenmigration mehrfach in einer Staging-Umgebung. Planen Sie ausreichend Support-Kapazität für die ersten Tage nach dem Launch ein.

Organisatorische Ressourcen nicht vorbereitet

Ein unterschätztes Problem: Die bestehenden Teams (Kundenservice, IT, Vertrieb) machen das Projekt "nebenher", ohne wirklich Zeit dafür zu haben. Die Organisation wird nicht auf die neue Realität vorbereitet, Prozesse werden nicht angepasst, und Mitarbeiter sind überfordert.

Was Sie anders machen sollten: Bereiten Sie Ihre Organisation rechtzeitig vor. Schaffen Sie dedizierte Ressourcen für das Projekt. Passen Sie Prozesse und Team-Strukturen an die neue E-Commerce-Realität an. Stellen Sie sicher, dass Teams nicht nur "nebenher" arbeiten, sondern fokussierte Kapazitäten haben.

Wie Sie es besser machen: Praktische Handlungsempfehlungen

1. Strategische Vorbereitung

• Definieren Sie klare, messbare Geschäftsziele und KPIs

• Erstellen Sie eine strategische Roadmap mit Meilensteinen

• Stellen Sie sicher, dass ein echter Business-Need besteht

• Holen Sie alle relevanten Stakeholder ab

2. Die richtige Technologie-Wahl

• Wählen Sie Plattform und Partner nach strategischem Fit, nicht nur nach Kosten

• Berücksichtigen Sie Ihr spezifisches B2B-Geschäftsmodell

• Setzen Sie auf flexible, skalierbare Architekturen

• Führen Sie PoCs für kritische Integrationen durch

3. Organisatorische Excellence

• Behandeln Sie das Projekt als Change Management, nicht nur als IT-Projekt

• Etablieren Sie klare Governance-Strukturen und Verantwortlichkeiten

• Investieren Sie in Change Management und Training

• Planen Sie realistische Timelines mit ausreichend Puffer

4. Technische Expertise

• Stellen Sie sicher, dass Sie die notwendige Expertise haben – intern oder extern

• Erstellen Sie detaillierte Systemarchitektur- und Datenfluss-Diagramme

• Nehmen Sie Integrationen ernst und testen Sie früh

• Planen Sie den Go-Live minutiös mit Rollback-Strategie

5. MVP-Mentalität und kontinuierliche Verbesserung

• Starten Sie schlank mit einem funktionalen MVP

• Sammeln Sie frühzeitig Feedback von echten Nutzern

• Iterieren Sie kontinuierlich basierend auf Daten und Feedback

• Planen Sie Post-Launch-Support und Weiterentwicklung ein

Fazit: Erfolgreiche E-Commerce-Projekte sind planbar

Die hohe Failure-Rate von B2B E-Commerce-Projekten ist keine Naturgewalt, sondern das Ergebnis vermeidbarer Fehler. Während etwa zwei Drittel aller Tech-Projekte ihre Ziele verfehlen, zeigen erfolgreiche Projekte klare Muster: strategische Planung, klare Governance, ausreichende Ressourcen und eine konsequente MVP-Mentalität.[^12]

Der Schlüssel zum Erfolg liegt nicht in der perfekten Technologie, sondern in der richtigen Vorbereitung, klaren Zielen, realistischer Planung und der Bereitschaft, iterativ zu arbeiten. Starten Sie schlank, lernen Sie schnell, und verbessern Sie kontinuierlich. So wird Ihr E-Commerce-Projekt nicht zur Statistik, sondern zum strategischen Erfolg.

Fußnoten

[^1]: BCG, "Most Large-Scale Tech Programs Fail: How to Succeed" (2024). Two-thirds of large-scale tech programs miss targets on time, budget, and scope. More than €20 billion in tech investments go to waste every year as a result of failed large-scale programs. Quelle: BCG.com

[^2]: BCG Build for the Future Study (2024). Nearly half of all C-suite executives said that more than 30% of their organization's technology development projects were over budget and late. Quelle: BCG.com

[^3]: Project Management Institute (PMI), Pulse of the Profession (2017). 37% of projects fail due to a lack of clear goals and objectives. Quelle: TransparentChoice.com

[^4]: TeamStage Project Management Statistics (2024). Inadequate project planning is the number one reason for project failure. Quelle: TeamStage.io

[^5]: McKinsey & Company, "Common Pitfalls in Transformations" (2022). 70% of transformations fail. Contributing factors include insufficiently high aspirations, lack of engagement within the organization, and insufficient investment in building capabilities. Quelle: McKinsey.com

[^6]: Deloitte Research via Dayforce (2024). 82% of transformation efforts fail due to employee resistance. Quelle: Dayforce.com

[^7]: Prosci Change Management Research & Milestone Task (2025). Companies applying change management techniques increased adoption success rates to 88%, compared to just 13% where change management is poor. Organizations with excellent change management are 7× more likely to meet objectives. Quelle: MilestoneTask.com

[^8]: BCG Build for the Future Study (2024). Lack of alignment between technology and business sides regarding operational goals, unrealistic timelines, and insufficient resources are the three top reasons for IT failures. Quelle: BCG.com

[^9]: Academic Study on IT Project Performance cited by PM 360 Consulting (2023). 78% of projects experienced time overruns, and 58% experienced cost overruns. Quelle: PM360Consulting.ie

[^10]: E-Commerce Best Practices: MVP approach enables quick customer feedback collection and iterative improvement, reducing time-to-market significantly. Agile and iterative approaches have become standard in successful E-Commerce implementations. Quelle: E-Commerce Industry Best Practices

[^11]: Various Industry Reports including Gartner Research. 50% of ERP integrations fail to achieve expected ROI due to poor planning; 70% of ERP projects fail to meet business goals due to critical data interface failures and datenkompatibilitätsprobleme. Quelle: Gartner Research

[^12]: BCG Build for the Future Study (2024). Champions (30% of companies) met timeline, budget, and scope expectations through strategic planning, clear governance, adequate resources, and realistic expectations. Quelle: BCG.com

[^13]: n8n - Fair-code Workflow Automation Platform. Open-source Workflow-Automation-Plattform mit über 400+ Integrationen, die es technischen Teams ermöglicht, Automationen und Proof of Concepts schnell zu erstellen. Quelle: n8n.io

„Wir brauchen ein B2B-Portal" – dieser Satz fällt in Strategiemeetings vieler Unternehmen. Doch was auf den ersten Blick wie eine klare Anforderung klingt, entpuppt sich bei genauerer Betrachtung als strategische Weichenstellung mit weitreichenden Konsequenzen. Denn: Das eine B2B-Portal gibt es nicht.

Im Gegensatz zu B2C-Shops, die trotz aller Individualisierung einem erkennbaren Grundmuster folgen – Produktkatalog, Warenkorb, Checkout, Zahlung – sind B2B-Portale hochgradig heterogen. Der Grund liegt in der fundamentalen Natur von B2B-Geschäften: Sie digitalisieren keine standardisierten Kaufprozesse, sondern komplexe Geschäftsprozesse, die tief in die Wertschöpfungsketten beider Parteien eingebettet sind.

Warum B2B-Projekte keine Standard-Shops sind

Der entscheidende Unterschied: B2B-Kunden „arbeiten" mit Ihrem Portal, sie „shoppen" nicht. Während B2C-Käufer Endprodukte für den persönlichen Gebrauch erwerben, beschaffen B2B-Einkäufer Güter und Dienstleistungen, die sie in eigene Produkte oder Dienstleistungen weiterverarbeiten. Die Transaktion ist damit kein isolierter Akt, sondern ein integraler Bestandteil komplexer Geschäftsprozesse.

Die Zahlen sprechen eine klare Sprache: B2B-Transaktionen involvieren typischerweise mehrere Stakeholder und längere Entscheidungszyklen. Laut einer aktuellen Studie sind 73% der B2B-Käufer mittlerweile bereit, Bestellungen von $500.000 oder mehr online zu tätigen – ein Anstieg von 59% im Jahr 2022.[^1] Diese hohen Transaktionswerte und die Komplexität der zugrunde liegenden Geschäftsprozesse erfordern spezialisierte Plattformen, die weit über die Funktionalität eines B2C-Shops hinausgehen.

Die Konsequenz: B2B-Plattformen müssen sich fundamental unterschiedlichen Use Cases anpassen. Ein Produktionsunternehmen, das monatlich Tausende Schrauben nachbestellt, hat völlig andere Anforderungen als ein Maschinenbauer, der Ersatzteile und Wartungsverträge für individuell konfigurierte Anlagen anbietet. Ein Distributor, der hunderte Wiederverkäufer mit kundenspezifischen Konditionen bedient, benötigt andere Funktionen als ein Hersteller, der einen Online-Katalog für Vertriebsmitarbeiter bereitstellt.

Bevor Sie also in ein B2B-Projekt investieren, müssen Sie die strategische Grundfrage beantworten: Welcher Portal-Archetyp bildet Ihr Geschäftsmodell optimal ab?

Die sechs B2B Portal Archetypen

Im Folgenden stellen wir die wichtigsten Portal-Typen vor, ihre charakteristischen Merkmale und die Geschäftsmodelle, für die sie konzipiert sind.

1. Online-Katalog / Digitaler Produktkatalog

Der Online-Katalog ist offen zugänglich ohne Login-Pflicht und verzichtet bewusst auf E-Commerce-Funktionen oder Checkout-Prozesse. Der Fokus liegt vollständig auf Produktpräsentation und Information – mit minimaler technischer Integration, primär einer PIM-Abbildung (Product Information Management). Produkte werden mit vollständiger Transparenz und technischen Details dargestellt. Dieser Archetyp eignet sich für Unternehmen, deren Produkte erklärungsbedürftig sind und bei denen der Verkauf primär über persönliche Beratung erfolgt. Die Conversion findet nicht im Portal statt – das Portal ist vielmehr ein Enabler für Vertriebsprozesse. Studien zeigen, dass 72% der Befragten angeben, dass Kataloge ihr Interesse an Produkten steigern, und 84% kaufen Produkte, nachdem sie diese in einem Katalog gesehen haben.[^2]

Typische Funktionen:

• Detaillierte Produktbeschreibungen mit technischen Spezifikationen

• Hochwertige Produktbilder, 360°-Ansichten oder 3D-Modelle

• Erweiterte Such- und Filterfunktionen

• PDF-Export von Produktdatenblättern

• Anfrage- und RFQ-Formulare (Request for Quote)

• Kontaktmöglichkeiten zu Vertriebsmitarbeitern

Zielgruppen und Use Cases:

• Hersteller komplexer technischer Produkte: Maschinenbau, Industrieausrüstung, Spezialbauteile

• Außendienst und Vertrieb: Produktvorführungen bei Kunden ohne physische Muster

• Messen und Trade Shows: Digitale Kataloge als Ersatz für gedruckte Broschüren

• Beratungsintensive Produkte: Konfigurierbare oder kundenspezifische Lösungen, bei denen der Kaufprozess offline erfolgt

2. Kundenportal / After-Sales-Portal

Das Kundenportal ist login-basiert und personalisiert, mit einem klaren Fokus: Die große Conversion ist bereits erfolgt. Es geht um After-Sales-Leistungen und Self-Service für administrative Aufgaben. Kunden erhalten Zugriff auf Dokumente und Archive sowie individualisierten Content basierend auf ihrer Kundenbeziehung. Kundenportale adressieren ein wachsendes Bedürfnis: 70% der Kunden erwarten, dass die Website eines Unternehmens eine Self-Service-Anwendung beinhaltet.[^3] Durch die Implementierung von Self-Service-Portalen können Unternehmen ihre Kundenservice-Kosten um bis zu 30% reduzieren.[^4] Gleichzeitig steigern sie die Kundenzufriedenheit, da Kunden 24/7 auf relevante Informationen zugreifen können, ohne auf Supportmitarbeiter angewiesen zu sein.

Typische Funktionen:

• Bestellhistorie und Order-Tracking

• Zugriff auf Rechnungen, Lieferscheine, Garantiedokumente

• Support-Ticket-System

• Individuelle FAQ und Knowledge Base

• Vertragsverwaltung und Renewal-Management

• Account-Management (Stammdaten, Zahlungsmethoden)

Zielgruppen und Use Cases:

• Service-orientierte B2B-Unternehmen: SaaS-Anbieter, Beratungsfirmen, Versicherungen

• Wiederkehrende Geschäftsbeziehungen: Kunden mit langfristigen Verträgen oder Abonnements

• Komplexe Kundenstrukturen: Konzerne mit mehreren Standorten, unterschiedlichen Abteilungen und individuellen Konditionen

3. Self-Service / Ersatzteil- und Wartungsportal

Das Self-Service-Portal ist login-basiert mit kundenspezifischer Konfiguration und bietet transaktionale Funktionen für spezifische After-Sales-Prozesse. Die Integration mit Service-Management-Systemen steht im Mittelpunkt, mit klarem Fokus auf Effizienz und Autonomie des Kunden. Self-Service-Portale entlasten nicht nur den Kundenservice, sondern verkürzen auch kritische Reaktionszeiten. Eine aktuelle Studie von Spryker und Statista+ zeigt: 95% der B2B-Käufer glauben, dass Self-Service-Portale die Einkaufseffizienz verbessern, wobei zwei Drittel zwischen 30 und 60 Minuten pro Transaktion einsparen.[^5] Wenn eine Produktionsmaschine ausfällt, kann der Techniker eigenständig das benötigte Ersatzteil identifizieren und bestellen – ohne Wartezeit auf einen Account Manager oder Supportmitarbeiter.

Typische Funktionen:

• Retourenmanagement und RMA (Return Material Authorization)

• Ersatzteilbestellung mit Explosionszeichnungen oder Digital Twins

• Buchung von Wartungsterminen und Serviceeinsätzen

• Zugang zu Schulungen, Trainings und Zertifizierungen

• Garantie- und Gewährleistungsabwicklung

• Download technischer Dokumentationen und Handbücher

Zielgruppen und Use Cases:

• Maschinenbauer und Anlagenhersteller: Kunden benötigen schnellen Zugriff auf Ersatzteile für produktionskritische Maschinen

• Medizintechnik: Service und Wartung medizinischer Geräte mit strikten Compliance-Anforderungen

• Automotive Aftermarket: Ersatzteilversorgung für Werkstätten und Händler

• IT- und Telekommunikation: Garantieabwicklung und Reparaturservices

4. Einkaufsportal / Beschaffungsportal

Das Einkaufsportal bietet vollständige E-Commerce-Funktionalität mit Checkout und zeichnet sich durch kundenindividuelle Preise, Rabatte und Konditionen aus. Komplexe Rechte- und Rollenkonzepte ermöglichen mehrstufige Freigabeprozesse, während die Integration mit Procurement-Systemen der Kunden über Business-Rules und Approval-Workflows erfolgt. Einkaufsportale digitalisieren repetitive Beschaffungsprozesse und schaffen Transparenz. Unternehmen, die auf strukturierte Procurement-Workflows setzen, profitieren von der Automatisierung und der Integration in bestehende ERP-Landschaften.

Typische Funktionen:

• Kundenspezifische Produktkataloge und Sortimente

• Staffelpreise und Volume-basierte Discounts

• Angebotsanfragen (RFQ) und Tender-Management

• Rechte- und Rollenmanagement mit mehrstufigen Freigabeprozessen

• OCI Punchout und cXML-Integration für Procurement-Systeme

• Credit Terms und flexible Zahlungsbedingungen (NET 30/60/90)

• Budgetverwaltung und Kostenstellen-Zuordnung

Zielgruppen und Use Cases:

• Produzierendes Gewerbe: Unternehmen, die Rohmaterialien, Komponenten oder MRO-Artikel (Maintenance, Repair, Operations) beschaffen

• Großhandel und Distribution: Wiederverkäufer, die Waren zur Weiterveräußerung einkaufen

• Procurement-Abteilungen: Einkaufsteams mit strukturierten Beschaffungsprozessen und ERP-Integration

• Franchise-Systeme: Zentrale Beschaffung für Filialen oder Partner-Standorte

🔧 TECHNOLOGIE-HIGHLIGHT: OCI Punchout

Eine Schlüsseltechnologie für moderne Einkaufsportale ist OCI Punchout (Open Catalog Interface). OCI ermöglicht es Käufern, direkt aus ihrem ERP-System (z.B. SAP SRM) in den Live-Katalog des Lieferanten zu „punchen". Der Käufer sieht in Echtzeit Produktverfügbarkeit, kundenspezifische Preise und individuelle Kataloge – ohne Medienbruch.

Nach der Produktauswahl werden die Warenkorbdaten automatisch zurück ins ERP-System übertragen, wo der interne Genehmigungsprozess stattfindet.[^6] Diese nahtlose Integration eliminiert manuelle Dateneingaben, reduziert Fehlerquoten und beschleunigt den Procurement-Prozess erheblich.

5. Distributoren-Portal / Großhandelsportal

Das Distributoren-Portal fokussiert auf Bulk-Orders und Mengenrabatte, mit Multi-Warehouse-Unterstützung und komplexen Logistik- und Fulfillment-Anforderungen. Account-Management und Sales-Rep-Zuordnung sowie Tiered Pricing basierend auf Abnahmemengen sind zentrale Merkmale. Der durchschnittliche B2B-Transaktionswert liegt deutlich über B2C-Werten (B2C: $52 durchschnittlich).[^7] Großhandelsportale sind auf hohe Bestellvolumina, komplexe Versandlogistik und flexible Zahlungsbedingungen ausgelegt. Sie ermöglichen es Distributoren, hunderte oder tausende Wiederverkäufer effizient zu bedienen, ohne dass jede Bestellung manuell bearbeitet werden muss.

Typische Funktionen:

• Volume-basierte Preisstrukturen (Staffelpreise)

• Lagerbestandsanzeige in Echtzeit über mehrere Standorte

• Credit-Management und NET-Terms-Zahlungsbedingungen

• Schnellbestellung über SKU-Listen oder CSV-Upload

• Reorder-Funktionen und Favoriten-Listen

• RMA und Retouren-Management

• White-Labeling für Wiederverkäufer

Zielgruppen und Use Cases:

• Großhändler und Distributoren: Bedienung von Wiederverkäufern, Händlern und Partnern

• Hersteller mit Distributorennetzwerk: Indirekte Vertriebskanäle mit regionalen Partnern

• Wholesaler im B2B2C-Modell: Produkte werden an Wiederverkäufer geliefert, die an Endkunden verkaufen

• Import-/Export-Geschäfte: Internationale Handelsstrukturen mit komplexen Zollabwicklungen

6. Partner- / Händlerportal

Das Partner-Portal bietet Zugang für autorisierte Vertriebspartner und Dealer, kombiniert Commerce-Funktionen mit Enablement-Tools und ermöglicht Partner-Performance-Tracking sowie die Verwaltung von Exklusivitäten und territorialen Rechten. Partner-Portale sind mehr als nur Transaktionsplattformen – sie sind Enablement-Hubs. Sie statten Vertriebspartner mit den Tools und Informationen aus, die sie benötigen, um erfolgreich zu verkaufen. Der Fokus liegt auf langfristiger Partnerschaft und gemeinsamer Wertschöpfung.

Typische Funktionen:

• E-Commerce für Produktbestellungen und Demo-Material

• Marketing-Materialien und Co-Branding-Tools (Broschüren, Pitch Decks, Logos)

• Schulungen, Zertifizierungen und Onboarding-Programme

• Deal-Registration und Opportunity-Management

• Provision-Management und Incentive-Programme

• Market Development Funds (MDF) Management

• Partner-Performance-Dashboards und KPI-Tracking

Zielgruppen und Use Cases:

• Software- und SaaS-Anbieter: Channel-Partner-Programme für indirekte Vertriebskanäle

• Technologie-Hersteller: VAR-Partner (Value-Added Resellers) und System-Integratoren

• Exklusiv-Distributoren: Autorisierte Händler mit territorialen Rechten (z.B. Automobilmarken, Luxusgüter)

• Franchise-Systeme: Unterstützung von Franchise-Nehmern beim Verkauf und Marketing

Hybride Ansätze: Die Realität komplexer Geschäftsmodelle

In der Praxis sind reine Archetypen selten. Die meisten erfolgreichen B2B-Portale kombinieren Funktionen mehrerer Typen, um den spezifischen Anforderungen ihres Geschäftsmodells gerecht zu werden.

Häufige hybride Konstellationen:

• Einkaufsportal + Self-Service:
  Kunden können zu kundenindividuellen Konditionen einkaufen, haben aber gleichzeitig Zugriff auf einen Self-Service-Bereich für Rechnungen, Retouren, Schulungsbuchungen und Support-Tickets. Diese Kombination ist besonders für produzierende Unternehmen relevant, die sowohl Verbrauchsmaterialien nachbestellen als auch Wartungsverträge verwalten müssen.

• Online-Katalog + Self-Service:
  Ein Maschinenbauer präsentiert hochkomplexe, individuell konfigurierte Anlagen im Online-Katalog. Die eigentliche Transaktion erfolgt offline über den Vertrieb. Sobald die Maschine jedoch verkauft und installiert ist, können Kunden im Self-Service-Portal Ersatzteile bestellen, Wartungen buchen und auf technische Dokumentationen zugreifen.

• Distributoren-Portal + Partner-Portal:
  Ein Großhändler bedient sowohl Wiederverkäufer (Distributoren-Funktionen) als auch autorisierte Händler (Partner-Funktionen). Während Wiederverkäufer primär große Mengen zu Standardkonditionen beziehen, erhalten autorisierte Händler zusätzlich Zugang zu Marketing-Materialien, Schulungen und Performance-Tracking.

🎯 WEITERE EXOTISCHE TYPEN

• B2B Marketplace: Multi-Vendor-Plattformen, auf denen mehrere Lieferanten ihre Produkte anbieten (z.B. branchenspezifische Marktplätze für MRO, Medizintechnik oder Bau)

• E-Learning-Portale: Digitale Schulungs- und Zertifizierungsplattformen, oft als Zusatzmodul in Partner-Portalen integriert

• Financial/Transaction-Portale: Spezialisierte Portale für komplexe Abrechnungsmodelle, Subscription-basierte Services oder Finanzdienstleistungen

Die Flexibilität, verschiedene Archetypen zu kombinieren, ist ein entscheidender Erfolgsfaktor für moderne B2B-Plattformen.

Warum Open Source die ideale Basis für B2B-Portale ist

Die Vielfalt der B2B-Archetypen und die Notwendigkeit hybrider Ansätze führen zu einer zentralen Erkenntnis: Standardisierte SaaS-Lösungen stoßen bei komplexen B2B-Geschäftsmodellen schnell an ihre Grenzen. Die Gründe, warum Open Source im B2B-Commerce zum Gamechanger wird, haben wir bereits in einem früheren Beitrag ausführlich beleuchtet. Im Kontext der Portal-Archetypen wird diese strategische Bedeutung besonders deutlich.

Flexibilität für non-standard Prozesse

Jedes der beschriebenen Portal-Modelle bringt spezifische Anforderungen mit sich, die tief in die Geschäftsprozesse des Unternehmens eingebettet sind. Open-Source-Plattformen bieten die Flexibilität, genau die Funktionen zu entwickeln, die Ihr Geschäftsmodell erfordert:

• OCI Punchout und cXML-Integration: Seamless Integration in Procurement-Systeme wie SAP SRM, Ariba oder Coupa – ohne Abhängigkeit von vorgefertigten SaaS-Konnektoren

• Bonitätsprüfungen und Credit Management: Integration externer Bonitätsprüfungs-APIs für automatisierte Kreditlimit-Verwaltung bei Großhandelsgeschäften

• Externes CMS oder Knowledge Base: Anbindung spezialisierter Content-Management-Systeme für individualisierte FAQs, technische Dokumentationen oder Schulungsinhalte

• Individuelle Approval-Workflows: Mehrstufige Freigabeprozesse, die exakt Ihre internen Organisationsstrukturen abbilden

• ERP-, CRM- und PIM-Integration: Nahtlose Verbindung zu bestehenden Systemlandschaften ohne Vendor-Lock-in

Zukunftssicherheit durch Modularität

B2B-Geschäftsmodelle entwickeln sich kontinuierlich weiter. Was heute ein reines Einkaufsportal ist, kann morgen um Self-Service-Funktionen oder Partner-Enablement erweitert werden müssen. Open-Source-Architekturen mit modularen Ansätzen ermöglichen es, schrittweise zu wachsen und neue Funktionen zu integrieren, ohne die Plattform neu aufsetzen zu müssen.

Fazit: Die richtige Entscheidung für Ihr Geschäftsmodell

Die Wahl des richtigen B2B-Portal-Archetyps ist keine technische, sondern eine strategische Entscheidung – ebenso wie die Wahl der richtigen E-Commerce-Architektur als technologisches Fundament. Sie bestimmt, wie effizient Sie Ihre Geschäftsprozesse digitalisieren, wie gut Sie Ihre Kunden bedienen und wie agil Sie auf Marktveränderungen reagieren können.

Drei zentrale Handlungsempfehlungen:

1. Analysieren Sie Ihre Geschäftsprozesse: Welche Prozesse soll das Portal digitalisieren? Wer sind die Nutzer und was sind deren konkrete Use Cases? Erst wenn Sie diese Fragen beantwortet haben, können Sie den passenden Archetyp identifizieren.

2. Denken Sie hybrid: Die Wahrscheinlichkeit, dass Ihr Geschäftsmodell exakt einem Archetyp entspricht, ist gering. Planen Sie von Anfang an die Kombination verschiedener Funktionen ein.

3. Setzen Sie auf Flexibilität: B2B-Geschäftsmodelle sind komplex und entwickeln sich weiter. Wählen Sie eine technologische Basis – idealerweise Open Source – die mit Ihrem Unternehmen wachsen kann und Ihnen die Freiheit gibt, individuelle Anforderungen umzusetzen.

Die richtige B2B-Plattform ist kein Kostenfaktor, sondern ein strategischer Enabler. Sie sollte Ihre Geschäftsprozesse abbilden, nicht einschränken. Sie sollte Ihre Kunden produktiver machen, nicht frustrieren. Und sie sollte Ihnen die Kontrolle über Ihre digitale Zukunft geben – nicht Sie in Abhängigkeit bringen.

Die Frage ist nicht, ob Sie ein B2B-Portal benötigen, sondern welcher Archetyp Ihr Geschäftsmodell optimal unterstützt.

Quellenverzeichnis

[^1]: Shopify: B2B vs. B2C Ecommerce: 14 Differences to Consider (2025). 73% der B2B-Käufer sind bereit, Bestellungen von $500.000 oder mehr online zu tätigen (Anstieg von 59% in 2022). Quelle: Shopify.com

[^2]: Verschiedene Studien zu Katalogwirkung. 72% berichten gesteigertes Interesse durch Kataloge, 84% kaufen nach Katalogsichtung. Daten aus meiner vorherigen Recherche zum Online-Katalog-Archetyp.

[^3]: ASAR Digital: 10 Stats That Make the Case for B2B Self-Service Portal (August 2024). 70% der Kunden erwarten Self-Service-Funktionen auf Unternehmenswebsites. Quelle: ASARDigital.com

[^4]: ASAR Digital: 10 Stats That Make the Case for B2B Self-Service Portal (August 2024). Unternehmen können Kundenservice-Kosten um bis zu 30% durch Self-Service-Portale reduzieren. Quelle: ASARDigital.com

[^5]: Spryker & Statista+: Rise of Self-Service Portals in B2B Aftersales (April 2025). 95% der B2B-Käufer glauben, dass SSPs die Einkaufseffizienz verbessern; zwei Drittel sparen 30-60 Minuten pro Transaktion. Quelle: Spryker.com

[^6]: Greenwing Technology: What is OCI Punchout? How OCI Transforms B2B Procurement (März 2024). OCI ermöglicht es Käufern, aus ihrem ERP-System direkt in Live-Kataloge von Lieferanten zu „punchen" und Warenkorbdaten automatisch zurückzuübertragen. Quelle: GreenWingTechnology.com

[^7]: Verschiedene B2B-Studien zum durchschnittlichen Transaktionswert. B2C liegt bei durchschnittlich $52, B2B deutlich höher aufgrund von Bulk-Orders und komplexeren Produkten.

[^8]: Smart SaaS: B2B SaaS Fees & Costs Beyond the Price Tag (März 2025). SaaS-Anbieter nutzen API-Rate-Limits und Tiered-Pricing-Modelle: „Rate limits throttle how often apps can communicate unless you upgrade to a higher tier." Quelle: SmartSaaS.works

Diese Entscheidung ist weit mehr als eine Budget-Frage. Sie bestimmt die Projektgeschwindigkeit, die langfristige Flexibilität, den Wissensaufbau in Ihrer Organisation und letztlich den Erfolg Ihres Replatformings. Im Folgenden beleuchten wir die drei gängigen Ansätze – Inhouse-Entwicklung, externe Agentur und Hybrid-Modell – und geben Ihnen einen praxisorientierten Leitfaden zur Auswahl des richtigen Partners an die Hand.

Die fundamentale Frage: Inhouse, Agentur oder Hybrid?

Es gibt keine universell "richtige" Antwort auf diese Frage. Die optimale Entscheidung hängt von Ihren spezifischen Rahmenbedingungen ab: verfügbare Ressourcen, technische Expertise, Zeitdruck, Budget und langfristige strategische Ausrichtung. Laut aktuellen Studien wählen 66% der US-Unternehmen und über 90% der Fortune 500/G2000-Unternehmen den Outsourcing-Ansatz für Software-Entwicklung – vor allem aus Gründen der Kosteneffizienz, mangelnder Skills und Talentknappheit.1

Doch bevor wir in die Details eintauchen, ein wichtiger Hinweis: Diese Entscheidung ist nicht binär. Viele erfolgreiche Replatforming-Projekte kombinieren interne und externe Ressourcen strategisch, um das Beste aus beiden Welten zu nutzen.

Option 1: Inhouse-Entwicklung – Digitale Souveränität vs. Ressourcen-Realität

Die Entwicklung durch ein eigenes Team bietet auf den ersten Blick attraktive Vorteile, bringt jedoch auch erhebliche Herausforderungen mit sich.

Die Vorteile: Kontrolle, Wissen und Alignment

Vollständige Kontrolle über das Projekt: Ihre internen Mitarbeiter sind vollständig Ihrer Führung unterstellt. Sie können Prioritäten flexibel setzen, die Roadmap nach Belieben anpassen und haben direkten Zugriff auf das Team – keine Abstimmung mit externen Account Managern oder Verzögerungen durch konkurrierende Kundenprojekte.

Tiefes Verständnis für Geschäftsprozesse: Ihre Mitarbeiter kennen die Prozesse, Ziele und Herausforderungen des Unternehmens aus erster Hand. Diese Domain-Expertise kann die Entwicklung erheblich beschleunigen, da weniger Zeit für Erklärungen und Kontextualisierung benötigt wird. Sie verstehen nicht nur die technischen Requirements, sondern auch das "Warum" dahinter. Gerade im B2B-Commerce-Kontext mit hochkomplexen Prozessen – mehrstufigen Freigabe-Workflows, kundenindividuellen Preislogiken, verschachtelten Organisationsstrukturen oder spezifischen Bestellbedingungen – ist dieses implizite Wissen unbezahlbar. Externe Agenturen müssen sich diese Komplexität erst mühsam erarbeiten, was Wochen oder Monate dauern kann.

Interner Wissensaufbau: Jede Zeile Code, jede Architekturentscheidung und jede gelöste Herausforderung bleibt in Ihrer Organisation. Dieses Wissen geht nicht verloren, wenn ein Agenturvertrag endet. Sie bauen nachhaltige Expertise auf, die auch für zukünftige Projekte wertvoll ist.

Langfristige Kosteneffizienz: Bei kontinuierlicher Weiterentwicklung können interne Teams kostengünstiger sein als permanente Agenturbetreuung. Sie zahlen Gehälter statt Tagessätze, und bei langfristiger Betrachtung können die Gesamtkosten niedriger ausfallen – vorausgesetzt, das Team ist ausgelastet.

Direktere Kommunikation: Keine Kommunikationsbarrieren durch externe Dienstleister. Fragen können sofort geklärt werden, Feedback-Schleifen sind kürzer, und die Abstimmung mit anderen Abteilungen erfolgt natürlicher.

Die Herausforderungen: Skills, Skalierung und versteckte Kosten

Rekrutierung und Time-to-Hire: Das Einstellen qualifizierter Entwickler ist zeitaufwendig und teuer. Laut aktuellen Daten beträgt die durchschnittliche Time-to-Hire für Software-Entwickler in den USA etwa 35-41 Tage, wobei Senior-Positionen bis zu 20% länger dauern können.2 Bei spezialisierteren Rollen wie Senior Application Developers kann die Rekrutierung sogar 50-90 Tage in Anspruch nehmen.3 In Hochphasen wie Januar, wenn 62% aller Tech-Unternehmen gleichzeitig rekrutieren, kann sich dieser Zeitraum auf 12+ Wochen verdoppeln.4

Multidisziplinäres Skillset erforderlich: Ein E-Commerce-Replatforming erfordert nicht nur Backend-Entwickler. Sie benötigen Frontend-Entwickler für die Storefront, UX/UI-Designer für Nutzerfreundlichkeit, DevOps-Engineers für Infrastruktur und Deployment, SEO-Spezialisten für Sichtbarkeit, sowie QA-Engineers für Testing. Ein komplettes Team aufzubauen ist kostenintensiv und dauert Monate.

Know-how-Risiken und Fluktuation: Die durchschnittliche Fluktuationsrate im Tech-Bereich liegt bei etwa 17-18% pro Jahr, wobei Engineering-Rollen mit 12% die niedrigste Rate aufweisen.5 Dennoch bleibt das Risiko: Wenn ein Schlüsselmitarbeiter mit kritischem Plattform-Wissen das Unternehmen verlässt, kann das Projekt erheblich verzögert werden. Die Einarbeitung neuer Mitarbeiter dauert typischerweise 3-6 Monate, bis sie voll produktiv sind.

Fehlende Projekt-Erfahrung: Interne Teams haben möglicherweise noch nie ein Replatforming dieser Größenordnung durchgeführt. Ihnen fehlen die Best Practices, bewährte Patterns und die Erfahrung im Umgang mit typischen Fallstricken. Diese Lernkurve kann teuer werden – Fehler, die eine erfahrene Agentur vermieden hätte, kosten Zeit und Geld.

Begrenzte Skalierbarkeit: Wenn das Projekt in eine kritische Phase eintritt und mehr Ressourcen benötigt werden, können Sie nicht einfach "hochskalieren". Neue Mitarbeiter müssen rekrutiert und eingearbeitet werden, was Wochen oder Monate dauert. Bei Agenturen können zusätzliche Entwickler oft innerhalb von Tagen zugewiesen werden.

Versteckte Kosten: Die Gesamtkosten eines internen Teams gehen weit über die Gehälter hinaus. Sozialabgaben und Benefits können 25-35% der Gehaltssumme ausmachen. Softwarelizenzen für Entwicklungstools, IDEs, Testing-Tools und Projektmanagement-Software summieren sich. Weiterbildung und Konferenzen sind notwendig, um das Team aktuell zu halten. Office-Infrastruktur, Hardware und Arbeitsplatzausstattung müssen berücksichtigt werden. Laut Studien kostet der Ersatz eines Mitarbeiters durchschnittlich 33-50% des Jahresgehalts für Entry-Level-Positionen und bis zu 200-400% für Executive-Rollen.6

Option 2: Externe Agentur – Spezialisierung vs. Kontrollverlust

Die Zusammenarbeit mit einer spezialisierten Agentur bietet Zugang zu Expertise und Ressourcen, die intern schwer aufzubauen wären. Doch auch dieser Ansatz hat seine Schattenseiten.

Die Vorteile: Expertise, Geschwindigkeit und Risikominimierung

Tiefgreifende Plattform-Expertise: Spezialisierte Agenturen haben Dutzende ähnlicher Projekte umgesetzt. Sie kennen die Plattform in- und auswendig, wissen, wo die Fallstricke liegen, und haben bewährte Lösungen für typische Herausforderungen. Diese Erfahrung ist unbezahlbar – sie vermeiden Fehler, die Sie intern erst machen würden.

Multidisziplinäres Team out-of-the-box: Agenturen verfügen über komplette Teams: Entwickler (Frontend, Backend, Full-Stack), UX/UI-Designer, Projektmanager, DevOps-Engineers, SEO-Spezialisten und QA-Engineers. Sie müssen kein Team aufbauen – es steht sofort zur Verfügung.

Schnellere Time-to-Market: Durch ihre Erfahrung und bestehende Ressourcen können Agenturen Projekte oft schneller umsetzen. Sie kennen die kritischen Pfade, wissen, wie man Abhängigkeiten managt, und haben Prozesse, die Verzögerungen minimieren. Studien zeigen, dass die Nutzung von Outsourcing-Partnern die Time-to-Hire um 20-50% reduzieren kann im Vergleich zu internem Recruitment.7

Bewährte Prozesse und Methoden: Etablierte Agenturen haben ausgereifte Projektmanagement-Methoden – sei es Scrum, Kanban oder hybride Ansätze. Sie wissen, wie man Stakeholder managed, Scope-Creep verhindert und Risiken frühzeitig identifiziert.

Resilienz bei Personalwechsel: Wenn ein Agentur-Entwickler ausfällt oder das Projekt verlässt, ist das Problem der Agentur, nicht Ihres. Sie ersetzen die Person aus ihrem Talentpool, ohne dass Ihr Projekt ins Stocken gerät.

Synergien durch breites Leistungsspektrum: Viele Agenturen bieten mehr als nur Entwicklung – Design, SEO, Online-Marketing, Testing. Diese Synergien können wertvoll sein, wenn Sie nicht nur eine neue Plattform, sondern ein umfassendes digitales Erlebnis schaffen möchten.

Die Herausforderungen: Kontrolle, Transparenz und langfristige Abhängigkeit

Weniger direkte Kontrolle: Sie arbeiten mit einem externen Team, das auch andere Kunden betreut. Prioritäten können sich verschieben, und Sie haben nicht die gleiche Kontrolle wie über interne Mitarbeiter. Entscheidungen müssen über Account Manager und Projektleiter kommuniziert werden.

Kommunikationsbarrieren: Die Zusammenarbeit mit externen Entwicklern kann komplexer sein. Missverständnisse entstehen leichter, wenn nicht alle Beteiligten täglich im selben Büro oder Slack-Channel arbeiten. Allerdings haben Remote-Work-Trends diese Herausforderung deutlich reduziert – moderne Tools und Praktiken machen verteilte Teams heute deutlich effektiver als noch vor Jahren.8

Transparenz und Einblick: Bei agenturgeführtem Projektmanagement kann die Transparenz leiden. Wie viele Stunden werden tatsächlich an Ihrem Projekt gearbeitet? Welche Entwickler arbeiten konkret an welchen Tasks? Diese Einblicke fehlen oft, sofern Sie keinen eigenen Zugang zum Projektmanagement-Tool erhalten.

Kostenkontrolle und Nachbudgetierung: Tagessätze können nach Vertragsabschluss angepasst werden. Bei Time-and-Material-Verträgen können unerwartete Komplexitäten zu erheblichen Nachbudgetierungen führen. Scope-Creep ist ein reales Risiko, und nicht alle Agenturen sind transparent, wenn das Budget knapp wird.

Vendor Lock-in und Wissensabfluss: Wenn die Agentur die Plattform entwickelt, haben sie das tiefe technische Verständnis – nicht Sie. Sollten Sie die Zusammenarbeit beenden wollen, kann der Wissenstransfer herausfordernd sein. Sie sind möglicherweise abhängig von der Agentur für Wartung und Weiterentwicklung.

Geteilte Aufmerksamkeit: Agenturen betreuen mehrere Kunden gleichzeitig. In kritischen Phasen Ihres Projekts könnte ein anderer Kunde Priorität haben. Sie sind ein Kunde unter vielen, nicht der einzige Fokus.

Option 3: Das Hybrid-Modell – Das Beste aus beiden Welten

Für viele B2B-Unternehmen erweist sich ein hybrides Modell als optimaler Ansatz. Dabei übernimmt eine Agentur das initiale Replatforming bis zum Go-Live, während ein internes Team langfristig Wartung und Weiterentwicklung übernimmt.

Wie das Hybrid-Modell funktioniert

Phase 1 – Initiales Replatforming (Agentur): Die Agentur führt Discovery und Requirements-Engineering durch, entwickelt die technische Architektur und implementiert die Kernfunktionalität, integriert Drittsysteme (ERP, PIM, CRM), migriert Daten und führt umfassende Tests durch. Ziel: Ein funktionsfähiger MVP (Minimum Viable Product) zum Go-Live.

Phase 2 – Wissenstransfer und Training: Die Agentur dokumentiert Architektur, Code und Prozesse, schult das interne Team in Plattform-Nutzung und Customization und etabliert Best Practices für Deployment und Wartung. Parallel arbeiten interne Entwickler bereits an kleineren Anpassungen, um Erfahrung zu sammeln.

Phase 3 – Laufender Betrieb (Inhouse + Agentur-Support): Das interne Team übernimmt die Verantwortung für laufende Wartung, kleinere Feature-Entwicklungen, Content-Updates und Bugfixes. Die Agentur steht für komplexe Entwicklungen, Performance-Optimierungen, größere Architektur-Änderungen und strategische Beratung zur Verfügung – auf Retainer-Basis oder projektbezogen.

Die Vorteile des Hybrid-Ansatzes

Schneller Start durch Agentur-Expertise: Sie profitieren von der Erfahrung und den Ressourcen der Agentur, um schnell produktiv zu werden. Das Risiko einer fehlgeschlagenen Implementierung sinkt erheblich.

Langfristige Unabhängigkeit durch Inhouse-Team: Sie bauen gleichzeitig internes Wissen auf und werden nicht langfristig von der Agentur abhängig. Nach dem Go-Live können Sie den Großteil der Arbeiten selbst übernehmen.

Kostenoptimierung: Die teuren initialen Entwicklungskosten werden durch die Agentur effizient abgewickelt. Danach sinken Ihre laufenden Kosten durch das günstigere interne Team. Sie zahlen die Agentur nur noch für das, was Sie wirklich brauchen.

Flexibilität bei Ressourcen: Wenn unerwartete Herausforderungen auftauchen oder Sie schnell skalieren müssen, können Sie die Agentur reaktivieren. Sie haben einen "On-Demand"-Partner für kritische Situationen.

Kontinuierlicher Wissenstransfer: Ihr internes Team lernt von Anfang an von den Agentur-Experten. Dieser Wissenstransfer ist strukturiert und begleitet, nicht abrupt beim Projektende.

Die kritischen Erfolgsfaktoren

Klare Rollenverteilung von Anfang an: Es muss kristallklar sein, wer für welche Tasks verantwortlich ist. Ambiguität führt zu Reibungsverlusten, verzögerten Entscheidungen und gegenseitigem Fingerpointing.

Abgestimmte Workflows: Deployment-Prozesse, Code-Reviews, Testing und Bug-Tracking müssen sorgfältig koordiniert werden. Nutzen Sie gemeinsame Tools wie JIRA, GitHub und Slack, und etablieren Sie klare Prozesse.

Strukturierter Wissenstransfer: Dokumentation ist Pflicht, nicht Kür. Die Agentur muss verpflichtet werden, ausführliche technische Dokumentation, Architektur-Diagramme und Code-Kommentare bereitzustellen. Hands-on-Training für Ihr internes Team sollte Teil des Vertrags sein.

Realistisches Timing: Der Übergang von agenturgeführter Entwicklung zu internem Betrieb braucht Zeit. Planen Sie eine Überlappungsphase von mindestens 3-6 Monaten ein, in der beide Teams parallel arbeiten.

Die Entscheidungsmatrix: Welcher Ansatz passt zu Ihnen?

Um Ihnen die Entscheidung zu erleichtern, haben wir eine Entscheidungsmatrix entwickelt, die verschiedene Szenarien abbildet.

Inhouse-Entwicklung ist sinnvoll, wenn:

• Sie bereits ein starkes internes Entwicklerteam haben, das nur erweitert werden muss

• Langfristige Kostenkontrolle höchste Priorität hat und Sie bereit sind, in den initialen Teamaufbau zu investieren

• Maximale Kontrolle und interne Wissensentwicklung strategisch wichtig sind

• Sie Zeit haben – Ihr Replatforming ist nicht zeitkritisch und kann schrittweise erfolgen

• Die Plattform-Expertise intern bereits vorhanden ist oder schnell aufgebaut werden kann

Externe Agentur ist die richtige Wahl, wenn:

• Schnelle Time-to-Market geschäftskritisch ist – Sie müssen schnell produktiv werden

• Interne IT-Ressourcen begrenzt sind oder bereits ausgelastet sind

• Sie keine Erfahrung mit der Zielplattform haben und die Lernkurve vermeiden wollen

• Das Projekt komplex ist und spezialisierte Expertise erfordert (z.B. Headless, Microservices)

• Sie Risiken minimieren wollen – erfahrene Agenturen kennen Fallstricke und vermeiden teure Fehler

• Ein vollständiges multidisziplinäres Team benötigt wird (Entwicklung, Design, SEO, Testing)

Das Hybrid-Modell passt, wenn:

• Sie langfristig Unabhängigkeit aufbauen wollen, aber kurzfristig Expertise benötigen

• Budget für initiales Investment vorhanden ist, aber langfristig Kosten gesenkt werden sollen

• Sie ein kleines internes Team haben, das erweitert und geschult werden soll

• Kontinuierliche Weiterentwicklung nach Go-Live geplant ist

• Sie die Flexibilität schätzen, bei Bedarf auf externe Expertise zurückgreifen zu können

Die richtige Agentur wählen: Ein strukturierter Ansatz

Wenn Sie sich für eine Agentur oder das Hybrid-Modell entschieden haben, steht die nächste kritische Frage an: Wie finden Sie den richtigen Partner? Die Auswahl der Agentur ist mindestens so wichtig wie die Entscheidung für eine Plattform.

1. Plattform-Spezialisierung und technische Tiefe

Verifikation der Expertise: Prüfen Sie nicht nur, ob die Agentur mit Ihrer Zielplattform arbeitet, sondern wie tief ihre Expertise ist. Sind sie offizieller Partner der Plattform (z.B. Adobe Commerce Partner, Shopware Partner)? Welche Zertifizierungen haben ihre Entwickler? Wie viele Projekte haben sie mit dieser spezifischen Plattform umgesetzt?

Architektur-Know-how: Wenn Sie eine Headless- oder Composable-Architektur anstreben, muss die Agentur nachweisbare Erfahrung damit haben. Fragen Sie nach konkreten Projekten, technischen Herausforderungen und wie sie gelöst wurden. Eine Demo oder Walkthrough eines ähnlichen Projekts ist Gold wert.

B2B-Kompetenz: B2B E-Commerce ist komplexer als B2C. Kundenspezifische Preise, Genehmigungsworkflows, Kontenverwaltung, ERP-Integration – diese Anforderungen sind nicht trivial. Die Agentur muss verstehen, wie B2B-Geschäftsprozesse digital abgebildet werden.

2. Referenzen und Erfolgsnachweise

Case Studies kritisch prüfen: Agenturen präsentieren ihre besten Erfolge in Case Studies. Das ist normal. Aber fragen Sie nach: Welche Herausforderungen gab es? Wie wurden Verzögerungen gehandhabt? Was lief nicht nach Plan? Realistische Agenturen sprechen offen über Learnings.

Direkte Kundenkontakte: Bitten Sie um Kontakte zu 2-3 ehemaligen oder aktuellen Kunden mit ähnlichen Projekten. Wenn die Agentur ablehnt, ist das ein Red Flag. Sprechen Sie mit diesen Referenzen und fragen Sie gezielt nach: War die Kommunikation gut? Wie wurden Budget-Überschreitungen gehandhabt? Würden sie die Agentur wieder beauftragen?

Live-Demo anfordern: Nichts ersetzt einen tatsächlichen Einblick. Bitten Sie die Agentur, ein abgeschlossenes Projekt live zu demonstrieren – am besten eines mit ähnlichen Anforderungen. Achten Sie auf Qualität, Performance und User Experience.

#3. Team-Struktur und Verfügbarkeit

Wer arbeitet tatsächlich an Ihrem Projekt?: In der Sales-Phase treffen Sie oft Senior-Consultants und Account Manager. Aber wer entwickelt konkret? Fragen Sie nach den Profilen der Entwickler, die Ihrem Projekt zugeordnet werden. Welche Erfahrung haben sie? Wo sind sie lokalisiert? Arbeiten sie vollzeit oder teilzeit an Ihrem Projekt?

Team-Größe und Ressourcen: Wie groß ist das Team der Agentur insgesamt? Wie viele Entwickler arbeiten mit Ihrer spezifischen Technologie? Eine Agentur mit 50 Mitarbeitern, von denen nur 5 Ihre Plattform beherrschen, ist riskanter als eine mit 20 spezialisierten Experten.

Geografische Nähe und Sprache: Für kritische Projektphasen (Discovery, Go-Live, Problemlösung) ist persönlicher Kontakt wertvoll. Geografische Nähe erleichtert Vor-Ort-Termine. Eine gemeinsame Sprache (nicht nur Englisch, sondern echte Deutsch-Kompetenz bei deutschen Projekten) reduziert Missverständnisse erheblich.

4. Projektmanagement und Arbeitsweise

Welche Methodik nutzt die Agentur?: Arbeitet sie nach Scrum, Wasserfall, oder hybriden Ansätzen? Die Methodik sollte zu Ihrer Organisation passen. Wenn Sie agil arbeiten wollen, aber die Agentur nur Wasserfall kennt, wird es schwierig.

Kommunikations-Rhythmus: Wie oft finden Stand-ups, Sprint-Reviews oder Status-Updates statt? Welche Tools nutzen sie (Slack, JIRA, Monday, Asana)? Erhalten Sie als Kunde direkten Zugang zu diesen Tools, oder werden Updates nur über den Account Manager kommuniziert?

Transparenz im Projektverlauf: Können Sie jederzeit sehen, woran gearbeitet wird? Gibt es klare Velocity-Metriken oder Burndown-Charts? Wie werden Verzögerungen kommuniziert? Agenturen, die proaktiv über Probleme informieren, sind vertrauenswürdiger als solche, die schlechte Nachrichten verschweigen.

5. Kostenmodelle und Vertragsgestaltung

Fixpreis vs. Time-and-Material: Beide Modelle haben Vor- und Nachteile. Fixpreis gibt Kostensicherheit, setzt aber voraus, dass der Scope perfekt definiert ist. Time-and-Material ist flexibler für sich entwickelnde Requirements, kann aber zu Kostenexplosionen führen. Manche Agenturen bieten hybride Modelle: Fixpreis für Kernfunktionalität, T&M für Zusatzfeatures.

Granularität der Angebote: Bei Fixpreis-Angeboten sollten Sie genau prüfen: Sind alle Ihre Requirements detailliert abgedeckt? Oder gibt es unklare Bereiche, die später zu Nachbudgetierungen führen könnten? Vergleichen Sie mehrere Angebote und fragen Sie gezielt nach, warum einzelne Posten unterschiedlich bewertet werden.

Change Management: Wie geht die Agentur mit Änderungswünschen um? Gibt es klare Prozesse für Change Requests? Werden diese separat kalkuliert, oder sind kleine Anpassungen im Retainer enthalten? Ein transparenter Change-Request-Prozess verhindert spätere Konflikte.

6. Post-Launch-Support und Langfristigkeit

Wartung und Support-Pakete: Was passiert nach dem Go-Live? Bietet die Agentur verschiedene Service-Level-Agreements (SLAs) an? Gibt es Entwickler-Kontingente oder Retainer-Modelle für laufende Betreuung? Wie schnell reagiert die Agentur auf kritische Bugs?

Roadmap-Beratung: Die besten Agenturen denken über das initiale Projekt hinaus. Sie sollten strategische Partner sein, die Sie bei der kontinuierlichen Optimierung und Weiterentwicklung unterstützen – nicht nur Code-Lieferanten.

Team-Kontinuität: Wird das Team, das Ihr Projekt entwickelt hat, auch später für Support und Weiterentwicklung verfügbar sein? Oder wird ein neues Team übernehmen, das sich erst einarbeiten muss? Kontinuität ist wertvoll.

7. Cultural Fit und persönliche Chemie

Dieser Punkt wird oft unterschätzt: Sie werden Monate oder Jahre eng mit dieser Agentur zusammenarbeiten. Die persönliche Chemie zwischen Ihrem Team und der Agentur ist entscheidend. Vertrauen Sie Ihrem Bauchgefühl: Fühlt sich die Zusammenarbeit schon in der Anbahnungsphase gut an? Sind die Menschen sympathisch und transparent?

Werte und Arbeitskultur: Passen die Werte der Agentur zu Ihrer Unternehmenskultur? Wenn Sie schnelles, iteratives Arbeiten schätzen, aber die Agentur in starren Wasserfall-Strukturen denkt, wird es schwierig. Wenn Sie Wert auf Nachhaltigkeit legen, aber die Agentur nur auf Umsatz-Maximierung fokussiert ist, fehlt das Alignment.

Lernen Sie das Team kennen: Bestehen Sie darauf, die tatsächlichen Projektbeteiligten kennenzulernen – nicht nur Sales und Account Management. Ein Gespräch mit dem technischen Lead und ein Kennenlernen des Projektmanagers gibt Ihnen viel bessere Einblicke als polierte Marketing-Präsentationen.

Red Flags: Warnsignale, die Sie ernst nehmen sollten

Bei der Agentur-Auswahl gibt es klare Warnsignale, die Sie nicht ignorieren sollten:

Zu niedrige Preise: Wenn ein Angebot signifikant günstiger ist als andere, fragen Sie nach dem Warum. Billigste Option führt oft zu mangelhafter Implementierung, versteckten Kosten und teuren Nachbesserungen. Qualität hat ihren Preis.

Übertriebene Versprechen: "Wir migrieren Ihren komplexen B2B-Shop in 6 Wochen" – seien Sie skeptisch. Realistische Timelines für mittelgroße B2B-Replatformings liegen bei 3-12 Monaten. Agenturen, die unrealistische Versprechen machen, werden sie nicht halten können.

Fehlende Transparenz: Unklare Pricing-Strukturen, vage Projektpläne, keine Bereitschaft zur Offenlegung von Team-Details – das sind Red Flags. Seriöse Agenturen arbeiten transparent.

Schlechte Kommunikation im Proposal-Stadium: Wenn die Agentur bereits im Sales-Prozess langsam reagiert, unklare Antworten gibt oder Anfragen ignoriert, wird es im Projekt nicht besser. Die Proposal-Phase ist die Vorschau auf die künftige Zusammenarbeit.

One-Size-Fits-All-Ansatz: Agenturen, die nicht nach Ihren individuellen Geschäftsprozessen fragen, sondern Standardlösungen verkaufen wollen, haben nicht verstanden, was B2B-Commerce ausmacht. Customization ist im B2B-Bereich die Regel, nicht die Ausnahme.

Keine Referenzen oder abweisende Reaktion auf Anfragen: Wenn eine Agentur keine Referenzkunden nennen will oder bei kritischen Fragen ausweichend wird, ist Vorsicht geboten.

Die kritischen Fragen, die Sie stellen sollten

Um die Spreu vom Weizen zu trennen, sollten Sie potenzielle Agenturen mit gezielten Fragen konfrontieren:

Zu Projekt-Erfahrung und Expertise:

• "Können Sie uns drei B2B-Commerce-Projekte mit ähnlichen Anforderungen zeigen und uns mit den Projektverantwortlichen verbinden?"

• "Wie gehen Sie mit Scope Creep um? Können Sie ein Beispiel geben, wo ein Projekt vom ursprünglichen Plan abwich?"

• "Welche waren die größten technischen Herausforderungen in Ihren letzten drei Replatforming-Projekten, und wie haben Sie diese gelöst?"

• "Wie tief ist Ihre Expertise in [Zielplattform]? Wie viele zertifizierte Entwickler haben Sie im Team?"

Zu Kosten und Budget:

• "Wie gehen Sie mit Budget-Überschreitungen um? Was passiert, wenn das Projekt teurer wird als ursprünglich geschätzt?"

• "Welche versteckten Kosten sollten wir einkalkulieren, die in Ihrem Angebot nicht enthalten sind?"

• "Können Sie Ihre Pricing-Struktur aufschlüsseln? Was kostet welche Rolle pro Tag?"

• "Gibt es Kosten für Dinge wie Change Requests, zusätzliche Meetings oder Support außerhalb der vereinbarten Zeiten?"

Zu Post-Launch und Langfristigkeit:

• "Welche Support-Modelle bieten Sie nach dem Go-Live? Was sind die SLAs für kritische Bugs?"

• "Wie messen Sie Projekt-Erfolg? Welche KPIs tracken Sie?"

• "Wie sieht Ihr Wissenstransfer aus, wenn wir später teilweise oder vollständig Inhouse übernehmen wollen?"

• "Wird das ursprüngliche Team auch nach Go-Live verfügbar sein, oder übernimmt ein anderes Team die Wartung?"

Zur Arbeitsweise und Kommunikation:

• "Wie oft finden Status-Updates statt? Welche Tools nutzen Sie für Projektmanagement und Kommunikation?"

• "Erhalten wir direkten Zugang zu JIRA/Ihrem PM-Tool, oder werden Updates nur über Account Manager kommuniziert?"

• "Wie gehen Sie mit kritischen Situationen um? Können Sie ein Beispiel geben, wo ein Projekt in Schieflage geriet und wie Sie es wieder auf Kurs brachten?"

• "Wer ist unser Hauptansprechpartner? Wie viele andere Projekte betreut diese Person parallel?"

Der MVP-Ansatz: Starten Sie klein, skalieren Sie smart

Ein oft übersehener, aber äußerst pragmatischer Ansatz ist der MVP-First-Ansatz (Minimum Viable Product). Statt direkt ein vollständiges Team aufzubauen oder sich langfristig an eine Agentur zu binden, starten Sie mit einem schlanken MVP:

Phase 1 – MVP mit Agentur (3-6 Monate): Die Agentur entwickelt eine funktionsfähige, aber bewusst abgespeckte Version Ihres Shops mit Kernfunktionalität: Produktkatalog, Suche, Warenkorb, Checkout und essenziellen B2B-Features wie kundenspezifische Preise.

Phase 2 – Validierung am Markt (3-6 Monate): Sie testen den MVP mit einigen wenigen, aber echten Kunden und generieren ersten Umsatz. Wichtig: Sie sammeln Feedback, verstehen, welche Features wirklich genutzt werden, und validieren Ihre technologischen Entscheidungen unter realen Bedingungen.

Phase 3 – Strategische Entscheidung: Basierend auf Umsatz und Feedback entscheiden Sie jetzt fundiert, ob Sie ein Inhouse-Team aufbauen (weil das Geschäftsmodell validiert ist und sich die Investition lohnt), die Agentur weiter beauftragen (weil Sie lieber extern bleiben wollen) oder ein Hybrid-Modell etablieren.

Der Vorteil: Sie investieren nicht blind in ein großes internes Team oder einen Langzeitvertrag, bevor Sie wissen, ob das Geschäftsmodell funktioniert. Diese Strategie ist besonders für Unternehmen sinnvoll, die neu im E-Commerce sind oder ein neues Geschäftsmodell testen.

Fazit: Die beste Entscheidung ist die informierte Entscheidung

Es gibt keine universell "richtige" Antwort auf die Frage "Inhouse oder Agentur?". Die optimale Lösung hängt von Ihrer spezifischen Situation ab – Ihren Ressourcen, Ihrer Expertise, Ihrem Zeitrahmen und Ihren strategischen Zielen.

Die entscheidenden Fragen, die Sie sich stellen sollten:

• Wie geschäftskritisch ist Time-to-Market? Wenn Sie schnell produktiv werden müssen, spricht vieles für eine Agentur.

• Welche IT-Ressourcen stehen uns langfristig zur Verfügung? Wenn Sie ein starkes internes Team haben oder aufbauen können, lohnt sich Inhouse-Entwicklung.

• Wie komplex sind unsere Anforderungen? Je spezialisierter die Anforderungen, desto wertvoller ist Agentur-Expertise.

• Wie wichtig ist uns langfristige Unabhängigkeit? Wenn digitale Souveränität strategisch wichtig ist, investieren Sie in Inhouse-Kapazitäten.

• Was ist unser Budget-Horizont? Können Sie hohe initiale Investitionen tragen, oder brauchen Sie planbare monatliche Kosten?

Für viele mittelständische B2B-Unternehmen erweist sich das Hybrid-Modell als optimaler Kompromiss: Sie profitieren von Agentur-Expertise für den kritischen Launch und bauen gleichzeitig internes Wissen für langfristige Unabhängigkeit auf.

Der wichtigste Rat: Nehmen Sie sich Zeit für diese Entscheidung. Sprechen Sie mit mehreren Agenturen, holen Sie Referenzen ein, und vertrauen Sie nicht nur auf Hochglanz-Präsentationen. Die Wahl Ihres Umsetzungspartners ist fast so wichtig wie die Wahl der Plattform selbst – und kann über Erfolg oder Misserfolg Ihres Replatformings entscheiden.

Im nächsten Schritt geht es darum, wie Sie den Replatforming-Prozess selbst optimal strukturieren: Von der Discovery-Phase über Datenmigration bis zum Go-Live und darüber hinaus. Denn selbst mit dem besten Team – intern oder extern – brauchen Sie einen klaren Prozess und eine solide Roadmap.

Fußnoten

1. Deloitte Global Outsourcing Survey 2024. 66% of US companies use software outsourcing, over 90% of Fortune 500/G2000 companies outsource. Primary drivers: cost reduction (70%), lack of in-house skills (40%), talent shortage (35%). Quelle: Relevant Software ↩

2. Glassdoor & Workable: Average Time to Hire Software Developer 2025. Average time-to-hire for software developers is 35-41 days in the US, with senior positions taking up to 20% longer. Quelle: Workable ↩

3. HackerEarth: Hiring Statistics 2025. Senior Application Developers have an average time-to-hire of 50-90 days. Time-to-hire varies significantly by seniority level and specialization. Quelle: HackerEarth Blog ↩

4. Employ: Best Time to Hire Software Engineers 2025. 62% of all tech companies recruit in January. Hiring can take 12+ weeks during peak seasons due to market saturation and competition for talent. Quelle: Employ.com ↩

5. LinkedIn Talent Solutions: Tech Industry Turnover Rate 2025. Average tech industry turnover rate is 17-18% per year, with engineering roles at approximately 12%. Factors include competitive job market, remote work opportunities, and demand for specialized skills. Quelle: Apollo Technical ↩

6. SHRM & Gallup: Cost of Employee Turnover 2025. Replacing an employee costs 33-50% of annual salary for entry-level positions, 150-200% for mid-level, and up to 400% for executive roles. Costs include recruitment, onboarding, lost productivity, and training. Quelle: Built In ↩

7. Future of Sourcing Digital: Outsourcing Statistics 2025. Companies using outsourcing partners reduce time-to-hire by 20-50% compared to internal recruitment due to pre-vetted talent pools and established processes. Quelle: Future of Sourcing ↩

8. Second Talent & McKinsey: Remote Work & Hiring Statistics 2025. Remote hiring delivers 340% larger candidate pools and 16% faster time-to-hire. 74% of companies plan permanent remote work post-COVID. By 2030, 1 billion people globally will work remotely, representing 30% of the global workforce.Quelle: Second Talent ↩

Digitale Souveränität als strategischer Wettbewerbsvorteil

In Zeiten verschärfter Regulierung und steigender Anforderungen an Datenschutz wird digitale Souveränität zum entscheidenden Faktor. Open-Source Software gibt Unternehmen die vollständige Kontrolle über ihren Code zurück. Der gesamte Quellcode ist einsehbar, auditierbar und kann bei Bedarf intern geprüft werden – ein Aspekt, der für ISO-Zertifizierungen oder branchenspezifische Compliance-Anforderungen zunehmend relevant wird.1

Besonders im Kontext der DSGVO bietet Open-Source einen unschätzbaren Vorteil: Sie behalten die vollständige Hoheit über Ihre Daten. Kundendaten, Preislisten und Geschäftsinformationen verbleiben in Ihrer Infrastruktur, ohne durch externe Server oder internationale Cloud-Anbieter zu wandern. Diese Datensouveränität ist nicht nur ein rechtliches Sicherheitsnetz, sondern auch ein Vertrauensfaktor gegenüber Ihren Geschäftskunden.

Unbegrenzte Flexibilität für individuelle B2B-Prozesse

Der B2B-Handel zeichnet sich durch hochspezifische Anforderungen aus, die weit über die Möglichkeiten standardisierter E-Commerce-Plattformen hinausgehen. Open-Source Systeme mit modularer Architektur ermöglichen es, exakt die Features zu entwickeln, die Ihr Geschäftsmodell erfordert: kundenindividuelle Bestellfreigabe-Workflows, mehrstufige Genehmigungsprozesse, differenzierte Kundenrechte und Rollenkonzepte oder automatisierte Kundenanlage mit ERP-Synchronisation.

Die wahre Stärke zeigt sich bei der Integration in bestehende Systemlandschaften. Während SaaS-Lösungen oft nur vordefinierte Schnittstellen bieten, lässt sich Open-Source Software nahtlos mit jeglichen Drittsystemen verbinden: Ihr CRM für Kundendaten, das PIM für Produktinformationen, Ihr ERP für Preise, Bestellungen und Warenwirtschaft sowie Buchhaltungssysteme. Diese Integrationsfähigkeit ist kein Nice-to-have, sondern die Grundlage für effiziente digitale Geschäftsprozesse.

KI-Integration als strategischer Differenzierungsfaktor

Ein entscheidender Vorteil, der in der Diskussion um Open-Source oft übersehen wird, ist die nahtlose Integration moderner KI-Technologien. Der AI Agent Markt im E-Commerce wird bis 2030 auf 175 Milliarden USD wachsen, mit einer jährlichen Wachstumsrate von über 30%.2 Open-Source Plattformen bieten hier einen entscheidenden Vorteil: vollständige Kontrolle über die Art und Weise, wie KI-Tools in Ihre Commerce-Umgebung integriert werden.

KI-gestützte User Experience: Die Integration von KI-Shopping-Assistenten und intelligenten Produktberatern revolutioniert das B2B-Einkaufserlebnis. Ihre Kunden können in natürlicher Sprache nach komplexen Produktspezifikationen suchen, erhalten personalisierte Empfehlungen basierend auf ihrer Einkaufshistorie und ihren individuellen Konditionen. AI-gestützte Personalisierung führt nachweislich zu messbaren ROI-Verbesserungen: 89% der Unternehmen berichten von positivem ROI, und KI-basierte Personalisierung kann die Conversion-Rate um bis zu 23% steigern.3 AI-Shopping-Assistenten können bereits 70% der Kundeninteraktionen autonom abwickeln.4

Ein B2B-Kunde könnte beispielsweise fragen: "Welche Schrauben eignen sich für Stahlkonstruktionen im Außenbereich bei Temperaturen bis -20°C?" – und erhält nicht nur passende Produktvorschläge, sondern auch technische Spezifikationen, verfügbare Mengen und kundenspezifische Preise in Echtzeit. Diese Art der kontextbezogenen Beratung war bisher nur im persönlichen Vertrieb möglich.

KI-optimierte Geschäftsprozesse: Die offene Architektur von Open-Source Plattformen ermöglicht es, KI-Tools direkt in Ihre Prozessketten zu integrieren. Content-Translation erfolgt automatisiert und kontextbezogen – nicht nur Wort für Wort, sondern unter Berücksichtigung branchenspezifischer Terminologie und Ihrer Corporate Language. Produktbilder werden automatisch für verschiedene Kanäle optimiert, Hintergründe entfernt oder angepasst. Produktbeschreibungen werden KI-gestützt generiert und an verschiedene Zielgruppen angepasst – technische Details für Einkäufer, anwendungsorientierte Beschreibungen für Endanwender.

Model Context Protocol (MCP) als Zukunftstechnologie: Besonders zukunftsweisend ist die Integration von Model Context Protocol (MCP), einem offenen Standard für die Kommunikation zwischen KI-Systemen und Datenquellen. MCP wurde von Anthropic entwickelt und im November 2024 als Open Standard veröffentlicht.5 Der Protokoll wurde inzwischen von führenden AI-Anbietern wie OpenAI und Google DeepMind adoptiert und im Dezember 2025 an die Linux Foundation unter der Agentic AI Foundation übergeben.6 Mit MCP können Sie verschiedene KI-Modelle nahtlos mit Ihren Produktdaten, Kundeninformationen und Geschäftsprozessen verbinden – ohne proprietäre APIs oder Vendor-Lock-in.

In der Praxis bedeutet dies: Ein KI-Kundensupport-Agent hat direkten, kontextbezogenen Zugriff auf Ihr Produktinventar, Kundenhistorie, offene Bestellungen und technische Dokumentation – und kann B2B-Kunden in Echtzeit präzise Auskünfte geben. Ein KI-gestützter Produktratgeber kann auf aktuelle Lagerbestände, kundenspezifische Preisvereinbarungen und sogar auf ERP-Daten zugreifen, um belastbare Empfehlungen zu geben.

Der entscheidende Unterschied zu proprietären SaaS-Lösungen: Bei Open-Source bestimmen Sie, welche KI-Modelle Sie einsetzen, wie Ihre Daten verarbeitet werden und wo die Rechenleistung erfolgt. Sie sind nicht auf die KI-Features beschränkt, die Ihr SaaS-Vendor anbietet, sondern können Best-of-Breed-Lösungen frei kombinieren und an Ihre spezifischen Anforderungen anpassen.

Unabhängigkeit statt Vendor Lock-in

Einer der kritischsten Aspekte bei der Wahl einer Commerce-Plattform ist die langfristige Bindung an einen Anbieter. Bei proprietären SaaS-Lösungen begeben Sie sich in eine Abhängigkeit, die weit über die monatliche Lizenzgebühr hinausgeht: Sie sind abhängig vom Produkt-Roadmap des Vendors, von dessen Preisentscheidungen und von der Verfügbarkeit der Plattform.

Mit Open-Source behalten Sie die Kontrolle über Ihre eigene Roadmap. Sie entscheiden, welche Features priorisiert werden, wann Updates eingespielt werden und in welche Richtung sich Ihre Plattform entwickelt. Diese strategische Unabhängigkeit ist gerade für mittelständische Unternehmen mit langfristigen Digitalisierungsstrategien von enormer Bedeutung.

Ein weiterer Punkt, der in der Praxis oft unterschätzt wird: SaaS-Anbieter setzen häufig Limits bei API-Calls oder der Anzahl verwaltbarer Datensätze.7 Im B2B-Kontext mit kundenspezifischen Preislisten, umfangreichen Produktkatalogen und individuellen Konditionen können schnell mehrere hunderttausend Datensätze zusammenkommen. Diese Skalierung lässt sich bei Open-Source planen und kontrollieren, ohne von Vendor-Limits ausgebremst zu werden.

Innovation durch Community und Ökosystem

Open-Source Plattformen wie Magento 2 oder Shopware 6 verfügen über lebendige Communities aus Entwicklern, Agenturen und Anwendern. Die Magento 2 Community zählt über 480.000 aktive Nutzer und 14.000 Unternehmen und Agenturen weltweit.8 Diese Ökosysteme treiben kontinuierlich Innovationen voran, entwickeln Extensions und teilen Best Practices. Wenn Sie auf ein technisches Problem stoßen, profitieren Sie von der kollektiven Erfahrung Tausender Entwickler weltweit.

Diese Community ist mehr als ein Support-Forum. Sie ist ein Innovationsmotor, der dafür sorgt, dass Open-Source Plattformen technologisch am Puls der Zeit bleiben und sich ständig weiterentwickeln. Debugging wird beschleunigt, neue Features entstehen aus echten Anforderungen der Anwender, und bewährte Lösungen für komplexe B2B-Szenarien werden geteilt.

Transparente Kostenstruktur und Investitionssicherheit

Die Kostenstruktur von Open-Source Commerce unterscheidet sich fundamental von SaaS-Modellen. Während Sie bei SaaS oft monatliche Lizenzgebühren zahlen, die sich am Umsatz oder der Nutzeranzahl orientieren, investieren Sie bei Open-Source primär in Hosting und Entwicklung. Diese Investition ist planbar, skalierbar und bleibt unter Ihrer Kontrolle.

Ein anschaulicher Vergleich: Sie bezahlen nicht für das Werkzeug, sondern für das Ergebnis, das Sie damit bauen. Die Software selbst ist frei verfügbar. Ihre Investition fließt in die Anpassung an Ihre spezifischen Anforderungen, in die Integration mit Ihren Systemen und in die kontinuierliche Optimierung Ihrer digitalen Vertriebskanäle. Diese Ausgaben schaffen echten Mehrwert für Ihr Unternehmen statt Lizenzgebühren an Dritte zu entrichten.

Gerade für wachsende B2B-Unternehmen ist diese Kostenkontrolle entscheidend. Während bei SaaS-Lösungen die Gebühren mit jedem zusätzlichen Nutzer, jedem weiteren Marktplatz oder jedem Umsatzwachstum steigen, bleiben bei Open-Source die Grundkosten stabil und skalieren nur dort, wo Sie tatsächlich mehr Ressourcen benötigen.

Die Kehrseite der Medaille: Was Sie beachten sollten

Open-Source ist kein Allheilmittel, und es wäre unseriös, die Herausforderungen zu verschweigen. Die Flexibilität und Kontrolle haben ihren Preis: Sie benötigen die entsprechende Infrastruktur und das Know-how, um diese zu betreiben. Hosting-Kosten variieren je nach Traffic, Produktanzahl und Bestellvolumen. Anders als bei SaaS, wo Infrastruktur im Paket enthalten ist, müssen Sie diese selbst planen und skalieren.

Updates und Wartung erfordern kontinuierliche Aufmerksamkeit. Während SaaS-Anbieter automatisch die neueste Version ausrollen, liegt die Verantwortung für Security-Updates und Versionswechsel bei Ihnen. Dies erfordert entweder eigene Entwickler-Ressourcen oder die Zusammenarbeit mit erfahrenen Partnern.

Die Weiterentwicklung Ihrer Plattform setzt Erfahrung mit Software-Entwicklung voraus. Sie benötigen ein Team oder einen Partner, der die Technologie beherrscht und Ihre Geschäftsanforderungen in Code übersetzen kann. Diese Investition in Expertise ist jedoch langfristig wertvoller als die Abhängigkeit von einem SaaS-Vendor.

Fazit: Open-Source als strategische Entscheidung

Open-Source Software ist im B2B Commerce kein Trend, sondern eine strategische Entscheidung für digitale Souveränität, maximale Flexibilität und langfristige Unabhängigkeit. Für Unternehmen, die ihre digitalen Vertriebskanäle als Kernkompetenz verstehen und die Kontrolle über ihre technologische Zukunft behalten wollen, führt kaum ein Weg an Open-Source vorbei.

Die Frage ist nicht, ob Open-Source die richtige Wahl ist, sondern ob Ihr Unternehmen bereit ist, die Verantwortung für die eigene digitale Infrastruktur zu übernehmen. Wenn Sie diese Frage mit Ja beantworten können, steht Ihnen mit Open-Source Commerce ein Werkzeug zur Verfügung, das in Flexibilität, Skalierbarkeit und strategischer Unabhängigkeit seinesgleichen sucht.

Fußnoten

1. ISO/IEC 5230:2020 - OpenChain Specification für Open-Source-Lizenz-Compliance. Quelle: ISO.org ↩

2. Mordor Intelligence: Agentic AI in Retail and ECommerce Market Report 2025. Der Markt wird von USD 46,74 Mrd. in 2025 auf USD 175,11 Mrd. bis 2030 wachsen (CAGR 30,2%). Quelle: Mordor Intelligence ↩

3. Envive AI: 63 AI Personalization in eCommerce Statistics. 89% der Unternehmen berichten von positivem ROI durch AI-Personalisierung, Conversion-Steigerungen bis 23%. Quelle: Envive.ai ↩

4. Freshworks: AI customer service statistics 2025. Virtual assistants können bis zu 70% der Anfragen deflektieren, 94% der Unternehmen nutzen AI in Marketing-Prozessen. Quelle: Freshworks.com ↩

5. Anthropic: Introducing the Model Context Protocol (November 2024). MCP ist ein offener Standard zur Verbindung von AI-Assistenten mit Datenquellen. Quelle: Anthropic.com ↩

6. Anthropic: Donating the Model Context Protocol to the Agentic AI Foundation (Dezember 2025). MCP wurde an die Linux Foundation übergeben, mit Unterstützung von OpenAI, Google, Microsoft, AWS und anderen. Quelle: Anthropic.com ↩

7. Smart SaaS: B2B SaaS Fees & Costs Beyond the Price Tag (März 2025). SaaS-Anbieter nutzen häufig API-Rate-Limits und versteckte Nutzungsgrenzen in Tiered-Pricing-Modellen. "Rate limits throttle how often apps can communicate unless you upgrade to a higher tier" und "Pay-per-call pricing forces businesses to pay based on API usage". Quelle: SmartSaaS.works ↩

8. Adobe Commerce (Magento): Community-Statistiken. Die Magento Open-Source Community umfasst über 480.000 aktive Nutzer und 14.000+ Agenturen weltweit.Quelle: OpenChain Project ↩

Im Folgenden beleuchten wir die kritischen Signale, die darauf hindeuten, dass Ihre E-Commerce-Plattform den Anforderungen Ihres Geschäfts nicht mehr gerecht wird – von offensichtlichen Kundenbeschwerden bis hin zu schleichenden technischen Schulden, die Ihre Organisation zunehmend lähmen.

Kundenbeschwerden als Frühwarnsystem

Ein besonders klares Indiz für Optimierungsbedarf sind Beschwerden von Kunden und Nutzern Ihres Shops. Diese betreffen oft Aspekte wie lange Ladezeiten, technische Fehler oder das Fehlen moderner Funktionen. Heutzutage setzen Nutzer von Online-Shops grundlegende Features als Standard voraus: eine schnelle und intuitive Produktsuche, Filter- und Sortiermöglichkeiten, einen reibungslosen Checkout mit vielfältigen Zahlungs- und Versandoptionen. Funktionen wie die datenschutzkonforme Speicherung von Kreditkartendaten gemäß PCI-DSS Compliance gelten mittlerweile als selbstverständlich.¹

Werden diese Erwartungen nicht erfüllt, verlassen unzufriedene Nutzer den Shop ohne Conversion. Während manche Kunden ihre Frustration äußern – etwa per E-Mail oder im Support-Chat – entscheiden sich viele, stillschweigend zur Konkurrenz zu wechseln. Beschwerden sollten daher stets ernst genommen werden, denn sie sind oft nur die Spitze eines Eisbergs. Die wirklichen Verluste zeigen sich nicht in den Support-Tickets, sondern in den Conversion-Rates und im Customer Lifetime Value.

Mitarbeiterfrust als Kostentreiber

Auch auf der internen Seite können Beschwerden wichtige Signale für Handlungsbedarf liefern. Die Effizienz Ihrer Mitarbeiter hängt direkt von der Leistungsfähigkeit der verwendeten Tools ab.

Content-Management: Content-Manager klagen häufig über aufwändige Prozesse bei der Pflege oder Erstellung von Content, insbesondere wenn dazu Entwicklerkenntnisse oder sogar Deployments notwendig sind. Moderne Plattformen sollten eine einfache Handhabung wiederverwendbarer Content-Bausteine ermöglichen und eine reibungslose Internationalisierung bieten, die ohne manuelle Eingriffe auskommt.

Produktdatenmanagement: Produktdatenmanager benötigen effektive Werkzeuge, um Kataloge effizient zu aktualisieren – vor allem bei Shops mit mehreren Tausend Artikeln (SKUs) und mehrsprachigen Beschreibungen. Massenänderungen von Attributen, wie das gleichzeitige Aktualisieren von Materialangaben für viele Produkte, sind hier ein Muss. Fehlende Automatisierungen in diesem Bereich verursachen nicht nur unnötige Kosten, sondern können auch zu fehlerhaften oder unvollständigen Produktinformationen führen, was wiederum potenziellen Umsatzverlust bedeutet.

Marketing-Operationen: Für Online-Marketer sind Flexibilität und Autonomie essenziell. Kampagnen und Rabatte, wie etwa Gutscheincodes, sollten im Admin-Bereich einfach einstellbar sein, ohne dass Entwickler eingreifen müssen. Zudem müssen Tracking-Tools wie Google Tag Manager problemlos konfiguriert und Drittanbieter-Pixel (z.B. für Facebook oder Google Ads) schnell eingebunden werden können. Wenn jede Marketing-Aktion ein IT-Ticket erfordert, leidet die Time-to-Market erheblich.

Buchhaltung und Fulfillment: Mitarbeiter in Buchhaltung und Fulfillment benötigen gut abgestimmte Prozesse. Der automatisierte Import von Bestelldaten ins ERP oder die Buchhaltungssoftware muss zuverlässig alle relevanten Informationen umfassen: Rechnungs- und Lieferadressen, Artikelnummern, Versand- und Zahlungsmethoden sowie Rabatte und Steuern. Manuelle Nachbearbeitung ist nicht nur ineffizient, sondern fehleranfällig und skaliert nicht mit wachsendem Geschäftsvolumen.

Technische Schulden dominieren die Roadmap

Ein schleichendes, aber hochgradig kritisches Signal ist die zunehmende Dominanz technischer Schulden in Ihrer Projekt- und Releaseplanung. Technische Schulden entstehen, wenn kurzfristige Lösungen und Workarounds sich über Jahre akkumulieren und die Codebasis zunehmend fragil und schwer wartbar wird.

Die Symptome sind deutlich: Die Time-to-Market für neue Features wird immer länger. Was vor zwei Jahren in einem Sprint umsetzbar war, benötigt heute mehrere Monate. Neue Funktionen erfordern umfangreiche Refactorings, weil die bestehende Architektur sie nicht mehr sauber integrieren lässt. Ihr Entwicklungsteam verbringt mehr Zeit damit, alte Systeme am Laufen zu halten, als innovative Features zu entwickeln.

Besonders problematisch wird es, wenn Know-how-Abhängigkeiten von einzelnen Entwicklern entstehen. Wenn nur noch eine oder zwei Personen im Team verstehen, wie kritische Teile des Systems funktionieren, wird dies zum organisatorischen Risiko. Die Entwicklerproduktivität sinkt messbar, weil immer mehr Zeit für das Verständnis komplexer Legacy-Strukturen aufgewendet werden muss statt für die Entwicklung neuer Funktionalität.

Die Plattform unterstützt Ihr Geschäftsmodell nicht mehr

Geschäftsmodelle entwickeln sich weiter – Ihre Technologie muss Schritt halten. Wenn Ihre aktuelle Plattform strategische Initiativen blockiert, ist das ein deutliches Signal für Replatforming-Bedarf:

Headless Commerce und Mobile Apps: Moderne B2B-Käufer erwarten nahtlose Erlebnisse über alle Kanäle hinweg. Wenn Ihre Plattform keine API-First-Architektur bietet oder das Ausspielen von Inhalten auf mobile Apps, IoT-Geräte oder In-Store-Terminals nicht sauber unterstützt, verpassen Sie wesentliche Touchpoints.

Multi-Warehouse und komplexe Logistik: B2B-Unternehmen mit mehreren Standorten, regionalen Lagern oder Drop-Shipping-Modellen benötigen eine Plattform, die diese Komplexität abbilden kann. Wenn Ihre Lösung nur ein einzelnes Lager unterstützt oder komplexe Versandlogiken nicht nativ abbildet, führt das zu kostspieligen Workarounds.

Omnichannel-Strategien: Die Grenzen zwischen Online- und Offline-Handel verschwimmen. Wenn Sie Click-and-Collect, In-Store-Reservierungen oder einheitliche Kundenerlebnisse über alle Kanäle hinweg anbieten möchten, aber Ihre Plattform diese Szenarien nicht unterstützt, limitiert das Ihre strategischen Optionen erheblich.

Steigende Total Cost of Ownership

Neben den offensichtlichen Signalen gibt es schleichende Entwicklungen, die ein Replatforming erforderlich machen. Ein Beispiel hierfür sind kontinuierlich steigende Total Cost of Ownership (TCO) bei gleichzeitig stagnierendem Umsatz. Die TCO umfassen unter anderem Hosting- und Lizenzgebühren sowie Kosten für interne Entwickler oder externe Agenturen.

Wenn der Deckungsbeitrag Ihres Shops über längere Zeit sinkt, weil ein immer größerer Anteil des Umsatzes in die Aufrechterhaltung der Plattform fließt statt in Wachstum und Innovation, kann die Rentabilität gefährdet sein. Besonders kritisch wird es, wenn Sie feststellen, dass Sie mehr für Wartung und Bugfixes ausgeben als für die Entwicklung neuer Features, die Ihren Kunden Mehrwert bieten.

Skalierungsprobleme und Performance-Engpässe

Weitere klare Hinweise auf Handlungsbedarf sind Skalierungsprobleme. Ein Shop, der bei starkem Traffic – etwa an Black Friday oder während Kampagnen – ausfällt oder erheblich verlangsamt, verliert nicht nur direkten Umsatz, sondern auch Kundenvertrauen. [FACT-CHECK ✓: Gartner schätzt die durchschnittlichen Kosten von IT-Downtime auf etwa 5.600 USD pro Minute. Für größere Unternehmen können diese Kosten in die Zehntausende pro Minute steigen. Während Peak-Shopping-Perioden wie Black Friday und Cyber Monday können sich diese Verluste exponentiell vervielfachen.]² In einer Welt, in der Nutzer erwarten, dass Websites in unter zwei Sekunden laden,³ kann jede Verzögerung zu signifikanten Conversion-Verlusten führen.

Ähnlich problematisch wird es, wenn die Internationalisierung neue Märkte nur mit großem Aufwand ermöglicht. Wenn das Hinzufügen neuer Länder, Sprachen oder Währungen mehrere Entwicklermonate erfordert, fehlt Ihnen die Agilität, die für internationales Wachstum notwendig ist.

End of Life und Compliance-Risiken

Ein kritisches Signal, das zum sofortigen Handeln zwingt, ist das End of Life (EOL) von Software oder Bibliotheken, die in Ihrem Shop verwendet werden. Dies kann nicht nur technische Probleme verursachen, sondern auch rechtliche Konsequenzen haben.

Artikel 32 der DSGVO fordert, dass technisch-adäquate Schutzmaßnahmen nach dem „Stand der Technik" eingesetzt werden, um ein angemessenes Sicherheitsniveau zu gewährleisten.[FACT-CHECK ✓: Art. 32 DSGVO verlangt unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, des Kontexts und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte natürlicher Personen, dass angemessene technische und organisatorische Maßnahmen implementiert werden.]⁴ Werden Systeme nicht rechtzeitig aktualisiert, drohen Datenschutzrisiken und damit verbundene Sanktionen. Veraltete Plattformen, die keine Sicherheitsupdates mehr erhalten, stellen nicht nur ein technisches, sondern auch ein juristisches und reputatives Risiko dar.

Auch aus Sicht der PCI-DSS Compliance kann die Verwendung veralteter Software-Versionen problematisch werden. Zahlungsdienstleister können die Zusammenarbeit einschränken oder beenden, wenn Ihre Plattform nicht mehr den aktuellen Sicherheitsstandards entspricht.

Fazit: Replatforming als strategische Investition

Die Entscheidung für ein E-Commerce Replatforming sollte nicht leichtfertig getroffen werden – sie erfordert sorgfältige Planung, signifikante Investitionen und ein klares Verständnis der strategischen Ziele. Gleichzeitig kann das Ignorieren der beschriebenen Warnsignale erhebliche Opportunitätskosten verursachen.

Wenn mehrere der genannten Signale auf Ihre Situation zutreffen – steigende TCO, technische Schulden, sinkende Entwicklerproduktivität, Kundenbeschwerden, fehlende Unterstützung für Ihr Geschäftsmodell oder End-of-Life-Szenarien – ist es Zeit, ein Replatforming ernsthaft in Betracht zu ziehen.

Die richtige E-Commerce-Plattform ist kein Kostenfaktor, sondern ein strategischer Enabler. Sie sollte Ihr Geschäftswachstum unterstützen, nicht bremsen. Sie sollte Ihre Mitarbeiter produktiver machen, nicht frustrieren. Und sie sollte Ihren Kunden ein exzellentes Erlebnis bieten, das sie zu wiederkehrenden Käufern macht.

Die Frage ist nicht, ob Replatforming notwendig ist, sondern wann der richtige Zeitpunkt dafür gekommen ist. Die beschriebenen Signale helfen Ihnen, diese Entscheidung fundiert zu treffen.

Fußnoten

1. Payment Card Industry Data Security Standard (PCI DSS). PCI DSS definiert Sicherheitsanforderungen zum Schutz von Umgebungen, in denen Zahlungskontodaten gespeichert, verarbeitet oder übertragen werden. Cardholder Data (CHD) umfasst die 16-stellige Kontonummer, Karteninhabernamen, Ablaufdatum und Service-Code. Quelle: PCI Security Standards Council ↩

2. DevOps.com & Gartner: The High Price of A Digital Disaster (November 2024). Gartner schätzt die durchschnittlichen Kosten von IT-Downtime auf etwa 5.600 USD pro Minute – für größere Unternehmen können diese Kosten in die Zehntausende USD pro Minute steigen. Während Peak-Shopping-Perioden wie Black Friday und Cyber Monday können sich diese Verluste exponentiell vervielfachen. Quelle: DevOps.com ↩

3. Vodien: Prevent eCommerce Site Crashes (November 2025). 47% der Kunden erwarten, dass eine Website in 2 Sekunden oder weniger lädt. Fast 70% der Online-Käufer geben an, dass die Ladegeschwindigkeit ihre Kaufbereitschaft beeinflusst. Quelle: Vodien.com ↩

4. GDPR Article 32 - Security of processing. Artikel 32(1) DSGVO verpflichtet Controller und Processor, unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, des Kontexts und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte natürlicher Personen, angemessene technische und organisatorische Maßnahmen zu implementieren. Quelle: GDPR-Info.eu ↩

Bevor Sie sich für eine konkrete E-Commerce-Plattform entscheiden, sollten Sie das architektonische Fundament klären. Im Folgenden beleuchten wir die gängigen Ansätze – von Frontend- über Backend-Architekturen bis hin zu Deployment-Modellen – und zeigen auf, welche strategischen Überlegungen hinter jeder Entscheidung stehen.

Frontend-Architektur: Coupled vs. Headless

Die Frontend-Architektur bestimmt, wie eng Ihre Storefront mit der zugrundeliegenden E-Commerce-Logik verbunden ist. Diese Entscheidung hat direkten Einfluss auf Innovationsgeschwindigkeit, Entwicklungsaufwand und Omnichannel-Fähigkeit.

Headless: Maximale Flexibilität durch Entkopplung

Bei einem Headless-Ansatz ist das Frontend vom Backend vollständig entkoppelt. Die Kommunikation erfolgt ausschließlich über APIs. Jede Nutzerinteraktion – vom Hinzufügen eines Produkts zum Warenkorb bis zum Login – wird per API-Call an das Backend übermittelt. Ein Shop könnte beispielsweise Magento 2 als Backend nutzen, während das Frontend auf Basis moderner JavaScript-Frameworks wie React oder Vue.js völlig unabhängig entwickelt wird.

Der entscheidende Vorteil liegt in der unabhängigen Entwicklung und dem getrennten Deployment von Frontend und Backend. Design-Änderungen oder neue Features im Frontend erfordern kein Backend-Deployment – das beschleunigt Innovation erheblich. Gleichzeitig ermöglicht dieser Ansatz echte Omnichannel-Fähigkeit: Das Backend kann Inhalte über APIs für verschiedenste Kanäle bereitstellen, von der Website über native Mobile Apps bis hin zu IoT-Geräten, In-Store-Terminals oder Voice Commerce. Diese Flexibilität ist für B2B-Unternehmen mit komplexen Vertriebsstrukturen zunehmend geschäftskritisch.

Hinzu kommt die Technologiefreiheit – Sie können für Frontend und Backend jeweils die am besten geeigneten Technologien wählen und moderne JavaScript-Frameworks nutzen, ohne durch Backend-Limitierungen eingeschränkt zu sein. Studien zeigen, dass Unternehmen mit Headless-Architekturen ihre Time-to-Market für neue Features um bis zu 50% reduzieren können.¹

Die Kehrseite der Medaille ist jedoch nicht zu unterschätzen. Zwei separate Systeme müssen verwaltet, gewartet und aufeinander abgestimmt werden, was zusätzliche Ressourcen und Expertise in API-Entwicklung sowie modernen Frontend-Technologien erfordert. Die enge API-Kommunikation zwischen Frontend und Backend erhöht die technische Komplexität erheblich. Ineffiziente API-Integrationen können Ladezeiten verlängern und die SEO-Performance beeinträchtigen – ein kritischer Faktor im E-Commerce.

Die höheren Anforderungen an Entwickler-Know-how und die komplexere Infrastruktur führen in der Regel zu deutlich höheren Projektkosten, sowohl initial als auch im laufenden Betrieb.[^2] Unternehmen sollten berücksichtigen, dass Headless-Implementierungen typischerweise mehr technische Expertise und laufende Entwicklungsressourcen erfordern.

Coupled: Bewährte Effizienz für fokussierte Geschäftsmodelle

Beim Coupled-Ansatz ist das Frontend eng mit dem Backend verbunden, typischerweise über PHP-Funktionen, JavaScript und AJAX-Calls. Änderungen im Frontend erfordern häufig auch Anpassungen im Backend, und es gibt in der Regel ein gemeinsames Deployment. Dies ist der klassische Ansatz etablierter Plattformen wie Magento 2, wo das Standard-Frontend direkt mit dem Backend integriert ist.

Der pragmatische Vorteil liegt in der Out-of-the-Box-Funktionalität: Für gängige E-Commerce-Plattformen existieren zahlreiche Extensions, bei denen Frontend und Backend nahtlos zusammenarbeiten. Die Implementierung ist schneller und die technischen Anforderungen sind geringer. Sowohl die initialen Projektkosten als auch die laufenden Betriebskosten fallen im Vergleich zu Headless deutlich niedriger aus – ein wichtiger Faktor für mittelständische Unternehmen mit begrenzten IT-Budgets. Für Standardanforderungen können bewährte Lösungen schnell implementiert werden, ohne aufwändige API-Entwicklung.

Die Einschränkungen zeigen sich jedoch bei wachsenden Anforderungen. Anpassungen am Frontend sind stark vom Backend abhängig, und die Integration moderner Frontend-Technologien oder innovativer UI-Patterns ist deutlich aufwändiger. Bei wachsendem Geschäftsumfang oder der Expansion in neue Kanäle kann die Backend-Abhängigkeit zum Flaschenhals werden.

Die enge Kopplung erschwert zudem die Auslieferung von Inhalten auf unterschiedliche Touchpoints – ein zunehmendes Problem, da B2B-Käufer nahtlose Erlebnisse über alle Kanäle hinweg erwarten.

Die strategische Frage: Wann welcher Ansatz?

Headless empfiehlt sich für größere Unternehmen mit komplexen Omnichannel-Strategien, für B2B-Geschäftsmodelle mit diversen Vertriebskanälen wie Website, Mobile Apps, Kundenportalen oder IoT, für Organisationen mit entsprechenden IT-Ressourcen und Projektbudgets sowie für Unternehmen, die schnelle Innovation im Frontend priorisieren.

Coupled ist hingegen die richtige Wahl für kleinere bis mittelgroße Händler mit fokussierten Geschäftsmodellen, für Unternehmen mit primär webbasiertem Vertrieb, für Projekte mit begrenzten Budgets und IT-Ressourcen sowie für Organisationen, die schnell am Markt sein müssen.

Backend-Architektur: Monolith, Microservices oder Composable Commerce?

Die Backend-Architektur bestimmt, wie Ihre E-Commerce-Anwendung strukturiert ist – als einheitliches System oder als Sammlung unabhängiger Services. Diese Entscheidung hat weitreichende Auswirkungen auf Skalierbarkeit, Wartbarkeit und Innovationsfähigkeit.

Microservices: Modularität für maximale Agilität

Bei Microservices wird die E-Commerce-Anwendung in kleinere, unabhängige Dienste unterteilt. Jeder Service übernimmt eine spezifische Aufgabe wie Produktkatalog, Bestandsmanagement, Zahlung oder Checkout. Die Services kommunizieren über APIs und können unabhängig voneinander deployed und skaliert werden.

Die Vorteile für große Organisationen sind beträchtlich. Jeder Service kann separat skaliert werden – wenn beispielsweise der Checkout-Service bei Peak-Shopping-Events wie Black Friday unter hoher Last steht, kann gezielt dieser Service hochskaliert werden, ohne die gesamte Infrastruktur zu überdimensionieren. Gleichzeitig ermöglicht die Architektur Technologiefreiheit: Der Produktkatalog könnte in Java laufen, während der Checkout-Service in Node.js implementiert ist. Die höhere Ausfallsicherheit resultiert daraus, dass ein Fehler in einem Service nicht das gesamte System beeinträchtigt – wenn der Recommendation-Service ausfällt, funktionieren Produktsuche, Warenkorb und Checkout weiterhin. Separate Teams können zudem unabhängig voneinander an verschiedenen Services arbeiten, was die Entwicklungsgeschwindigkeit erhöht.

Die Herausforderungen sind jedoch erheblich. Die Koordination der API-Kommunikation zwischen Services ist anspruchsvoll, und Monitoring, Debugging sowie Fehlersuche über mehrere verteilte Services hinweg erfordern spezialisierte Tools und erhebliches DevOps-Know-how.

Ein aktueller Fall aus 2025 illustriert die realen Kosten drastisch.² Microservices führen typischerweise zu zehn- bis fünfzehnfach höheren Infrastrukturkosten im Vergleich zu Monolithen bei kleinen Teams. Die höheren Kosten resultieren aus zusätzlichen Aufwänden für Entwicklung, Infrastruktur, Service-Orchestrierung und spezialisiertes Personal – zusätzliche Platform Engineers kosten allein $140.000-$360.000 jährlich.³

Für kleine Teams oder Projekte in frühen Phasen sind Microservices oft kontraproduktiv. Die Komplexität lohnt sich erst bei ausreichender Größe und Skalierung – typischerweise bei sehr großen Organisationen mit hunderten Entwicklern.

Monolith: Bewährte Einfachheit mit klaren Grenzen

Ein monolithisches System integriert alle Funktionen – Frontend, Backend, Datenbank – in einer eng verknüpften Codebasis. Bei einer Standardinstallation von Magento 2 sind alle Kernfunktionen wie Suche, Produktmanagement, Warenkorb und Checkout in einem System vereint.

Der pragmatische Vorteil liegt in der einfachen Entwicklung und Verwaltung. Nur eine Codebasis muss gepflegt werden, was den Overhead beim Deployment reduziert und Testing sowie Wartung deutlich einfacher macht. Extensions und Anpassungen können mit relativ geringem Aufwand integriert werden, und für viele Standardanforderungen existieren bewährte Lösungen. Monolithische Systeme sind zudem weniger ressourcenintensiv und verursachen niedrigere Hosting- und Betriebskosten.

Die Grenzen zeigen sich jedoch bei wachsenden Anforderungen. Größere Anpassungen und Erweiterungen werden aufwendig und teuer, da die enge Kopplung aller Komponenten umfangreiche Änderungen risikoreich macht. Bei steigendem Traffic oder erweiterten Anforderungen stößt die Skalierbarkeit an Grenzen. Während horizontale Skalierung möglich ist, können Sie nicht gezielt einzelne Funktionen skalieren. Bei umfangreichen Individualisierungen sammeln sich über Zeit technische Schulden an, die Wartungs- und Update-Kosten erhöhen.

Composable Commerce: Der pragmatische Mittelweg

Composable Commerce stellt einen Mittelweg dar: Spezialisierte Systeme werden modular kombiniert, um eine maßgeschneiderte Lösung zu schaffen. In der Praxis könnte dies bedeuten, dass Magento 2⁴ als Commerce-Kern dient, Akeneo⁵ als PIM für Produktdaten fungiert, Storyblok⁶ als Headless CMS für Content eingesetzt wird und Algolia⁷ für die Suche verantwortlich ist.

Der Best-of-Breed-Ansatz ermöglicht es, für jeden Bereich die beste verfügbare Lösung zu wählen – das PIM mit der besten Produktdatenverwaltung, das CMS mit dem intuitivsten Content-Management, die Suchlösung mit der höchsten Performance. Diese sogenannten Packaged Business Capabilities (PBCs) sind vorkonfigurierte, API-first Software-Komponenten, die spezifische Geschäftsfunktionen abdecken. Die Zukunftssicherheit durch Austauschbarkeit ist ein weiterer Vorteil: Einzelne Komponenten können bei Bedarf ausgetauscht werden, ohne das gesamte System zu beeinträchtigen. Laut Gartner können Unternehmen mit Composable-Architekturen neue Features bis zu 80% schneller implementieren als mit monolithischen Plattformen.⁸ Sie komponieren Ihre Lösung exakt nach Ihren Anforderungen und zahlen nur für die Funktionen, die Sie tatsächlich benötigen.

Die realen Herausforderungen liegen in der erhöhten Komplexität: Die Integration und Koordination verschiedener Systeme ist anspruchsvoll, und jede zusätzliche Komponente erhöht die Anzahl der Schnittstellen und potentiellen Fehlerquellen. Neben den initialen Investitionen für Entwicklung und Lizenzen entstehen laufende Kosten für die Wartung und Pflege der Integrationen. Die Zusammenarbeit mit verschiedenen Anbietern erfordert mehr Koordination, und Support-Anfragen müssen möglicherweise mit mehreren Parteien geklärt werden. Kompatibilitäten zwischen Systemen müssen sorgfältig geprüft werden, da Updates eines Systems Anpassungen bei den Integrationen erfordern können.

Composable Commerce basiert typischerweise auf MACH-Architektur: Microservices-basiert, API-first, Cloud-native und Headless. Diese Prinzipien ermöglichen die flexible Integration der verschiedenen Komponenten.

Welche Backend-Architektur für welches Szenario?

Die Wahl der Backend-Architektur ist eine Abwägung zwischen Flexibilität, Kosten und technischer Machbarkeit. Ein Monolith eignet sich für kleinere bis mittlere Unternehmen mit überschaubarer Komplexität, für fokussierte Geschäftsmodelle ohne extensive Omnichannel-Anforderungen, für Organisationen mit begrenzten IT-Ressourcen sowie für Projekte, die schnell produktiv sein müssen.

Composable Commerce passt zu mittelständischen Unternehmen mit spezifischen Anforderungen, zu Organisationen, die Best-of-Breed-Lösungen bevorzugen, zu Unternehmen mit klarem Fokus auf bestimmte Bereiche wie exzellentes Content-Management sowie zu Projekten mit ausreichendem Budget für Integration und Wartung.

Microservices sind relevant für sehr große Unternehmen mit komplexen, hochskalierbaren Anforderungen, für Organisationen mit umfangreichen Entwickler-Teams von mehr als 100 Engineers, für Geschäftsmodelle mit extremen Skalierungsanforderungen sowie für Unternehmen mit der Expertise und Infrastruktur für verteilte Systeme.

Der pragmatische Weg, den viele erfolgreiche Unternehmen wählen, ist der Start mit einem gut strukturierten Monolithen, aus dem bei Bedarf schrittweise spezifische Funktionen in separate Services extrahiert werden. Diese hybride Strategie kombiniert initiale Einfachheit mit langfristiger Flexibilität.

Deployment-Modell: SaaS, On-Premise oder PaaS?

Das Deployment-Modell bestimmt, wo und wie Ihre E-Commerce-Plattform betrieben wird. Diese Entscheidung beeinflusst Kontrolle, Flexibilität und operative Verantwortung.

SaaS: Managed Services für schnellen Start

Bei Software as a Service (SaaS) wird die Software von einem externen Anbieter gehostet und vollständig verwaltet. Der Anbieter stellt die gesamte Infrastruktur bereit, inklusive regelmäßiger Updates. Die Nutzung erfolgt über eine monatliche oder jährliche Gebühr. Shopify ist das prominenteste Beispiel im E-Commerce-Bereich.

Die Vorteile für viele Organisationen liegen auf der Hand: Sie müssen sich nicht um Hosting, Servermanagement oder Updates kümmern – der Anbieter übernimmt diese Aufgaben vollständig. SaaS-Lösungen können oft innerhalb weniger Wochen produktiv sein, die Nutzungsgebühren sind klar kalkulierbar und in der Regel vorhersehbar, und Sie erhalten kontinuierlich neue Features und Sicherheitsupdates ohne eigenen Aufwand.

Die Einschränkungen werden jedoch mit wachsenden Anforderungen deutlich. Sie können keine direkten Änderungen am Quellcode vornehmen, und Anpassungen an der Geschäftslogik erfordern Extensions oder externe Microservices. Neue Features und Funktionen werden nur durch den Anbieter bereitgestellt – Sie sind abhängig von dessen Roadmap und Prioritäten. Alle Daten liegen auf Servern des Anbieters, was für Unternehmen mit strengen Compliance-Anforderungen problematisch sein kann. Bei spezifischen Performance-Anforderungen oder ungewöhnlichen Traffic-Mustern können SaaS-Lösungen zudem an Grenzen stoßen.

On-Premise: Maximale Kontrolle, maximale Verantwortung

Bei On-Premise wird die Software auf eigenen Servern oder bei einem Cloud-Anbieter wie AWS, Google Cloud oder Microsoft Azure gehostet. Sie tragen die volle Verantwortung für Konfiguration, Verwaltung und Wartung der Infrastruktur. Open-Source-Lösungen wie Shopware 6⁹ und Magento 2⁴ werden typischerweise on-premise betrieben.

Die Vorteile vollständiger Kontrolle sind beträchtlich: Sie haben volle Kontrolle über alle Aspekte der Infrastruktur und können diese nach Ihren Anforderungen konfigurieren. Individuelle Anpassungen an Geschäftslogik und Funktionalität sind ohne Einschränkungen möglich. Sie sind nicht von den Entscheidungen eines SaaS-Anbieters abhängig und können Ihre eigene technologische Roadmap verfolgen. Ihre Daten bleiben unter Ihrer vollständigen Kontrolle – ein wichtiger Faktor für Compliance und Datenschutz.

Die operativen Herausforderungen sind jedoch erheblich. Anschaffung, Einrichtung und Konfiguration von Servern oder Cloud-Infrastruktur erfordern signifikante Investitionen. Wartung, Updates, Backups und Security-Management verursachen kontinuierliche Kosten. Sie benötigen IT-Expertise für Infrastrukturmanagement, DevOps und Security. Traffic-Spitzen müssen vorausgeplant werden, und ohne automatische Skalierung können Peak-Events wie Black Friday zur Herausforderung werden.

PaaS: Der ausbalancierte Mittelweg

Platform as a Service (PaaS) bietet einen Mittelweg: Der Anbieter stellt eine Plattform bereit, auf der Sie eigene Software installieren und verwalten können. Die zugrundeliegende Infrastruktur – Server, Datenbanken, Caching – wird vom Anbieter bereitgestellt. Sie haben jedoch Zugriff auf den Quellcode und können die Geschäftslogik anpassen. Adobe Commerce Cloud ist ein bekanntes Beispiel.

Die Balance zwischen Flexibilität und Convenience zeigt sich in mehreren Aspekten: Sie können die Geschäftslogik individuell anpassen und haben Zugriff auf den Code. Der Aufwand für Infrastruktur-Management entfällt weitgehend, da der Anbieter sich um Skalierung, Verfügbarkeit und Basiswartung kümmert. Sicherheitspatches und Infrastruktur-Updates werden vom Anbieter verwaltet.

Die Kompromisse liegen in höheren Kosten als bei SaaS, insbesondere durch Lizenzkosten und höheren Entwicklungsbedarf. Bei der Skalierung und bestimmten Infrastruktur-Entscheidungen sind Sie vom Anbieter abhängig. Umfangreiche Anpassungen erfordern zudem spezialisierte Entwicklerkapazitäten.

Deployment-Modell: Die strategische Wahl

Die Entscheidung für ein Deployment-Modell sollte verschiedene Faktoren berücksichtigen. SaaS eignet sich, wenn schnelle Time-to-Market kritisch ist, IT-Ressourcen begrenzt sind, Standardfunktionalität ausreicht und planbare, transparente Kosten wichtig sind.

On-Premise ist die richtige Wahl, wenn maximale Kontrolle und Datensouveränität erforderlich sind, umfangreiche Individualisierungen notwendig sind, IT-Expertise im Haus vorhanden ist und langfristig niedrigere Gesamtkosten angestrebt werden.

PaaS bietet sich an, wenn Flexibilität bei der Geschäftslogik benötigt wird, Infrastruktur-Management ausgelagert werden soll, ausreichendes Budget vorhanden ist und ein Mittelweg zwischen Kontrolle und Convenience optimal ist.

Die zentrale Frage: Anpassung oder Individualität?

Alle diese architektonischen Entscheidungen laufen auf eine fundamentale strategische Frage hinaus: Passe ich mein Geschäft an die Software an, oder passe ich die Software an mein Geschäft an?

Diese Frage sollte im Kontext Ihrer Organisation beantwortet werden. Standardisierung durch Software eignet sich für Unternehmen mit Geschäftsmodellen, die sich gut in bestehende Lösungen einfügen. Der Vorteil liegt im schnelleren Start und geringeren initialen Investitionen. Sie profitieren von bewährten Best Practices und kontinuierlichen Verbesserungen des Anbieters. Typisch ist dies für Start-ups, kleinere Händler und Unternehmen mit fokussierten Geschäftsmodellen.

Individualisierung durch Software ist hingegen notwendig für Unternehmen mit hochspezifischen Geschäftsprozessen. Die höheren initialen Investitionen zahlen sich langfristig durch strategische Wettbewerbsvorteile aus. Sie behalten volle Kontrolle über Features, Roadmap und technologische Entwicklung. Typisch ist dies für etablierte Mittelständler, Unternehmen mit komplexen B2B-Prozessen und Organisationen mit starkem technologischen Differenzierungsbedarf.

Die Realität liegt oft dazwischen. Die meisten erfolgreichen E-Commerce-Projekte finden einen pragmatischen Mittelweg: Sie nutzen bewährte Standard-Komponenten dort, wo sie passen, und investieren in Individualisierung dort, wo es geschäftskritisch ist.

Kriterien zur Wahl der richtigen E-Commerce-Plattform

Nachdem Sie die architektonischen Grundsatzentscheidungen getroffen haben, steht die Auswahl der konkreten E-Commerce-Plattform an. Diese Entscheidung sollte nicht isoliert erfolgen, sondern systematisch anhand mehrerer Kriterien bewertet werden.

Technologische Passung zur IT-Strategie

Die gewählte Plattform muss nahtlos in Ihre bestehende IT-Landschaft passen und Ihre langfristige IT-Strategie unterstützen. Wenn Sie sich für eine Headless-Architektur entschieden haben, muss die Plattform robuste APIs bereitstellen. Bei einem Monolithen sollte sie ausgereifte Integrationsmöglichkeiten mit Ihren bestehenden Systemen bieten.

Berücksichtigen Sie Ihre Cloud-Strategie: Setzen Sie konsequent auf Cloud-native Lösungen, oder benötigen Sie Flexibilität für hybride Deployments? Manche Organisationen haben aufgrund von Compliance-Anforderungen oder strategischen Entscheidungen klare Vorgaben, welche Infrastrukturmodelle in Frage kommen.

Funktionale Abdeckung: Out-of-the-Box vs. Customization

Plattformen mit umfangreichen Out-of-the-Box-Funktionen eignen sich hervorragend für Geschäftsmodelle mit standardisierten Anforderungen. Wenn Ihre Geschäftsprozesse sich gut in bewährte E-Commerce-Patterns einfügen – Produktkatalog, Warenkorb, Checkout, Bestellverwaltung – profitieren Sie von schneller Implementierung und geringeren Kosten.

Für komplexere oder hochspezifische B2B-Anforderungen sind individuelle Anpassungen unvermeidlich. Hier wird entscheidend, wie erweiterbar die Plattform ist: Wie umfangreich ist das Extension-Ökosystem? Wie gut dokumentiert sind APIs und Entwickler-Schnittstellen? Können kritische Geschäftsprozesse ohne Core-Modifikationen abgebildet werden?

Ein praktischer Ansatz besteht darin, eine Liste Ihrer zehn bis fünfzehn kritischsten Geschäftsanforderungen zu erstellen und bei jeder evaluierten Plattform zu prüfen, wie diese abgedeckt werden können – nativ, durch Extensions oder durch Custom Development.

Verfügbarkeit von Expertise und Partnern

Die beste Technologie nützt wenig, wenn Sie niemanden finden, der sie implementieren und warten kann. Die Verfügbarkeit von qualifizierten Agenturen und Entwicklern ist ein oft unterschätzter, aber geschäftskritischer Faktor.

Ein breites Netzwerk an erfahrenen Partnern bietet mehrere Vorteile: wettbewerbsfähige Preise durch größeren Markt, Flexibilität beim Wechsel zwischen Partnern, spezialisierte Expertise für unterschiedliche Anforderungen sowie geografische Nähe und lokaler Support.

Wenn Sie planen, eigene Entwicklerressourcen aufzubauen, sollten Sie prüfen, wie groß der Talentpool für diese Technologie ist, welche Gehaltsniveaus zu erwarten sind und wie attraktiv die Technologie für Entwickler ist – wichtig für Recruiting und Retention.

Die Pandemie hat die Verfügbarkeit von Remote-Entwicklern erhöht.¹⁰ Für populäre Plattformen wie Magento 2, Shopware 6 oder Shopify können Sie heute auf einen globalen Talentpool zugreifen, was die geografischen Einschränkungen deutlich reduziert.

Reife und Vitalität des Ökosystems

Ein vitales Ökosystem ist mehr als ein Nice-to-have – es ist ein Indikator für die langfristige Zukunftsfähigkeit der Plattform und ein praktischer Vorteil im Tagesgeschäft.

Messbare Indikatoren sind die Anzahl verfügbarer Extensions und wie aktiv diese gepflegt werden, Community-Aktivität in Form von Stack Overflow-Fragen, GitHub-Aktivität und Forum-Diskussionen, die Regelmäßigkeit von Updates und Security-Patches sowie die Qualität der Entwickler-Dokumentation – ist sie umfassend, aktuell und verständlich?

Eine etablierte Community bedeutet in der Praxis schnellere Problemlösungen durch geteiltes Wissen, bewährte Best Practices und Code-Patterns, Früherkennung von Bugs mit verfügbaren Workarounds sowie Innovation durch Community-Beiträge.

Vorsicht ist jedoch bei Hypes geboten. Nicht jede neue, gehypte Plattform hat ein reifes Ökosystem. Cutting-Edge-Technologie kann verlockend sein, birgt aber das Risiko, dass Sie Pionierarbeit leisten müssen, wo bei etablierten Plattformen bereits Lösungen existieren. Wägen Sie Innovation gegen Stabilität ab.

Zukunftssicherheit und Roadmap

E-Commerce-Plattformen sind langfristige Investitionen. Die Zukunftssicherheit der Plattform sollte ein zentrales Auswahlkriterium sein.

Prüfen Sie kritisch die Vendor-Roadmap: Kommuniziert der Anbieter transparent seine Produktvision? Werden regelmäßig neue Features entwickelt? Wie ist die Historie bei Breaking Changes, die wichtig für Upgrade-Aufwände ist? Bei Open Source sollten Sie fragen, wie aktiv die Core-Development-Community ist.

Die technologische Modernität zeigt sich darin, ob die Plattform auf aktuellen Technologie-Stacks basiert, moderne Standards wie Progressive Web Apps oder Headless APIs unterstützt und ob die Architektur zukunftsfähig oder bereits technisch überholt ist.

Verstehen Sie die End-of-Life-Zyklen der Plattform. Shopware 5 erreichte Ende 2024 End-of-Life, Magento 1 bereits 2020. Unternehmen, die diese Signale ignoriert haben, standen unter massivem Migrationsdruck. Prüfen Sie, wie der Anbieter mit Major-Version-Upgrades umgeht und wie lange ältere Versionen supportet werden.

Kostenstruktur und Total Cost of Ownership

Die Lizenzkosten sind nur die Spitze des Eisbergs. Für eine fundierte Entscheidung müssen Sie die Total Cost of Ownership (TCO) über den gesamten Lebenszyklus betrachten.

Zu den initialen Kosten gehören Lizenzgebühren bei proprietären Lösungen, Implementierungskosten für Agentur und Custom Development, Infrastruktur-Setup, Daten-Migration sowie Schulungen.

Die laufenden Kosten umfassen wiederkehrende Lizenzgebühren, Hosting und Infrastruktur, Wartung und Updates, Extension-Lizenzen sowie Support-Verträge.

Viele SaaS-Plattformen haben gestaffelte Preismodelle mit Limits bei API-Calls (oft wird es teuer, wenn Sie intensiv integrieren), bei der Anzahl der SKUs oder Produktvarianten, beim Transaktionsvolumen oder Umsatz sowie bei der Anzahl der Nutzer oder Admin-Accounts.¹¹ Diese Kosten können bei Wachstum exponentiell steigen.

Transparenz und Kalkulierbarkeit sind entscheidend. Bei Open-Source-Lösungen sind die Kosten planbarer, da keine Lizenzgebühren anfallen. Sie investieren in Entwicklung und Infrastruktur – Kosten, die Sie direkt kontrollieren können. Bei SaaS und proprietären Lösungen sollten Sie Preiserhöhungen und wachsende Nutzungsgebühren einkalkulieren.

Interne Expertise als strategischer Vorteil

Ein oft übersehener, aber entscheidender Faktor ist die vorhandene Expertise in Ihrem Team.

Wenn Ihr IT-Team bereits Erfahrung mit einem bestimmten Technologie-Stack hat – etwa PHP, Node.js oder .NET – sollte dies in Ihre Entscheidung einfließen. Die Lernkurve für eine neue Plattform ist erheblich kürzer, wenn die zugrundeliegenden Technologien bereits bekannt sind.

Die Vorteile interner Expertise zeigen sich in schnellerer Implementierung und kürzerer Time-to-Market, geringerer Abhängigkeit von externen Dienstleistern, besserer Kontrolle über Qualität und Timelines, der Möglichkeit zu schnellen Iterationen und Bugfixes sowie langfristig niedrigeren Betriebskosten. Mit starker interner Expertise können Sie fundierter entscheiden, wann es sinnvoll ist, Features selbst zu entwickeln statt teure Extensions zu lizenzieren.

Überschätzen Sie Ihre interne Expertise jedoch nicht. Die Aussage "Wir haben PHP-Entwickler" bedeutet nicht automatisch "Wir können Magento 2 effizient betreiben". Moderne E-Commerce-Plattformen sind hochkomplex. Investieren Sie in Schulungen oder kombinieren Sie interne Ressourcen mit erfahrenen externen Partnern, zumindest in der Anfangsphase.

Praktisches Vorgehen: Die Plattform-Evaluierungs-Matrix

Um eine strukturierte Entscheidung zu treffen, empfiehlt sich eine gewichtete Bewertungsmatrix. Listen Sie zunächst Ihre Kriterien auf und gewichten Sie diese nach Wichtigkeit, beispielsweise auf einer Skala von eins bis zehn. Bewerten Sie dann jede Plattform für jedes Kriterium, etwa auf einer Skala von eins bis fünf. Berechnen Sie anschließend gewichtete Scores, indem Sie Gewichtung und Bewertung multiplizieren, und vergleichen Sie objektiv die Gesamtscores.

Typische Kriterien mit ihren Gewichtungen könnten sein: funktionale Abdeckung mit höchster Priorität von zehn von zehn als geschäftskritisches Kriterium, TCO über drei Jahre mit neun von zehn aufgrund hoher finanzieller Relevanz, Verfügbarkeit von Partnern mit acht von zehn als operativ wichtig, interne Expertise mit sieben von zehn zur Risikoreduktion, Ökosystem-Reife ebenfalls mit sieben von zehn für langfristige Sicherheit, Zukunftssicherheit und Roadmap mit acht von zehn als strategisch relevant sowie Performance und Skalierbarkeit mit neun von zehn als technisch kritisch.

Für die finalen zwei bis drei Kandidaten empfiehlt sich ein zeitlich begrenzter Proof of Concept (PoC). Implementieren Sie Ihre drei bis fünf kritischsten Anforderungen als Prototyp. Dies gibt Ihnen reale Insights in Entwicklerproduktivität, Plattform-Eigenheiten und versteckte Komplexitäten, die in Verkaufspräsentationen nicht sichtbar werden.

Praktische Empfehlungen für die architektonische Entscheidung

Basierend auf Projekterfahrung und Marktbeobachtungen lassen sich folgende Leitlinien ableiten.

Für Start-ups und kleinere Händler empfiehlt sich ein Coupled Frontend, eine monolithische Backend-Architektur und SaaS als Deployment-Modell. Die Rationale dahinter ist der schnellste Weg zum Markt bei geringster Komplexität und niedrigsten Kosten.

Für mittelständische B2B-Händler eignet sich ein Coupled Frontend, wobei bei starken Omnichannel-Anforderungen Headless in Betracht gezogen werden sollte. Die Backend-Architektur kann ein Monolith oder Composable Commerce sein, während PaaS oder On-Premise als Deployment-Modelle sinnvoll sind. Die Rationale liegt in der Balance zwischen Flexibilität und Komplexität sowie Kontrolle über kritische Geschäftsprozesse.

Für große Unternehmen mit komplexen Anforderungen ist ein Headless Frontend die richtige Wahl. Die Backend-Architektur sollte Composable Commerce sein, in Ausnahmefällen Microservices, während PaaS oder On-Premise als Deployment-Modelle dienen. Die Rationale ist maximale Flexibilität für komplexe Omnichannel-Strategien bei voller Kontrolle.

Die wichtigste Empfehlung lautet jedoch: Starten Sie einfach, und skalieren Sie bei Bedarf. Ein gut strukturierter Monolith mit klaren Modul-Grenzen lässt sich schrittweise in Richtung Microservices oder Composable Commerce entwickeln, ohne dass Sie die Komplexität zu früh tragen müssen.

Fazit: Architektur als strategisches Werkzeug

Die Wahl der E-Commerce-Architektur ist keine technische Detailfrage, sondern eine strategische Entscheidung mit langfristigen Auswirkungen. Es gibt keine universell "richtige" Architektur – nur die Architektur, die optimal zu Ihren Geschäftsanforderungen, Ihren Ressourcen und Ihrer strategischen Ausrichtung passt.

Die entscheidenden Fragen, die Sie sich stellen sollten, lauten: Wie komplex ist unser Geschäftsmodell wirklich, und überschätzen wir die Notwendigkeit von Komplexität? Welche IT-Ressourcen stehen uns langfristig zur Verfügung, und können wir die gewählte Architektur dauerhaft betreiben und weiterentwickeln? Wie schnell müssen wir am Markt sein – ist Time-to-Market wichtiger als technologische Perfektion? Wo liegt unser strategischer Wettbewerbsvorteil, und wo sollten wir in Individualisierung investieren? Wie wird sich unser Geschäft in den nächsten drei bis fünf Jahren entwickeln, und wählen wir eine Architektur, die mit uns wachsen kann?

Die beste Architektur ist nicht die modernste oder komplexeste – sondern die, die Ihr Geschäft optimal unterstützt, von Ihrem Team effektiv betrieben werden kann und ausreichend Flexibilität für zukünftiges Wachstum bietet.

Im nächsten Schritt geht es um die konkrete Plattformwahl: Welche spezifischen Systeme und Lösungen passen zu der von Ihnen gewählten architektonischen Grundlage? Welche Kriterien sollten bei der Auswahl berücksichtigt werden? Und wie stellen Sie sicher, dass Ihre Wahl auch langfristig tragfähig bleibt?

Fußnoten

1. Swell: 28 Headless Commerce Trends for 2025. Research indicates businesses adopting headless achieve a 50% reduction in time to launch new digital experiences. This acceleration comes from decoupled frontend and backend development that allows teams to work simultaneously. Quelle: Swell.is ↩

2. Engineer in the Dark (Medium): Microservices Killed Our Startup. Monoliths Would've Saved Us (Dezember 2025). Ein Start-up verlor 6 Monate Entwicklungszeit und $800.000 Runway durch den Wechsel zu Microservices. Nach Rückkehr zum Monolithen: wieder shipping features, gute Response Times, manageable Infrastructure Costs. Quelle: Medium/Let's Code Future ↩

3. Java Code Geeks: Microservices vs Monoliths in 2026 (Dezember 2025). Platform Engineers kosten $140.000-$180.000 jährlich. Microservices benötigen 2-4 Platform Engineers vs. 1-2 Operations Engineers für Monolithen – zusätzliche Personalkosten von $140.000-$360.000 pro Jahr, die Infrastrukturkosten-Unterschiede in den Schatten stellen. Quelle: JavaCodeGeeks ↩

4. Magento 2 (Adobe Commerce): Open-Source E-Commerce-Plattform. Website: business.adobe.com/products/magento ↩ ↩²

5. Akeneo: Product Information Management (PIM) System. Website: akeneo.com ↩

6. Storyblok: Headless Content Management System. Website: storyblok.com ↩

7. Algolia: AI-Powered Search and Discovery Platform. Website: algolia.com ↩

8. Gartner: Composable Commerce Must Be Adopted for the Future of Applications (Juni 2020). "By 2023, organizations that have adopted a composable approach will outpace competition by 80% in the speed of new feature implementation." Mike Lowndes, Sandy Shen, aktualisiert August 2021. Referenziert u.a. bei: The Future of Commerce ↩

9. Shopware 6: Open-Source E-Commerce-Plattform. Website: shopware.com ↩

10. Second Talent & McKinsey: Remote Work & Hiring Statistics 2025 (September 2025). Remote hiring delivers 340% larger candidate pools and 16% faster time-to-hire. 74% of companies plan permanent remote work post-COVID (Gartner). By 2030, 1 billion people globally will work remotely, representing 30% of the global workforce. Quelle: Second Talent ↩

11. Smart SaaS: B2B SaaS Fees & Costs Beyond the Price Tag (März 2025). SaaS-Anbieter nutzen häufig API-Rate-Limits und versteckte Nutzungsgrenzen in Tiered-Pricing-Modellen. "Rate limits throttle how often apps can communicate unless you upgrade to a higher tier" und "Pay-per-call pricing forces businesses to pay based on API usage". Quelle: SmartSaaS.works ↩