Warum E-Commerce-Projekte nach dem Go-live scheitern

Die Champagner-Flasche ist leer, der Go-live war gestern. Die Agentur schickt die Schlussrechnung. Und ab morgen seid ihr allein mit einem System, das ihr nicht gebaut habt.

Ihr kennt die Bedienfläche, klar. Produkte anlegen, Bestellungen verwalten, vielleicht ein paar Einstellungen im Backend. Aber was passiert, wenn der erste Fehler im Checkout auftaucht? Wenn die Ladezeit nach drei Wochen einbricht? Wenn das ERP plötzlich keine Bestellungen mehr synchronisiert?

Dann greift ihr zum Telefon. Und stellt fest: Der Projektleiter, der euer System in- und auswendig kannte, ist längst im nächsten Projekt. Der Support-Vertrag deckt nur Bugs ab, keine Weiterentwicklung. Und die Dokumentation besteht aus einem halbfertigen Confluence-Space, den seit dem Launch niemand mehr angefasst hat.

Das ist kein Einzelfall. Das ist das Standardergebnis des klassischen Agenturmodells. Und die Zahlen belegen es.

Die Zahlen, die niemand gern hört

Es gibt eine unangenehme Wahrheit über IT-Projekte, die in Kickoff-Meetings nie auf der Agenda steht: Die meisten scheitern. Nicht dramatisch, nicht mit einem großen Knall. Sondern leise. Über Budget, hinter Zeitplan, unter den Erwartungen.

Die Standish Group analysiert seit über 25 Jahren die Erfolgsquote von IT-Projekten. Ihr aktueller Report zeigt: Nur 31% aller IT-Projekte werden als erfolgreich eingestuft. 50% sind "challenged", also über Budget, über Zeitplan oder mit reduziertem Funktionsumfang. Und 19% scheitern komplett.

Lest das nochmal: Weniger als ein Drittel aller IT-Projekte erreicht das, was versprochen wurde.

McKinsey und die Universität Oxford haben 5.400 IT-Projekte ausgewertet und das Bild wird noch deutlicher: 45% lagen über Budget. 7% über dem Zeitplan. Und 56% lieferten weniger Wert als erwartet. Das sind keine kleinen Startups mit wackeliger Finanzierung. Das sind große Unternehmen mit professionellem Projektmanagement und sechsstelligen Budgets.

Gartner spricht im Kontext digitaler Commerce-Plattformen eine noch härtere Sprache: Bis zu 90% der Digital-Commerce-Implementierungen scheitern oder werden innerhalb weniger Jahre deprioritiert. Der Grund: Unternehmen unterschätzen systematisch, was nach dem Go-live passiert.

Und in Deutschland? Die Bitkom-Studie 2025 zeigt: 53% der deutschen Unternehmen sagen, sie kämpfen mit der Umsetzung ihrer Digitalisierungsprojekte. Nicht mit der Strategie. Nicht mit der Vision. Mit der Umsetzung.

Die Gemeinsamkeit dieser Zahlen: Das Problem liegt fast nie an der Technologie. Die Plattformen funktionieren. Shopware und Shopify funktionieren beide. Commercetools funktioniert. Das Problem liegt in dem, was zwischen Technologie und Business-Ergebnis passiert. Und genau da endet bei den meisten Agenturen der Auftrag. Ob es um eine SAP Hybris Migration geht, um die Wahl der richtigen SAP-Alternative oder um den Wechsel von plentymarkets: Die Plattformwahl ist selten das Problem. Die Begleitung danach schon.

Die 5 häufigsten Post-Go-live-Killer

Der Go-live ist nicht der Moment, ab dem alles läuft. Er ist der Moment, ab dem alles laufen muss. Echte Nutzer, echte Bestellungen, echtes Geld. Und genau ab diesem Punkt zeigen sich die Schwächen, die im Projektverlauf unsichtbar waren.

Fünf Muster tauchen dabei mit erschreckender Regelmäßigkeit auf.

1. Kein Iterationsbudget

