IOX Insights
Damit dein Produkt weiterläuft – ganz gleich, was passiert
Was passiert eigentlich mit deinem vernetzten Produkt, wenn der Partner wegfällt, der es entwickelt hat? Für immer mehr Hersteller ist das keine theoretische Frage. Namen wie grandcentrix, Tresmo oder aconno stehen für einen Markt, der sich gerade spürbar neu sortiert. Und den Kunden, die daran hängen, bleibt oft nur eine kurze Vorwarnung.
Das Problem, das auf der Hand liegt
Wenn dein Entwicklungspartner wegfällt, ist die erste Frage naheliegend: Wer kümmert sich jetzt um mein Produkt? Wer pflegt die Firmware, wer betreibt die Cloud, wer rollt im Ernstfall ein Update für tausende Geräte im Feld aus? Wer kümmert sich um Sicherheitsupdates? Der Reflex ist verständlich. Der Erstreflex ist verständlich. Man will schnell einen Ersatz finden, damit nichts liegen bleibt.
Genau dieser Reflex ist aber die erste Falle. Ein neuer Partner, der ohne saubere Übergabe einsteigt, arbeitet sich monatelang in ein fremdes System ein, ohne die Hintergründe zu kennen. Dabei wiederholt er womöglich Fehler, die längst gelöst waren. Bevor du über Lösungen nachdenkst, lohnt sich deshalb ein Blick auf die Probleme, die auf den ersten Blick noch gar nicht sichtbar sind.
Was du jetzt nicht übersehen solltest
Das eigentliche Risiko ist nämlich nicht, kurz ohne Betreuung dazustehen. Es ist der dauerhafte Verlust dessen, was dein Produkt am Leben hält.
Da ist zuerst die Frage nach Code und Rechten. Gehört dir eigentlich, was du bezahlt hast? Liegt dir der vollständige Quellcode von Firmware, Backend und Apps vor, inklusive Repositories, Zertifikaten und Dokumentation? Und sind die Nutzungsrechte eindeutig bei dir? Was du dir jetzt nicht sicherst, ist nach der endgültigen Schließung oft nicht mehr zu bekommen.
Dann die Infrastruktur. Läuft die Cloud auf deinen eigenen Konten oder auf denen des Dienstleisters? Wer hat Zugriff, wer zahlt, was passiert mit den Daten? Eine Infrastruktur in fremder Hand ist der häufigste Grund, warum ein Übergang ins Stocken gerät.
Heikel wird es bei den Sicherheitsupdates. Ein Gerät, das keine Updates mehr bekommt, wird mit der Zeit zum Risiko. Das gilt für deine Nutzer*innen und, mit Blick auf den Cyber Resilience Act, auch für dich als Hersteller.
Und schließlich das undokumentierte Wissen, also Entscheidungen, Workarounds und Eigenheiten der Hardware, die niemand aufgeschrieben hat. Es geht mit den Menschen verloren, die das Team verlassen. Und die verlassen ein Unternehmen in Auflösung schneller, als man denkt. Oft ist das wertvollste Wissen schon weg, bevor die Schließung überhaupt offiziell ist. Der trügerischste Gedanke in dieser Phase ist deshalb „wir haben ja noch Zeit“.
Unser Rat: erst sichern, dann entscheiden
Die gute Nachricht: Ein Produkt, das im Markt funktioniert, verliert durch die Schließung seines Dienstleisters nicht seinen Wert. Es verliert erst einmal nur seinen Betreuer, und diese Lücke lässt sich schließen. Entscheidend ist die Reihenfolge.
Nimm dir die ersten Wochen für einen ehrlichen Kassensturz und kläre dabei:
- Liegen Quellcode, Doku und alle Zugänge nachweislich bei uns?
- Wem gehört die Infrastruktur, wer hat Zugriff auf Konten und Schlüssel?
- Könnten wir kurzfristig ein Sicherheitsupdate ausliefern?
- Wo liegt Wissen nur in einzelnen Köpfen?
Ziemlich oft zeigt so ein Kassensturz, dass die Lage weniger dramatisch ist als befürchtet. Vieles ist da, es muss nur zusammengetragen werden. Außerdem verhandelst du aus einer ganz anderen Position, gegenüber dem alten Dienstleister wie gegenüber neuen Partnern.
Ein Punkt, der dabei leicht untergeht, liegt nicht beim alten Dienstleister, sondern bei dir im Haus. Als Verantwortlicher musst du klären, wer das Produkt künftig intern trägt. Wer übernimmt die fachlichen Anforderungen? Wie viel Kapazität haben deine eigenen Leute realistisch frei? Und welche Aufgaben gibst du bewusst an einen neuen Partner ab? Je klarer diese Rollen sind, desto souveräner steuerst du die Übergabe, statt sie nur zu durchlaufen.
Erst danach geht es an die Wahl des Nachfolgers. Fachliches Können solltest du bei seriösen Anbietern ohnehin voraussetzen dürfen. Wichtiger ist eine andere Fähigkeit: ein bestehendes, fremdes System sauber zu übernehmen. Ein guter Partner analysiert den vorhandenen Code und benennt offen, wo Altlasten liegen, statt reflexartig alles neu zu bauen. Er denkt dabei über die ganze Breite deines Produkts. Hardware, Firmware, Konnektivität, Cloud und App greifen ineinander, und wer nur eine Ebene beherrscht, löst dein Problem bestenfalls zur Hälfte. Genauso wichtig ist Transparenz: Von Anfang an sollte klar sein, wem Code, Rechte und Infrastruktur gehören, damit du nicht gleich wieder in die alte Abhängigkeit rutschst.
Fazit
Die Schließung eines Entwicklungspartners ist ein ernster Einschnitt, aber kein Grund zur Panik. Dein Produkt behält seinen Wert. Was jetzt zählt, ist Struktur: sichern, verstehen und das Wissen bewahren, solange es greifbar ist. Und dann wählst du in Ruhe den richtigen neuen Partner. So wird der Wechsel nicht zum Bruch, sondern zum Neuanfang auf besseren Fundamenten.
Code allein reicht nicht. Erst Infrastruktur, Zugänge und Betriebswissen zusammen machen dein Produkt wieder handlungsfähig.
Der IOX Abhängigkeits-Check
Du willst wissen, wie fest dein laufendes Projekt an einzelne Partner, Werkzeuge oder Bauteile gebunden ist? Genau dafür gibt es bei uns den Abhängigkeits-Check für laufende Entwicklungsprojekte. Wir gehen vier Punkte durch: Wo liegen Artefakte und Rechte, wie übergabefähig ist die Dokumentation, welche Werkzeuge und Bauteile binden dich fest, und wie lange dauert ein Wechsel realistisch. Am Ende steht eine Seite mit einer Ampel und den zwei Dingen, die du zuerst angehen solltest. Kostenfrei, weil wir wissen wollen, wie verbreitet das Problem wirklich ist.
IOX Whitepaper:
