Migration zwischen KI-Anbietern.

Ein Anbieterwechsel klingt in der Theorie nach einer überschaubaren Aufgabe: Vertrag kündigen, Daten exportieren, beim neuen Anbieter wieder importieren, fertig. Wer es einmal versucht hat, weiß: Die Realität sieht anders aus. Zwischen den Modellen unterschiedlicher Anbieter liegen feine, aber konsequenzenreiche Unterschiede — andere Tokenizer, andere Antwortstile, andere Verhaltensweisen bei Edge Cases. Prompts, die monatelang sauber funktioniert haben, liefern beim neuen Anbieter plötzlich schlechtere oder unbrauchbare Ergebnisse. Hinzu kommen Integrationen, die umgebaut werden müssen, Eval-Suiten, die nachgeschärft gehören, und ein Team, das umgeschult werden will. Aus dem ursprünglich geplanten Vier-Wochen-Wechsel werden schnell vier Monate. Was bei einer KI-Migration tatsächlich anfällt, wie man die Kosten realistisch einschätzt und welche Reihenfolge sich bewährt, ist Thema dieses Beitrags.

Warum KI-Migrationen schwieriger sind als klassische Software-Wechsel.

Bei klassischen Software-Wechseln gibt es etablierte Migrationswege: Daten exportieren, Konfigurationen übersetzen, Schnittstellen anpassen. Bei KI-Anbietern fehlt dieser stabile Boden. Drei Unterschiede sind dabei entscheidend.

Erstens: Modelle verhalten sich unterschiedlich, auch wenn sie funktional ähnlich wirken. Ein Prompt, der bei Anbieter A präzise, sachliche Antworten produziert, kann bei Anbieter B ausschweifender, kreativer oder zurückhaltender antworten. Diese Unterschiede sind selten dokumentiert und zeigen sich oft erst in der Praxis. Migration ist deshalb nicht nur ein Transport von Daten, sondern eine Neukalibrierung von Verhalten.

Zweitens: Die APIs unterscheiden sich in vielen Details. Parameter haben unterschiedliche Bedeutungen, Standardwerte sind anders gesetzt, Antwortformate variieren. Wer eine Anwendung auf Anbieter A gebaut hat, hat oft hunderte kleiner Anpassungen vorgenommen, die in der Migration mitwandern müssen. Selbst standardisierte Schnittstellenformate wie das OpenAI-Format werden von verschiedenen Anbietern leicht unterschiedlich interpretiert.

Drittens: Die organisatorische Verflechtung ist tiefer als bei klassischer Software. Mitarbeitende kennen die Eigenheiten eines Modells, Prompt-Bibliotheken sind oft mündliches Wissen, einzelne Workflows sind über Monate auf ein bestimmtes Antwortverhalten optimiert. Eine Migration heißt deshalb auch immer: Wissen umbauen, Routinen neu lernen, Erwartungen anpassen. Das ist kein technisches, sondern ein Veränderungsthema.

Die fünf Komponenten einer KI-Migration.

Wer eine Migration realistisch plant, muss sie in ihre Bestandteile zerlegen. Praktikabel hat sich eine Aufteilung in fünf Komponenten erwiesen, die unterschiedlich viel Aufwand verursachen und unterschiedlich gut planbar sind.

Wichtig ist die Reihenfolge der Aufwandsschätzung. In der Praxis wird der Datentransport regelmäßig überschätzt — er ist meist schneller erledigt als befürchtet. Unterschätzt werden Prompt-Anpassungen, Workflow-Umbauten und vor allem die Schulungsaufgabe. Wer nur Daten und APIs in seiner Migration plant, kalkuliert systematisch zu kurz.

Eine vernünftige Faustregel: Der reine technische Umbau ist meist 30 bis 40 Prozent des Gesamtaufwands. Der Rest verteilt sich auf Prompt-Engineering, Qualitätssicherung, Schulung und stille Anpassungen, die im laufenden Betrieb nötig werden. Wer mit der 40-Prozent-Zahl plant, ist näher an der Realität als mit der 80-Prozent-Zahl, die viele Migrationspläne suggerieren.