Das häufigste Problem, und das am leichtesten vermeidbare. Das Projektbudget war auf den Go-live kalkuliert. Jeder Euro floss in Entwicklung, Design, Migration. Am Launch-Tag ist das Budget aufgebraucht.

Aber kein System ist beim Go-live fertig. Das ist keine Schwäche. Das ist Realität. Ihr werdet Features finden, die in der Praxis anders genutzt werden als geplant. Ihr werdet Conversion-Killer entdecken, die erst mit echten Nutzern sichtbar werden. Ihr werdet Integrationen nachjustieren müssen, weil das ERP sich im Livebetrieb anders verhält als im Staging.

Ohne Iterationsbudget steht ihr vor der Wahl: Entweder ihr lebt mit den Problemen, oder ihr müsst intern um neues Budget kämpfen. Beides kostet mehr als die 15 bis 20 Prozent, die ihr von Anfang an hätten einplanen können.

2. Kein Monitoring, keine Performance-Baseline

Wann ist euer Shop schnell genug? Was ist eine "normale" Fehlerquote im Checkout? Wie viele 404-Seiten sind akzeptabel?

Wenn ihr diese Fragen nicht beantworten könnt, habt ihr kein Monitoring-Problem. Ihr habt ein Blindflug-Problem. Ohne Performance-Baselines, die vor dem Launch definiert wurden, erkennt ihr Verschlechterungen nicht. Ihr reagiert erst, wenn Kunden sich beschweren oder die Conversion einbricht. Und dann ist der Schaden bereits da.

Ein typisches Szenario: Drei Monate nach dem Launch sinkt die Conversion-Rate um 0,8 Prozentpunkte. Niemand bemerkt es, weil niemand die Ausgangswerte dokumentiert hat. Bei einem Shop mit 500.000 EUR Monatsumsatz sind 0,8 Prozentpunkte weniger Conversion schnell 40.000 bis 60.000 EUR entgangener Umsatz. Pro Monat.

3. Vendor-Handoff: Übergabe ins Nichts

Die Agentur hat das Projekt abgeschlossen. Es gibt einen Übergabetermin, vielleicht sogar einen Workshop. Zwei Stunden, in denen jemand durch das Backend klickt und erklärt, wo man was findet.

Dann ist die Agentur weg. Und mit ihr das gesamte Kontextwissen, das über Monate aufgebaut wurde: Warum wurde diese Architekturentscheidung getroffen? Welche Workarounds stecken im Checkout? Welche API-Limitierung des ERP hat zu dieser Custom-Lösung geführt?

Dieses Wissen ist nirgends dokumentiert, weil es "alle wussten". Alle bei der Agentur, wohlgemerkt. Nicht bei euch.

Wenn der erste kritische Bug auftritt, der tieferes Systemverständnis erfordert, steht ihr vor einer teuren Entscheidung: Die alte Agentur für ein Support-Ticket beauftragen (zu deren Stundensätzen und Verfügbarkeit) oder eine neue Agentur einarbeiten, die das System erst verstehen muss.

4. Fehlende Dokumentation

Dokumentation ist das Erste, was unter Zeitdruck gestrichen wird. Verständlich aus Projektsicht: Kein Stakeholder fragt nach Dokumentation. Alle fragen nach Features. Also fließt jede verfügbare Stunde in sichtbare Ergebnisse.

Die Rechnung kommt später. Wenn der erste Entwickler wechselt und sein Nachfolger drei Wochen braucht, um den Code zu verstehen. Wenn eine Integration angepasst werden muss und niemand weiß, welche Datenfelder wo gemappt sind. Wenn ein Plugin-Update die Konfiguration überschreibt und niemand die Original-Einstellungen kennt.

Fehlende Dokumentation ist die teuerste Form von technischen Schulden, weil sie jede zukünftige Änderung verteuert. Nicht einmalig, sondern dauerhaft.

5. SEO-Migration vergessen oder halbherzig

Ein Relaunch ohne saubere SEO-Migration ist wie ein Umzug, bei dem ihr vergesst, eure Adresse zu ändern. Die alten Kunden finden euch nicht mehr.

