Ihr Agent läuft. Leads werden qualifiziert, Tickets triagiert, Rechnungen fliessen durch. Der No-Code-Builder oder der n8n-Workflow, den Sie vor drei Monaten aufgesetzt haben, hat das Konzept bewiesen — und zeigt jetzt erste Risse.
Die Antwortzeiten sind gestiegen. Ein Drittanbieter-API-Update hat letzten Dienstag zwei Flows kaputt gemacht, und Ihr Team hat einen halben Tag damit verbracht, Node-Konfigurationen manuell zu reparieren. Die Rate Limits der Plattform sind während der Stosszeiten inzwischen ein echter Engpass, und das nächste Feature, das Sie brauchen — Abfragen aus einer proprietären internen Datenbank, mehrere Entscheidungsschritte mit Memory verknüpfen — liegt knapp ausserhalb dessen, was die Builder-UI sauber ausdrücken kann.
Das ist der Migrationszeitpunkt. Ob und wie Sie von Ihrer No-Code-KI-Agenten-Plattform zu einer Custom-Architektur migrieren, ist eine weitreichende Entscheidung. Gut gemacht, bewahrt sie alles, was Sie bewiesen haben, und fügt alles hinzu, was Sie brauchen. Schlecht gemacht, wird daraus ein Rewrite, der doppelt so lange dauert und Monate an Iterationswissen vernichtet.
Die Signale, die eine Migration rechtfertigen (und nicht nur verlockend machen)
Mehr Kontrolle zu wollen, ist kein ausreichender Grund zum Neubauen. Custom Code hat reale Kosten: längere initiale Entwicklung, mehr Infrastruktur-Ownership und keinen Vendor, den man anrufen kann, wenn etwas kaputt geht. Prüfen Sie daher, ob Sie wirklich an strukturelle Grenzen stossen — oder ob die Plattform noch Spielraum hat.
Strukturelle Auslöser, die ernst genommen werden sollten:
- Integrationstiefe. Ihr Workflow muss auf interne Systeme (ERP, proprietäre Datenbanken, Legacy-APIs) zugreifen, bei denen die Plattform sich nicht sauber authentifizieren kann oder bei denen Sie mit fragilen Zwischenschritten um Einschränkungen herumarbeiten.
- Volumen und Zuverlässigkeit. Der Agent verarbeitet genug Transaktionen, dass Plattform-Rate-Limits oder Shared-Infrastructure-SLAs die Performance spürbar beeinträchtigen. Wenn ein Queue-Rückstau an einem geschäftigen Montagmorgen echten Umsatzverlust verursacht, ist das strukturell, nicht zufällig.
- Logik-Komplexität. Der benötigte Workflow erfordert verzweigte Conditional Logic, Multi-Step-Reasoning mit gemeinsam genutztem State oder Memory über Sessions hinweg — und das lässt sich in der Plattform nicht sauber abbilden oder erfordert Workarounds, die künftige Maintainer nicht verstehen werden. Reine No-Code-Builder (Zapier und einfachere Tools) haben die engsten Grenzen; Low-Code-Plattformen wie n8n haben natives Memory und Stateful Orchestration ergänzt, aber auch dort stösst komplexe Multi-Agent-Logik oft an das, was der visuelle Editor klar ausdrücken kann.
- Datenhaltung oder Compliance. Ihre rechtlichen oder datenschutzrechtlichen Anforderungen (revDSG, DSGVO) schränken grenzüberschreitende Datentransfers auf eine Weise ein, die bestimmte Cloud-Plattformen nicht-konform machen kann — oder die in der Praxis verlangen, dass Daten in einer bestimmten Jurisdiktion verbleiben. Branchenspezifische Regeln wie FINMA-Rundschreiben oder Gesundheitsvorschriften können auf diesen Grundgesetzen noch strengere Lokalisierungsanforderungen auferlegen.
- Kosten bei Skalierung. Plattform-Preise, die bei 500 monatlichen Agent-Runs funktioniert haben, sehen bei 50.000 anders aus. Wenn die Kosten pro Task schneller wachsen als der generierte Wert, hat sich die TCO-Rechnung verschoben.
Keines dieser Signale ist für sich genommen eine Krise. Wenn zwei oder drei gleichzeitig auftreten, lohnt es sich, zu handeln.
Für einen umfassenderen Blick auf das, was das Build-vs-Buy-Kalkül grundsätzlich antreibt, behandelt das Build vs Buy Framework für KI-Agenten die initiale Entscheidung ausführlich. Dieser Artikel setzt an dem Punkt an, an dem diese Entscheidung in Richtung Custom kippt.
Was Erhalten Bleibt, Was Neu Gebaut Wird
Der Instinkt bei einer Migration ist, von vorne anzufangen — saubere Codebase, ordentliche Architektur, keine unordentlichen Workarounds. Widerstehen Sie diesem Impuls. Ihr bestehendes Prototyp enthält etwas Wertvolles: ein validiertes Modell des echten Workflows, inklusive aller Edge Cases, die die Realität ans Tageslicht gebracht hat.
Was Sie mitnehmen sollten:
- Die Business Logic — die Conditional Rules, Eskalationsschwellen und Routing-Entscheidungen, die Ihr Team durch Iteration verfeinert hat. Dokumentieren Sie jeden nicht offensichtlichen Branch, bevor Sie den Code anfassen.
- Den Prompt-Layer — wenn Sie System Prompts und Few-Shot-Beispiele für Ihre spezifische Domäne optimiert haben, sind das hart erarbeitete Ergebnisse. Migrieren Sie diese sorgfältig und testen Sie Outputs gegen Ihre Baseline, bevor Sie eine Version als final betrachten.
- Die Fehler-Taxonomie — jedes Mal, wenn der Prototyp falsch reagiert hat und jemand das bemerkte, haben Sie etwas gelernt. Ihre QA-Checkliste für den Custom Build sollte direkt aus diesen Vorfällen entstehen.
Was typischerweise neu gebaut werden muss:
- Authentifizierung und Secrets Management — No-Code-Plattformen — insbesondere Self-Hosted-Konfigurationen — speichern Credentials oft auf eine Weise, die Ihren spezifischen Produktionssicherheitsstandards möglicherweise nicht entspricht. Bauen Sie dies von Anfang an gegen den Secret Store Ihrer Infrastruktur auf.
- Fehlerbehandlung und Retries — Plattform-Builder abstrahieren Ausfallmodi weg. Custom Code zwingt Sie dazu, explizit festzulegen, was passiert, wenn ein API-Aufruf ein Timeout hat, ein Modell eine fehlerhafte Antwort zurückgibt oder eine Queue sich aufstaut. Diese Explizitheit ist ein Vorteil, sobald Sie sie haben.
- Observability — Sie haben vom Prototyp wahrscheinlich minimales Logging. Custom Code bedeutet, dass Sie genau das instrumentieren können, was zählt: Latenz pro Step, Token-Verbrauch pro Run, Fehlerraten nach Kategorie. Hier investieren Migrationsteams am häufigsten zu wenig — und es ist das, was sie am meisten bereuen.
Eine Staged Migration, die den Produktionsbetrieb Nicht Unterbricht
Die risikoreichste Migrationsstrategie ist die, bei der Sie alles offline nehmen, zwei Monate parallel neu aufbauen und dann einen einzigen Cutover durchführen. Vermeiden Sie das. Ein stufenweiser Ansatz braucht mehr Planungszeit, liefert aber fast immer schneller und mit geringerem Risiko.
Eine Migrationssequenz, die funktioniert:
-
Den Prototyp einfrieren. Hören Sie auf, der Plattform-Version neue Features hinzuzufügen. Sie ist jetzt eine Referenzimplementierung, kein Produkt mehr. Das ist leichter gesagt als getan — Stakeholder werden weiterhin Verbesserungen anfordern — aber Scope Creep an einem System, das Sie ersetzen, multipliziert die Migrationskosten.
-
Die kanonische Logik extrahieren und dokumentieren. Bevor Sie eine Zeile Custom Code schreiben, verfassen Sie eine Spezifikation dessen, was der Agent leisten soll: Inputs, Entscheidungszweige, Outputs, Fehlerbedingungen. Behandeln Sie das als Source of Truth, auf die sich beide Versionen einigen sollten.
-
Zuerst die Core-Infrastruktur aufbauen, dann die Logik. Richten Sie die Custom-Umgebung ein — Hosting, CI/CD, Logging, Secrets — bevor Sie eine Workflow-Logik portieren. Logik auf wackelige Infrastruktur zu migrieren, produziert subtile Bugs, die schwer zu verfolgen sind.
-
Die Custom-Version im Shadow-Betrieb laufen lassen. Leiten Sie echten Produktions-Traffic gleichzeitig auf beide Systeme, wobei die Plattform-Version die tatsächlichen Antworten liefert und die Custom-Version still mitläuft. Vergleichen Sie die Outputs. Wenn die Übereinstimmungsraten hoch sind und die Fehlerrate Ihrer Custom-Version akzeptabel ist, sind Sie bereit für den Switch.
-
Schrittweise Traffic-Verschiebung. Beginnen Sie damit, 5–10 % des Traffics an die Custom-Version zu senden, während die Plattform den Rest übernimmt. Beobachten Sie mindestens einen vollständigen Geschäftszyklus auf Regressionen in Ihren Kernmetriken, bevor Sie den Anteil erhöhen. Ein Fehleranstieg um 2 Uhr nachts an einem Mittwoch zeigt sich möglicherweise erst nach einer Woche im Live-Betrieb.
-
Bewusst ausser Betrieb nehmen. Halten Sie die Plattform-Version 30 Tage nach dem vollständigen Cutover im Read-Only- oder Standby-Modus. Das ist günstige Absicherung gegen Edge Cases, die nur in seltenen Szenarien auftreten.
Der Operative Wandel, den Niemand Einplant
Wenn Sie von einer No-Code-KI-Agenten-Plattform zu Custom Code migrieren, wechseln Sie nicht nur die Technologie — Sie wechseln, wer die operative Verantwortung trägt.
Auf einer Plattform kümmert sich der Vendor um Infrastrukturzuverlässigkeit, Versions-Upgrades für die zugrundeliegenden LLM-Connectors und den grössten Teil des Security Patchings. Bei Custom Code liegt all das bei Ihrem Team oder Ihrem Entwicklungspartner.
Das ist handhabbar, muss aber explizit gemacht werden. Beantworten Sie vor der Migration:
- Wer überwacht den Agenten in der Produktion? Was sind die Alerting-Schwellwerte?
- Was ist der Incident-Response-Prozess, wenn der Agent im grossen Massstab falsch reagiert?
- Wer pflegt die Beziehung zum Modellanbieter, und wie wird eine Model-API-Änderung absorbiert?
Teams, die diese Gespräche überspringen, entdecken die Antworten oft zum denkbar schlechtesten Zeitpunkt — während eines Produktionsvorfalls an einem Freitagnachmittag.
Der Artikel KI-Agenten in der Produktion verwalten behandelt das operative Playbook ausführlich. Es lohnt sich, ihn zu lesen, bevor Sie Ihren Migrationsplan abschliessen — nicht danach.
Wie Lange Dauert Das Wirklich?
Das hängt von der Agent-Komplexität und der Qualität der Prototyp-Dokumentation ab. Für einen Single-Agent-Workflow mittlerer Komplexität — etwa ein Lead-Qualification-Agent, der gegen ein CRM läuft — dauert eine Staged Migration typischerweise vier bis acht Wochen, Shadow-Betrieb und Traffic-Verschiebung eingeschlossen.
Dieser Zeitplan verlängert sich, wenn der Prototyp nicht dokumentierte Edge Cases hat, wenn Custom Integrationen das Aushandeln von API-Zugriffen mit internen Systemverantwortlichen erfordern oder wenn die Compliance-Prüfung für die neue Hosting-Umgebung länger als erwartet dauert.
Die Shadow-Run-Phase zu überspringen, um den Zeitplan zu komprimieren, ist ein häufiger Fehler. Zwei Wochen Parallelbetrieb sind günstig im Vergleich zu einem Produktionsvorfall, den niemand im Testing entdeckt hat.
Plattform-Lock-In Während der Migration
Das Migrationsfenster ist der Zeitpunkt, an dem Sie am stärksten dem Plattform-Lock-in ausgesetzt sind. Sie sind auf die Plattform für den Produktions-Traffic angewiesen, während die Custom-Version aufgebaut wird. Wenn der Vendor in diesem Zeitfenster die Preise ändert, den API-Zugang einschränkt oder einen Ausfall hat, sind Ihre Optionen begrenzt.
Kartieren Sie genau, wovon Sie in der Plattform abhängen — und welche Abhängigkeiten leicht zu replizieren sind im Vergleich zu schwierigen — bevor Sie beginnen. Der Artikel KI-Agenten Plattform Lock-In bildet die spezifischen Risikokategorien detailliert ab.
Wann Migration die Falsche Antwort Ist
Migration ist nicht immer die richtige Entscheidung, selbst wenn Sie auf Reibungspunkte stossen. Zwei Szenarien, in denen es sinnvoller ist, bei der Plattform zu bleiben (oder zu einer anderen zu wechseln) als zu Custom Code zu gehen:
Der Workflow ist wirklich einfach. Wenn Ihr Agent eine Sache zuverlässig erledigt und die Plattform das ohne nennenswerte Einschränkungen schafft, ist der operative Overhead von Custom Code nicht gerechtfertigt. Plattformen verdienen ihre Kosten bei niedriger bis mittlerer Komplexität.
Der Business Case hat sich noch nicht stabilisiert. Wenn sich der Workflow noch jeden Monat erheblich ändert — andere Inputs, andere Entscheidungslogik, andere Outputs — sind die Kosten für die Pflege einer Custom Codebase bei sich ändernden Anforderungen hoch. Beweisen Sie erst Stabilität auf der Plattform. Der Artikel Wenn No-Code-KI-Agenten-Builder an ihre Grenzen stossen bietet ein nützliches Framework, um zu unterscheiden, ob Sie tatsächlich an der Decke angekommen sind oder ob Sie noch nicht den richtigen Workflow gebaut haben.
Migration mit Partner oder Im Haus
Eine Migration dieser Art ist In-House machbar, wenn Sie Ingenieure mit Produktionserfahrung in AI/ML und entsprechender Bandbreite haben. Die meisten KMU haben beides nicht gleichzeitig.
Mit einem Entwicklungspartner zu arbeiten, hat in der Migrationsphase einen spezifischen Vorteil: Ein Team, das bereits Agenten von Plattformen zu Custom Code migriert hat, ist den meisten Fehlermodi bereits begegnet — und hat die Templates, Testing-Tooling und operativen Runbooks bereits aufgebaut. Dieses institutionelle Wissen komprimiert eine 12-wöchige Migration auf 6 Wochen.
Bei Orange ITS haben wir die Custom-KI-Agenten-Entwicklung genau um diese Art von Migrationsengagement herum strukturiert: ausgehend von Ihrem bestehenden Prototyp, extrahieren wir, was funktioniert, bauen neu, was nicht funktioniert, und übergeben ein Produktionssystem mit vollständiger Observability und einem operativen Handover, das Ihr Team eigenständig betreiben kann.
Bereit, Ihre Migration zu Planen?
Wenn Ihre Agent-Plattform die oben beschriebenen Risse zeigt — und Sie eine nüchterne Einschätzung wünschen, was eine Migration für Ihr spezifisches Setup bedeuten würde — ist ein 30-minütiges Gespräch mit unserem Team der richtige Einstieg.
Wir schauen uns Ihren aktuellen Workflow an, identifizieren die strukturellen Auslöser, die in Ihrem Kontext am meisten zählen, und geben Ihnen eine ehrliche Einschätzung, ob Migration jetzt, später oder gar nicht sinnvoll ist.
Vereinbaren Sie jetzt ein Gespräch mit Orange ITS — keine Slides, kein Sales-Pitch, nur ein technisches Gespräch über Ihr konkretes System.