Daten und Vektor-Datenbanken: Was wirklich umzieht.

Beim Datentransport sind drei Kategorien zu unterscheiden: Rohdaten, abgeleitete Daten, Modellartefakte. Jede Kategorie hat ihre eigene Migrationslogik.

Rohdaten — die Quelltexte, Dokumente, Bilder, die in das KI-System gefüttert werden — sind meist problemlos zu migrieren, weil sie unabhängig vom Anbieter existieren. Hier ist vor allem die Vollständigkeit des Exports zu prüfen. Manche Anbieter exportieren standardmäßig nicht alle Metadaten; was im neuen System fehlt, ist später teuer nachzupflegen.

Abgeleitete Daten sind heikler. Embeddings (Vektor-Repräsentationen von Texten) sind nicht zwischen Anbietern austauschbar — jeder Anbieter erzeugt seine eigenen Embeddings mit eigenem Embedding-Modell. Wer eine RAG-Anwendung (Retrieval-Augmented Generation) migriert, muss alle Embeddings neu berechnen lassen. Das ist nicht aufwendig im Sinne von menschlicher Arbeit, aber kostspielig in API-Calls und braucht Zeit. Für große Vektor-Datenbanken können das Tage an Rechenzeit und vierstellige Eurobeträge sein.

Modellartefakte — fine-getunte Modelle, RLHF-Anpassungen, eigene Adapter — sind in der Regel nicht migrierbar. Sie sind an die zugrundeliegende Modellarchitektur gebunden. Wer ein eigenes Fine-Tuning bei Anbieter A hat, muss es bei Anbieter B neu durchführen, mit anderem Aufwand und potenziell anderem Ergebnis. Das ist einer der versteckten Kostenpunkte, die bei der ersten Schätzung gerne übersehen werden.

Prompt-Migration: Der oft unterschätzte Hebel.

Die Prompt-Migration ist meist der zeitaufwendigste Teil. Prompts, die für ein Modell optimiert wurden, funktionieren bei einem anderen Modell selten so gut wie erwartet. Manche Formulierungen sind direkt übertragbar, andere brauchen substanzielle Anpassungen. Wer die Migration unterschätzt, lässt sich oft von ersten Tests täuschen, in denen die Prompts „auch beim neuen Anbieter funktionieren“ — bis die Edge Cases auftauchen.

Typische Migrationsthemen bei Prompts:

• Systemprompt-Konventionen: Wo akzeptiert das neue Modell Verhaltensanweisungen, wie reagiert es auf Rollendefinitionen?
• Few-Shot-Beispiele: Müssen oft an die Antwortlogik des neuen Modells angepasst werden — Stil, Länge, Format.
• Sicherheits-Verhalten: Verschiedene Modelle reagieren unterschiedlich sensibel auf bestimmte Themen — was bei Anbieter A funktioniert, blockt Anbieter B.
• Strukturierte Ausgaben: JSON-Schema-Adhärenz, Tool-Calling, Function-Calls unterscheiden sich in Syntax und Zuverlässigkeit.
• Mehrsprachige Prompts: Deutsche Prompts können bei unterschiedlichen Modellen sehr unterschiedlich performen — selbst bei Modellen, die offiziell mehrsprachig sind.

Pragmatisch heißt das: Für jeden produktiven Prompt sollte es eine Test-Liste geben, mit der die Funktionsfähigkeit nach der Migration überprüft wird. Wer ohne solche Tests umsteigt, entdeckt Probleme erst beim produktiven Einsatz — meistens dann, wenn ein verärgerter Fachbereich anruft.

Workflows, Integrationen und API-Adapter.