Das passiert erschreckend oft. URL-Strukturen ändern sich, Redirects werden nur für die 20 wichtigsten Seiten eingerichtet, Meta-Daten gehen verloren, die interne Verlinkung bricht. Das Ergebnis: 30 bis 50 Prozent Traffic-Verlust in den ersten Wochen nach dem Launch.

Bei einem Shop, der 40 Prozent seines Umsatzes über organischen Traffic generiert, sind 30 Prozent weniger Traffic nicht nur ein SEO-Problem. Sie sind ein Umsatzproblem. Und die Erholung dauert Monate, manchmal Jahre.

Das Tückische: SEO-Verluste zeigen sich verzögert. Nicht am Launch-Tag, sondern zwei bis vier Wochen später. Genau dann, wenn die Agentur längst im nächsten Projekt steckt und der Support-Vertrag nur "technische Bugs" abdeckt, nicht "strategische Versäumnisse".

Warum das Agenturmodell das Problem ist

Jetzt wird es unbequem. Denn die fünf Post-Go-live-Killer sind keine Einzelfehler. Sie sind Symptome eines strukturellen Problems: Das klassische Agenturmodell hat keinen eingebauten Anreiz, sich um das zu kümmern, was nach dem Go-live passiert.

Schauen wir uns die beiden gängigen Abrechnungsmodelle an.

Time & Material (T&M): Die Agentur wird nach Aufwand bezahlt. Das klingt fair, hat aber einen versteckten Fehler: Die Agentur hat keinen wirtschaftlichen Anreiz, effizient zu arbeiten oder das Projekt abzuschließen. Jede Stunde mehr ist eine Stunde mehr Umsatz. Jedes "Das ist komplexer als gedacht" erhöht die Rechnung. Die Agentur gewinnt, wenn das Projekt länger dauert.

Festpreis: Die Agentur liefert einen definierten Scope zu einem festen Preis. Das klingt nach Sicherheit, hat aber den umgekehrten Fehler: Die Agentur hat jetzt maximalen Anreiz, Ecken zu schneiden. Jede Stunde, die sie einspart, ist direkte Marge. Tests? Nur das Nötigste. Dokumentation? "Machen wir am Ende" (und am Ende ist kein Budget mehr). Performance-Optimierung? "Liegt im Rahmen des Akzeptablen."

Beide Modelle enden am selben Punkt: dem Go-live. Ab diesem Moment hat die Agentur ihre Schuldigkeit getan. Die Rechnung ist gestellt. Das Team wird auf das nächste Projekt umgeplant. Was mit eurem Shop danach passiert, ist vertraglich nicht ihr Problem.

Und genau hier liegt die strukturelle Lücke. Kein Abrechnungsmodell misst Outcomes. Keines fragt: Funktioniert der Shop sechs Monate nach dem Launch noch so, wie er soll? Stimmt die Conversion? Sind die Betriebskosten im Rahmen? Hat das Team die Kompetenz, das System weiterzuentwickeln?

Was fehlt, ist keine bessere Agentur. Was fehlt, ist ein anderes Modell: eine Partnerschaft, die am Ergebnis gemessen wird, nicht am Projektabschluss.

Das bedeutet nicht, dass jede Agentur schlecht arbeitet. Es gibt hervorragende Agenturen mit engagierten Teams. Aber das System, in dem sie arbeiten, belohnt die falschen Dinge. Es belohnt Projekte, nicht Ergebnisse. Es belohnt Go-lives, nicht Wachstum.

Was echte E-Commerce-Beratung nach dem Go-live bedeutet

Wenn wir bei datrycs von E-Commerce-Beratung sprechen, meinen wir nicht: "Wir schreiben euch ein Konzeptpapier und wünschen viel Erfolg." Wir meinen: Wir stehen noch da, wenn der Champagner längst schal ist.

Das klingt nach Marketingversprechen. Ist es aber nicht. Es ist das direkte Ergebnis einer Erkenntnis, die aus der Praxis stammt: Wer selbst auf der Händler-Seite gestanden hat, weiß, dass der Go-live der Anfang ist, nicht das Ende.

