Rettung und Übernahme von Magento-Projekten

Ein Magento-Projekt muss nicht von Grund auf neu entwickelt werden, nur weil der aktuelle Anbieter nicht liefert, Fehler zurückkehren und jede weitere Änderung schwieriger wird.

Wir übernehmen problematische Magento-Plattformen, ermitteln die Ursachen und stabilisieren kritische Bereiche. Das Ziel ist nicht der nächste Notfalleinsatz, sondern ein Projektzustand, in dem die Weiterentwicklung wieder planbar wird.

Ein kostenloses Gespräch von 30–60 Minuten. Wir lernen den Projektzustand, die dringendsten Probleme und das aktuelle Kooperationsmodell kennen. Wir skizzieren, wie eine sichere Übernahme aussehen kann und wo die Stabilisierung beginnen sollte.

Ausgangslage

Wenn das Problem mehr als ein einzelner Fehler ist

Unternehmen kommen meist dann mit einem Rescue-Projekt zu uns, wenn sich die Probleme zu einem wiederkehrenden Muster verdichten.

Der bisherige Anbieter benötigt immer mehr Zeit für Änderungen.

Der Backlog wächst schneller, als er abgearbeitet wird.

Dieselben Fehler kehren nach jeder weiteren Korrektur zurück.

Neue Funktionen destabilisieren andere Systemteile.

Der Shop hat Performanceprobleme oder funktioniert zeitweise nicht richtig.

Intern lassen sich die grundlegenden Fragen immer schwerer beantworten: Liegt das Problem im Code, in einer Integration, der Datenbank, der Infrastruktur oder im Projektmanagement?

Der gemeinsame Nenner ist der Verlust an Berechenbarkeit. Die Plattform verkauft möglicherweise noch, bietet aber keine verlässliche Grundlage mehr für die Planung weiterer Entwicklung.

Bei Rescue geht es nicht darum, einige Tickets zu schließen. Es geht darum, die Kontrolle über die Plattform zurückzugewinnen.

Diagnose

Zuerst die Diagnose, dann die Zusagen

Wir beginnen nicht mit der Annahme, bereits zu wissen, was neu geschrieben werden muss.

Im ersten Gespräch klären wir die aktuelle Situation, die Projekthistorie und die wichtigsten Symptome. Mit den verfügbaren Informationen können wir das Ausmaß zunächst einschätzen und die Bereiche bestimmen, die eine tiefere Diagnose erfordern.

Eine gründlichere Analyse kann eine eigene Projektphase sein. Ihren Umfang passen wir an die Situation an – nicht jeder Shop benötigt dasselbe Audit.

Je nach Problemlage analysieren wir unter anderem:

  • individuellen Code und Magento-Module,
  • die Plattformkonfiguration,
  • Logs und Fehlerhistorie,
  • die Datenbank,
  • Frontend und Checkout,
  • die Performance,
  • Integrationen mit ERP, PIM, CRM und individuellen Systemen,
  • Cron und Warteschlangen,
  • OpenSearch oder Elasticsearch,
  • Redis und Varnish,
  • die Infrastruktur,
  • den Deployment-Prozess,
  • den Backlog und die Projektdokumentation.

Entscheidung

Die Diagnose muss zu einer Entscheidung führen

Eine Liste gefundener Fehler allein hat nur begrenzten Wert.

Nach der Analyse sollte klar sein:

Diagnoseergebnis

  • welche Probleme kritisch sind,

  • welche nur Symptome eines anderen Problems sind,

  • was zuerst behoben werden muss,

  • was unverändert bleiben kann,

  • welche Bereiche neu aufgebaut statt weiter ausgebessert werden sollten,

  • wie Übernahme und Stabilisierung ablaufen sollen.

Das Ergebnis sollte ein konkretes Arbeitsdokument sein: eine Beschreibung der wichtigsten Probleme und ihrer Ursachen, Prioritäten und ein empfohlener Maßnahmenplan.

Wenn weitere Reparaturen an einem Bereich technisch oder wirtschaftlich nicht sinnvoll sind, sagen wir das offen. Manchmal ist die Neuentwicklung eines Moduls, Frontends, Checkouts oder einer Integration die richtige Lösung statt weiterer punktueller Korrekturen.