Wer eine KI-Anwendung mit sauberer Architektur gebaut hat, hat den Anbieter-Code hinter einer Abstraktionsschicht versteckt. In dem Fall ist der Workflow-Umbau überschaubar — die Schicht wird ausgetauscht, die Geschäftslogik darüber bleibt unverändert. Wer den Anbieter-Code direkt überall in der Anwendung verstreut hat, hat einen wesentlich größeren Refactoring-Aufwand.

In der Praxis ist die Realität meist gemischt. Manche Workflows sind sauber gekapselt, andere haben Anbieter-Spezifika tief im Code. Eine ehrliche Bestandsaufnahme zu Beginn der Migration spart später viel Zeit. Drei Fragen helfen: Welche Stellen im Code rufen den Anbieter direkt auf? Welche Parameter-Sets sind anbieterspezifisch (und wie werden sie übersetzt)? Welche Antwortformate werden in Folgelogik weiterverarbeitet (und wie unterscheiden sich diese beim neuen Anbieter)?

Heikel sind die scheinbar harmlosen Stellen. Standardwerte für Temperature oder Top-P können beim neuen Anbieter andere Bedeutungen haben. Streaming-Verhalten unterscheidet sich. Fehlercodes sind anders strukturiert. Retry-Logiken müssen oft angepasst werden, weil die Rate-Limits sich anders verhalten. Diese Details summieren sich.

Ein in der Praxis bewährter Ansatz: vor der Migration einmal alle Aufrufstellen kartieren, eine Adapter-Schicht einziehen (falls noch nicht vorhanden) und dann erst migrieren. Das verlängert den Migrationsprozess vorne, beschleunigt ihn hinten und macht zukünftige Wechsel deutlich günstiger. Wer auf Adapter verzichtet, zahlt bei jeder Migration den vollen Preis. Mehr dazu, wie man Anbieter-Abhängigkeiten von vornherein reduziert, im Beitrag über Vendor-Lock-in vermeiden.

Eval-Suiten: Die Versicherung gegen Qualitätsabfall.

Eine Eval-Suite ist eine Sammlung von Testfällen, mit denen die Qualität eines KI-Outputs systematisch überprüft wird. Sie ist im Regelbetrieb nützlich, in der Migration unverzichtbar. Ohne Eval-Suite ist jede Aussage über die Vergleichbarkeit zweier Anbieter Bauchgefühl — und Bauchgefühl reicht für eine produktive Entscheidung selten.

Was eine gute Eval-Suite enthält: typische Anfragen, schwierige Edge Cases, Beispiele aus echten Geschäftsfällen, definierte erwartete Outputs (oder Bewertungskriterien, falls deterministische Outputs nicht möglich sind). Für die Migration wird die Suite gegen das bisherige Modell und das neue Modell laufen gelassen, und die Ergebnisse werden verglichen. Klingt einfach — ist aber ein nicht trivialer Aufwand, vor allem bei generativen Anwendungen, wo die Bewertung der Outputs subjektiv ist.

Drei Praxistipps für die Eval-Suite in einer Migration: Erstens, die Suite vor der Migration konsolidieren — viele Unternehmen haben verstreutes Testwissen, das in der Migration zusammengeführt werden muss. Zweitens, eine quantitative und eine qualitative Schicht haben: Quantitativ über automatisierte Vergleiche, qualitativ über stichprobenartige menschliche Bewertung. Drittens, die Suite während der Migration aktiv weiterentwickeln — jede entdeckte Schwäche des neuen Anbieters wird zum Testfall für künftige Migrationen.

Was man von einer Eval-Suite nicht erwarten darf: dass sie alle realweltlichen Probleme abdeckt. Modelle haben ein langes Tail an Edge Cases, die kein Testset vollständig erfasst. Eine Eval-Suite erhöht die Wahrscheinlichkeit, Probleme früh zu finden — sie eliminiert sie nicht. Wer das im Blick hat, geht mit der Suite umsichtig um.

Realistische Migrationskosten und Zeitrahmen.