Konkret sieht das so aus:

Hypercare-Phase: Die ersten 90 Tage

Die kritischste Phase jedes E-Commerce-Projekts sind die ersten 90 Tage nach dem Launch. In dieser Zeit zeigt sich, was im Projekt übersehen wurde. Nicht weil jemand schlampig gearbeitet hat, sondern weil bestimmte Probleme erst unter realen Bedingungen sichtbar werden.

Eine seriöse E-Commerce-Beratung plant diese Phase von Anfang an ein. Dediziertes Team, definierte Reaktionszeiten, klare Eskalationswege. Nicht als optionalen Zusatz-Service, sondern als festen Bestandteil des Projekts.

Was in der Hypercare-Phase passiert: tägliches Performance-Monitoring, wöchentliche Review-Calls, sofortige Reaktion auf kritische Bugs, Analyse von echtem Nutzerverhalten vs. geplanten User Journeys, Feintuning der Integrationen im Livebetrieb.

Performance-Baselines vor dem Launch

Ihr könnt nicht messen, was ihr nicht definiert habt. Deshalb gehören Performance-Baselines in die Projektplanung, nicht in die Nachbetreuung.

Das Minimum:

• Ladezeiten: Time to First Byte (TTFB), Largest Contentful Paint (LCP), Time to Interactive (TTI) pro Seitentyp (Startseite, Kategorie, Produkt, Checkout)
• Core Web Vitals: CLS, INP als harte Schwellenwerte
• Conversion-Benchmarks: Checkout-Completion-Rate, Warenkorbabbrüche, durchschnittlicher Bestellwert
• Uptime-Ziele: 99,9% klingt gut, aber was passiert bei 99,5%? Was ist der Eskalationsweg?
• Error-Budgets: Ab welcher Fehlerquote wird reagiert, nicht erst wenn der Shop steht?

Diese Baselines sind kein Nice-to-have. Sie sind die Grundlage dafür, dass ihr nach dem Launch objektiv bewerten könnt, ob euer Shop so funktioniert, wie er soll.

Iterationsbudget einplanen

Die Faustregel: Plant 15 bis 20 Prozent eures Projektbudgets als Iterationsbudget ein. Nicht als Puffer für Unvorhergesehenes im Projekt, sondern als dediziertes Budget für die Zeit nach dem Launch.

Bei einem Projektbudget von 200.000 EUR sind das 30.000 bis 40.000 EUR. Klingt nach viel? Rechnet dagegen, was ein einzelner Tag Downtime kostet. Für mittelständische Online-Händler liegen die Kosten bei 50.000 bis 100.000 USD pro Stunde. In der Peak Season kann es für größere Händler schnell auf 1 bis 2 Millionen USD pro Stunde steigen. Das relativiert die 30.000 EUR Iterationsbudget ziemlich schnell.

Dokumentation als Deliverable

Dokumentation ist kein Bonus. Sie ist ein Deliverable, das im Vertrag steht, im Projektplan terminiert ist und vor dem Go-live abgenommen wird.

Das bedeutet nicht hundert Seiten PDF, die niemand liest. Es bedeutet:

• Architektur-Dokumentation: Welche Systeme sprechen wie miteinander? Warum diese Architektur und nicht eine andere?
• Entscheidungs-Log: Welche Alternativen wurden evaluiert und warum verworfen?
• Runbook: Was tun bei den zehn wahrscheinlichsten Fehlern?
• Integrations-Map: Welche API-Endpoints, welche Datenfelder, welche Transformationen?
• Onboarding-Guide: Wie macht sich ein neuer Entwickler in einer Woche produktionsbereit?

Wenn eure Agentur bei der Frage nach Dokumentation die Augen verdreht, habt ihr eure Antwort.

Checkliste: Daran erkennt ihr eine Agentur, die nach dem Go-live verschwindet

Druckt diese Liste aus. Nehmt sie mit in euer nächstes Agentur-Gespräch. Und achtet auf die Reaktionen.