Rescue sollte nicht bedeuten, bestehenden Code um jeden Preis zu verteidigen.

Übergabe

So übernehmen wir ein Projekt von einem anderen Anbieter

Der reine Agenturwechsel löst das Problem nicht. Wissen, Zugänge und die Verantwortung für eine laufende Plattform müssen ebenfalls übertragen werden.

Wir helfen unter anderem bei der Organisation folgender Bereiche:

  • Repositories und Quellcode,
  • Umgebungen,
  • Server, Hosting oder Cloud-Infrastruktur,
  • Deployment-Prozess und CI/CD,
  • Konten und Zugänge für Magento und die eingesetzten Dienste,
  • Integrationen und ihre Konfiguration,
  • Module und Lizenzen,
  • Dokumentation,
  • Backlog,
  • Wissen über die Geschäftsprozesse.

Erfordert es die Situation, arbeiten wir während einer Übergangszeit mit dem bisherigen Anbieter zusammen. Ein abrupter Schnitt ist nicht immer die risikoärmste Lösung.

Entscheidend ist, dass nach der Übergabe klar ist, wer die Plattform verantwortet, welche Prioritäten gelten und wie weitergearbeitet wird.

Verantwortung

Wir übernehmen bevorzugt die Verantwortung für die gesamte Plattform

Wir können einen ausgewählten Projektbereich übernehmen. Das ist jedoch nicht unser bevorzugtes Rescue-Modell.

In einer komplexen Magento-Plattform enden Probleme selten an einer Modulgrenze. Ein langsamer Checkout kann seine Ursache in individuellem Code, einer Integration oder der Datenbank haben. Importprobleme können die Indexierung beeinträchtigen. Ein Infrastrukturausfall kann wie ein Anwendungsfehler aussehen.

Wenn mehrere Teams für voneinander abhängige Plattformteile verantwortlich sind, verschwimmen Zuständigkeiten leicht. Die Diagnose endet dann dort, wo der Leistungsumfang eines anderen Anbieters beginnt.

Deshalb übernehmen wir bei Rescue-Projekten bevorzugt die gesamte Plattform und steuern die Prioritäten zentral.

Die Übernahme einzelner Bereiche ist möglich. Dann legen wir die Grenzen unserer Verantwortung eindeutig fest.

Prioritäten

Zuerst Stabilität, dann die Roadmap für neue Funktionen

Nach der Übernahme beginnen wir nicht mit den ältesten Tickets im Backlog.

Zuerst bearbeiten wir die Bereiche mit dem größten Einfluss auf die Plattform:

  • Bestellprozess und Checkout,
  • Fehler, die Ausfälle verursachen,
  • Plattformperformance,
  • Integrationen,
  • Indexierung und Suche,
  • geplante Aufgaben und Warteschlangen,
  • Deployment,
  • Infrastruktur.

Das Ziel ist, Risiken zu reduzieren und eine stabile Ausgangsbasis zu schaffen.

Erst danach ist die Rückkehr zur Roadmap für neue Funktionen sinnvoll. Andernfalls wird weiterhin auf einer Plattform entwickelt, deren Verhalten schwer vorhersehbar ist.

  1. Stabilisierung

  2. Kontrolle

  3. Weiterentwicklung

Danach

Rescue endet nicht, sobald „der Shop wieder läuft“

Eine Notfallkorrektur kann den Checkout innerhalb eines Tages wiederherstellen. Sie erklärt aber nicht, warum das Problem auftrat oder ob es mit dem nächsten Deployment zurückkehrt.

Sobald das Projekt stabil ist, kümmern wir uns deshalb um Ursachen und nicht nur um Symptome.

Die weitere Zusammenarbeit kann Folgendes umfassen:

  • Monitoring,
  • Magento-Updates,
  • schrittweisen Abbau technischer Altlasten,
  • Architekturverbesserungen,
  • Entwicklung neuer Funktionen,
  • Umsetzung der Roadmap.

Wir können die langfristige Wartung und Weiterentwicklung übernehmen. Das ist jedoch keine Voraussetzung für Rescue.

Das angestrebte Ergebnis ist eine Plattform, über die das Unternehmen wieder die Kontrolle hat.

Technischer Magento-Support und Wartung →

Beispiele

Zwei unterschiedliche Szenarien für die Übernahme einer problematischen Plattform