Was kostet eine KI-Migration tatsächlich? Die ehrliche Antwort lautet: deutlich mehr als die meisten Erstschätzungen. Für ein mittelständisches Unternehmen mit zwei bis fünf produktiven KI-Anwendungen liegen realistische Werte oft bei zwei bis sechs Monaten Projektlaufzeit und 30.000 bis 150.000 Euro an direkten Kosten — abhängig von Komplexität, Eigenleistung und externer Unterstützung.

Die Kostenstruktur verteilt sich typischerweise auf vier Bereiche: technischer Umbau (ca. 30–40 Prozent), Prompt-Migration und Eval (ca. 25–35 Prozent), Schulung und Change Management (ca. 15–25 Prozent), Phase-out und Parallelbetrieb (ca. 10–15 Prozent). Der letzte Punkt wird oft vergessen: In einer professionellen Migration läuft das alte System eine Zeit parallel zum neuen, mit doppelten Lizenzkosten. Diese Parallelphase ist nötig, um Probleme zu erkennen und zurückrollen zu können — aber sie kostet.

Zur Zeitschätzung: Eine ehrliche Migration eines komplexen Workflows (z. B. KI-gestützte Dokumentenverarbeitung mit RAG, mehreren Prompts, Fachintegration) braucht selten weniger als zehn Wochen. Wer in vier Wochen migriert, hat entweder einen sehr einfachen Anwendungsfall oder erhebliche Risiken nicht adressiert. Beides ist möglich — der Unterschied sollte aber bewusst sein.

Eine vernünftige Pufferregel: Auf die ehrliche Erstschätzung zwanzig bis dreißig Prozent Reserve aufschlagen. Migrationen entdecken regelmäßig Aspekte, die in der Planung nicht sichtbar waren — eine alte Integration, ein vergessener Workflow, ein Edge Case, der nirgends dokumentiert war. Wer ohne Puffer plant, hat ohne Puffer Stress.

Wie Sie eine Migration sauber durchführen.

Eine geordnete Migration folgt einer Reihenfolge, die das Risiko begrenzt. Bewährt hat sich ein fünfphasiger Ablauf: Inventur, Vorbereitung, Pilot-Migration, Vollmigration, Phase-out.

In der Inventur wird der Ist-Zustand erfasst: Welche Anwendungen nutzen welche Modelle, welche Daten, welche Integrationen, welche Prompt-Bibliotheken? Diese Phase dauert zwei bis vier Wochen und ist die wertvollste — sie verhindert, dass später vergessene Komponenten auffallen.

In der Vorbereitung wird die Eval-Suite aufgebaut beziehungsweise konsolidiert, die Adapter-Schicht eingezogen (falls nötig), Testumgebungen geschaffen und das Migrationsteam aufgesetzt. Auch hier sind zwei bis vier Wochen realistisch.

Die Pilot-Migration beginnt mit dem unkritischsten Anwendungsfall. Ein bis zwei Workflows werden vollständig migriert, durch die Eval-Suite geschickt und mit echten Nutzern getestet. Hier lernt das Team die Eigenheiten des neuen Anbieters und justiert die Migrationsverfahren. Diese Phase dauert oft länger, als geplant — und das ist gut so, weil hier die teuren Lehrgelder bezahlt werden, nicht in der Vollmigration.

Die Vollmigration rollt die geprüften Verfahren auf die restlichen Anwendungen aus. Hier ist Tempo möglich, weil die methodischen Fragen geklärt sind. Im Phase-out wird der alte Anbieter geordnet abgeschaltet: Restdaten exportiert, Verträge gekündigt, Konten geschlossen, Mitarbeitende auf das neue System eingenordet. Erst danach ist die Migration wirklich abgeschlossen — vorher ist sie nur fast fertig, was ein anderer Zustand ist.

Sie planen einen Wechsel des KI-Anbieters und wollen die Migration realistisch aufsetzen? Unverbindlich anfragen — wir schauen gemeinsam auf Bestand, Aufwand und Risiken — und entwickeln einen Plan, der zur Komplexität Ihrer Anwendungen passt.