Warnsignale:

• Das Angebot endet beim Go-live. Keine Hypercare-Phase, kein Post-Launch-Support im Vertrag.
• Auf die Frage "Was passiert nach dem Launch?" kommt: "Dafür gibt es unseren Support-Vertrag." (Support ist nicht dasselbe wie Weiterentwicklung.)
• Kein Wort über Performance-Baselines oder Monitoring im Angebot.
• Dokumentation wird als "optional" oder "nach Aufwand" gelistet.
• Die SEO-Migration besteht aus einer Redirect-Liste, die "jemand am Ende" erstellt.
• Das Team, das euer Projekt baut, wird euch nicht nach dem Launch betreuen.
• Die Agentur kann nicht erklären, was passiert, wenn ihr nach sechs Monaten ein Problem habt.
• Es gibt kein Iterationsbudget im Projektplan.
• Auf die Frage nach Referenzen für langfristige Partnerschaften kommt Schweigen.
• Die Agentur redet nur über Features, nie über Business-Outcomes.

Positive Signale:

• Die Agentur fragt nach euren Business-KPIs, nicht nur nach dem Feature-Scope.
• Es gibt einen konkreten Plan für die ersten 90 Tage nach dem Launch.
• Performance-Baselines werden vor dem Launch gemeinsam definiert.
• Dokumentation hat einen eigenen Posten im Angebot.
• Die SEO-Migration wird von Anfang an mitgeplant, nicht als Nachgedanke.
• Das Team bleibt nach dem Launch ansprechbar, mit definierten Reaktionszeiten.
• Die Agentur hat Kunden, die sie seit Jahren betreut, nicht nur Projekte, die sie abgeschlossen hat.

Wie datrycs das anders macht

Wir könnten jetzt behaupten, dass wir alles besser machen. Stattdessen erklären wir, warum wir es anders machen.

datrycs ist entstanden, weil die Gründer selbst auf der Händler-Seite standen. Bei Lampenwelt.de, einem der größten Lighting-E-Commerce-Unternehmen Europas. Dort haben sie erlebt, was es bedeutet, nach einem Relaunch allein dazustehen. Sie haben die Support-Tickets geschrieben, die drei Tage ohne Antwort blieben. Sie haben das Iterationsbudget erkämpft, das im ursprünglichen Angebot nicht vorgesehen war. Sie haben die Dokumentation selbst geschrieben, weil die Agentur es nicht getan hat.

Diese Erfahrung ist der Grund, warum bei datrycs jedes Projekt über den Go-live hinaus geplant wird. Nicht als Upselling. Sondern weil wir wissen, dass ein Shop, der am Launch-Tag funktioniert, noch lange kein erfolgreicher Shop ist.

Konkret heißt das:

• Jedes Projekt hat eine definierte Hypercare-Phase.
• Performance-Baselines werden vor dem Launch gemeinsam mit dem Kunden definiert.
• Dokumentation ist ein Deliverable, kein Anhängsel.
• Das Team, das baut, bleibt nach dem Launch ansprechbar.
• Wir messen uns an Business-Ergebnissen, nicht an Feature-Listen.

Klingt das nach dem, was eine gute E-Commerce-Beratung leisten sollte? Dann stellt sich die Frage, warum es so selten passiert. Die Antwort kennt ihr jetzt: Weil das Agenturmodell es nicht belohnt.

FAQ: Häufige Fragen zu E-Commerce-Projekten nach dem Go-live

Warum scheitern E-Commerce-Projekte trotz hoher Budgets?

Budget allein schützt nicht vor dem Scheitern. Die Standish Group zeigt, dass auch Projekte mit großen Budgets zu 69% ihre Ziele verfehlen. Die häufigsten Gründe: Das Budget endet beim Go-live, es gibt kein Iterationsbudget, Performance-Baselines fehlen, und die Verantwortung der Agentur endet mit der Schlussrechnung. Es geht nicht darum, mehr Geld auszugeben, sondern darum, es an den richtigen Stellen einzusetzen.

Was kostet ein fehlgeschlagener E-Commerce-Relaunch?