Übernahme eines PWA-Projekts: Wenn weitere Korrekturen nicht mehr sinnvoll sind

Bei einem von uns übernommenen Magento-Projekt war das Frontend zuvor als PWA umgesetzt worden.

Das Problem war nicht PWA an sich, sondern die Art der Umsetzung. Die Plattform enthielt viele Implementierungsfehler. Korrekturen verursachten neue Regressionen, und selbst kleine Änderungen erforderten unverhältnismäßig viel Aufwand.

Dieselben Probleme kehrten wieder, während die Frontendentwicklung teurer und schwerer planbar wurde.

Wir kamen zu dem Schluss, dass weitere Einzelkorrekturen nicht gerechtfertigt waren. Das Magento-Backend blieb erhalten. Das Frontend und die problematischen Bereiche wurden mit einer anderen Lösung neu aufgebaut.

Das zeigt die Grenze zwischen Reparatur und Neuaufbau. Rescue bedeutet nicht automatisch, die gesamte Plattform neu zu schreiben. Manchmal ist es richtig, Funktionierendes zu erhalten und einen Bereich zu ersetzen, dessen weitere Wartung mehr kosten würde als die Neuentwicklung.

Übernahme eines Shops nach einem Angriff: Zuerst den Vertrieb wiederherstellen

In einem anderen Projekt übernahmen wir einen Magento-Shop nach einem schweren Sicherheitsvorfall. Der Zugang zu Infrastruktur, Code und Umgebungsinformationen war stark eingeschränkt. Die Plattform konnte nicht einfach aus einer vollständigen aktuellen Sicherung gestartet werden.

Das erste Ziel war weder ein Audit noch die Bereinigung der Architektur. Wir mussten die Kontrolle zurückgewinnen, das Projekt aus unterschiedlichen Quellen zusammensetzen und möglichst schnell wieder einen funktionsfähigen Shop bereitstellen.

Mit verfügbaren Codekopien, alten Sicherungen und anderen erhaltenen Bestandteilen rekonstruierten wir die Plattform sowie die zentralen Daten und Prozesse für die Wiederaufnahme des Verkaufs.

Zu den Arbeiten gehörten:

  • verfügbare Zugänge übernehmen und ordnen,
  • vorhandene Code- und Datenversionen zusammentragen,
  • erhaltene Sicherungen analysieren,
  • die Umgebung aus verfügbaren Quellen rekonstruieren,
  • zentrale Vertriebsprozesse wiederherstellen,
  • Integrationen und externe Dienste prüfen,
  • kritische Verkaufshindernisse beseitigen,
  • die wiederhergestellte Umgebung absichern und stabilisieren.

Die Zeit, in der der Shop nicht normal verkaufen konnte, sollte so kurz wie möglich bleiben.

Wir warteten nicht, bis alles perfekt geordnet war. Zuerst brachten wir die Plattform in einen Zustand, der die wichtigsten Geschäftsprozesse sicher unterstützte. Diagnose, Infrastrukturbereinigung und Stabilisierung wurden anschließend fortgesetzt.

Das zeigt die andere Seite von Rescue. Eine reguläre Übernahme kann mit Diagnose und Planung beginnen. In einer Krise kann die Reihenfolge anders aussehen:

zuerst die Kontrolle zurückgewinnen, den Vertrieb wiederherstellen und Risiken reduzieren – und erst danach die Plattform in den Zielzustand bringen.

Bedenken

Anbieterwechsel nach einer schlechten Erfahrung?

Den Anbieter eines problematischen Projekts zu wechseln ist schwieriger, als eine neue Implementierung zu beginnen. Das Unternehmen hat bereits Kosten, Verzögerungen und oft mehrere Versuche erlebt, dieselben Probleme zu beheben.

Drei Bedenken begegnen uns besonders häufig.

„Der neue Anbieter wird Monate brauchen, um das Projekt zu verstehen“

Wir versprechen nicht, ein komplexes System in wenigen Tagen zu verstehen. Die Einarbeitung ist aber keine separate, monatelange Phase. Die Diagnose schafft Verständnis und Prioritäten, während kritische Probleme parallel bearbeitet werden können.

„Woher wissen wir, dass es nicht wieder genauso wird?“