Die direkten Kosten sind oft das kleinere Problem. Downtime kostet mittelständische Online-Händler 50.000 bis 100.000 USD pro Stunde. In der Peak Season steigen die Kosten für größere Händler auf 1 bis 2 Millionen USD pro Stunde. Dazu kommen indirekte Kosten: SEO-Traffic-Verluste von 30 bis 50 Prozent, Vertrauensverlust bei Stammkunden, interne Ressourcen für Firefighting statt Wachstum. Ein gescheiterter Relaunch kann leicht das Drei- bis Fünffache des ursprünglichen Projektbudgets kosten.

Was ist eine Hypercare-Phase und warum ist sie wichtig?

Die Hypercare-Phase sind die ersten 90 Tage nach dem Go-live. In dieser Zeit zeigen sich Probleme, die im Projektverlauf unsichtbar waren, weil sie erst unter realen Bedingungen auftreten: echte Nutzer, echte Bestellvolumen, echte Lastspitzen. Eine gute E-Commerce-Beratung plant diese Phase fest ein, mit dediziertem Team, definierten Reaktionszeiten und täglichem Performance-Monitoring. Ohne Hypercare-Phase seid ihr ab Tag 1 auf euch allein gestellt.

T&M vs. Festpreis: Welches Modell schützt nach dem Go-live?

Keines von beiden. T&M gibt der Agentur keinen Anreiz, effizient zu arbeiten. Festpreis gibt der Agentur maximalen Anreiz, Ecken zu schneiden. Beide Modelle enden beim Go-live. Was ihr braucht, ist eine Partnerschaft, die an Business-Outcomes gemessen wird, nicht an Stunden oder Meilensteinen. Fragt bei der Agenturauswahl nicht nur nach dem Abrechnungsmodell, sondern nach der Zusammenarbeit nach dem Launch.

Wie finde ich eine E-Commerce-Beratung, die wirklich bleibt?

Stellt drei Fragen. Erstens: "Was passiert nach dem Go-live?" Wenn die Antwort "Support-Vertrag" ist, habt ihr eure Antwort. Zweitens: "Zeigt mir Kunden, die ihr seit mehr als zwei Jahren betreut." Wer nur Projekte vorweisen kann, aber keine langfristigen Partnerschaften, wird auch bei euch nach dem Launch verschwinden. Drittens: "Wer betreut mich nach dem Launch?" Wenn es ein anderes Team ist als das Projektteam, geht Kontext verloren. Nutzt die Checkliste aus diesem Artikel als Gesprächsleitfaden.

Wie viel Iterationsbudget sollte ich nach dem Go-live einplanen?

Die Faustregel: 15 bis 20 Prozent eures Projektbudgets. Bei einem 200.000 EUR Projekt sind das 30.000 bis 40.000 EUR für die Post-Launch-Phase. Dieses Budget deckt die Hypercare-Phase, erste Optimierungen basierend auf echten Nutzerdaten, Performance-Feintuning und kleinere Feature-Anpassungen. Wenn das im Verhältnis zu den Kosten eines einzigen Tages Downtime steht, relativiert sich die Summe schnell.

Mein letzter Relaunch ist gescheitert. Was kann ich jetzt tun?

Zunächst: Die Diagnose stellen. Wo genau habt ihr Probleme? Performance, Conversion, Integrationen, SEO-Verluste? Dann priorisieren: Nicht alles gleichzeitig, sondern den größten Hebel zuerst. Häufig sind das technische Schulden, die im Relaunch mitgeschleppt oder neu aufgebaut wurden. Und schließlich: Einen Partner suchen, der bereit ist, das System zu übernehmen und langfristig zu stabilisieren. Wenn ihr dabei Hilfe braucht, meldet euch.

Nächster Schritt

Ihr plant einen Relaunch, steckt mitten in einem Projekt oder habt gerade einen Go-live hinter euch, der sich nicht so anfühlt wie erhofft? Dann lasst uns reden. Nicht über Features. Über Ergebnisse.

Sprecht uns an