Wir erwarten kein Vertrauen allein aufgrund von Zusagen. Die erste Phase ermittelt Ursachen, trennt kritische Probleme und legt die Arbeitsreihenfolge fest. Wir sagen klar, was neu aufgebaut werden sollte und was bleiben kann.

„Der Anbieterwechsel verursacht weitere Kosten, bevor sich etwas verbessert“

Eine Übernahme erfordert Arbeit. Deshalb konzentrieren wir uns zuerst auf die größten Geschäftsrisiken: Ausfälle, Checkout, Performance und Integrationen. Wir wollen Verluste schnell reduzieren und zugleich Wissen für die weitere Stabilisierung aufbauen.

Team

Warum Velocity

Magento ist unsere Kernkompetenz.

Wir arbeiten mit Frontend, Shopfunktionen, Integrationen, Datenbanken, Suche, Cache und Infrastruktur.

Das ist bei Rescue entscheidend, weil die Ursache eines Problems häufig nicht dort liegt, wo das Symptom sichtbar wird.

Unsere Experten bewerten die Plattform auch mit Blick auf die spätere Wartung. Bleiben wir nach der Stabilisierung, arbeiten wir selbst mit den Entscheidungen, die während Rescue getroffen wurden.

Uns ist nicht nur wichtig, dass eine Korrektur heute funktioniert, sondern auch, dass sich die Plattform später sicher weiterentwickeln lässt.

Verwandte Lösungen

Wann diese Dienstleistung nicht die richtige ist

Sie entwickeln eine neue Plattform von Grund auf

Wenn wir ein neues System konzipieren, statt ein problematisches Magento zu übernehmen, ist eine neue Implementierung der passende Weg.

Magento-Implementierung →

Neue Funktionen haben vom ersten Tag an alleinige Priorität

Bei Rescue müssen zuerst die Grundlagen stabilisiert werden. Gibt es keinen Spielraum, technische Probleme zu lösen, ist dieses Modell vermutlich nicht passend.

Fragen

FAQ

VLCT

Ja. Die Übernahme von einem anderen Anbieter ist eines der zentralen Rescue-Szenarien. Wir helfen sowohl bei der technischen Organisation als auch beim eigentlichen Übergabeprozess.

VLCT

Nicht immer. Wenn es das Risiko reduziert, können wir eine Zeit lang mit dem bisherigen Anbieter zusammenarbeiten und die Verantwortung schrittweise übernehmen.

VLCT

Der Umfang hängt vom Projekt ab. Einen Teil der Diagnose können wir bereits in den ersten Gesprächen und bei der Sichtung verfügbarer Informationen durchführen. Komplexere Probleme erfordern eine separate technische Phase mit Zugriff auf Code, Logs und Umgebungen.

VLCT

Das hängt von Plattformgröße, Zahl der Anpassungen und Integrationen sowie Dokumentationsqualität ab. Wir betrachten die Einarbeitung jedoch nicht als separate, monatelange Wartephase vor der eigentlichen Arbeit. Kritische Bereiche können bereits bearbeitet werden, während wir unser Systemverständnis vertiefen.

VLCT

Nein. Zuerst bewerten wir den Zustand der einzelnen Bereiche. Ein Teil lässt sich meist erhalten, andere Elemente müssen repariert werden. Bei manchen ist eine Neuentwicklung wirtschaftlicher als die weitere Wartung.

VLCT

Das ist möglich, wir bevorzugen jedoch die Verantwortung für die gesamte Plattform. Magento-Probleme überschreiten häufig die Grenzen einzelner Bereiche. Bei einem begrenzten Umfang legen wir deshalb klar fest, wofür wir verantwortlich sein können.

VLCT

Ja. Der Umfang hängt von der Situation und den verfügbaren Ressourcen ab. In kritischen Fällen geht es zunächst darum, Zugänge, Code und Daten zurückzugewinnen und die wichtigsten Vertriebsprozesse wiederherzustellen. Die vollständige Diagnose und Bereinigung können fortgesetzt werden, sobald die Plattform wieder online ist.

VLCT

Die Plattform kann in einen regulären Wartungs- und Entwicklungsbetrieb übergehen: Monitoring, Updates, schrittweiser Abbau technischer Altlasten und Umsetzung der Roadmap für neue Funktionen.