Self-Service-iPaaS verkauft Produktivität in der Build-Phase. Ihr Team bekommt eine Plattform, eine Connector-Bibliothek und die Möglichkeit, Integrationen schneller zu bauen als von Hand. Dieser Teil funktioniert. Die Lizenz sagt nichts darüber, wer diese Integrationen danach überwacht, wer sie repariert, wenn sich ein Endpunkt ändert, und wer sich gegenüber dem Business verantwortet, wenn eine ausgefallene Integration einen davon abhängigen Prozess stoppt.
Der Wechsel zu einem Managed Service überträgt diese Betriebslast an einen Anbieter unter einer Servicezusage, und der Service bringt seine eigene Integrationsinfrastruktur mit. Das Ziel ist eine Landschaft, die Sie nicht mehr lizenzieren, administrieren oder besetzen, und genau daher kommt die Senkung der Gesamtbetriebskosten. Ihre bestehende Plattform läuft weiter, während die Flows hinüberwandern, sodass der Wechsel in Wellen erfolgt. Dieser Artikel behandelt, warum Teams den Wechsel vollziehen, welche Phasen er durchläuft, wer danach wofür verantwortlich ist und wie lange er dauert.
Kernaussagen
- Self-Service-iPaaS gibt Ihrem Team einen besseren Ort für Integrationsarbeit. Die Arbeit und die Verantwortung dafür bleiben bei Ihrem Team.
- Die eigene Forschung der Plattformanbieter zeigt die Lücke: Unternehmen betreiben inzwischen 957 Anwendungen, davon 27 % angebunden, während die IT 36 % ihrer Zeit mit dem Bau individueller Integrationen verbringt. Leistungsfähiges Tooling hat sie nicht geschlossen.
- Der Übergang verlagert Verantwortung Integration für Integration, in Wellen. Für eine gewisse Zeit sind beide Parteien für dieselbe Arbeit besetzt, und diese Überlappung gehört in den Business Case.
- Die Ersparnis ist eine Ersparnis bei den Gesamtbetriebskosten und sie kommt zur Verlängerung. Sobald die Flows auf der Infrastruktur des Anbieters laufen, verlassen Plattformlizenz, Administration und interne Betriebskosten den Run Rate, sodass der Übergang rückwärts von Ihrem Verlängerungstermin geplant werden sollte.
Das Betriebsmodell hinter Managed Integration Services beschreibt das Integration Ops Buch ausführlich: Lifecycle-Phasen, Ownership-Muster und Playbook-Beispiele. Kostenlos herunterladen.
Warum Teams sich von Self-Service-iPaaS abwenden
Das iPaaS-Versprechen ist ein Build-Phase-Versprechen, und auf seinen eigenen Bedingungen stimmt es. Connectoren, ein visueller Mapper, wiederverwendbare Muster, Governance-Tooling. Ein Team, das bisher Punkt-zu-Punkt-Verbindungen von Hand codiert hat, baut auf einer Plattform schneller als ohne.
Was das Versprechen auslässt, ist alles nach dem Build. Aus einer gebauten Integration eine funktionierende zu machen, über die Jahre, in denen sie weiter funktionieren muss, bleibt bei demjenigen, dem das Plattformkonto gehört: das Monitoring, die Reparaturen, die Änderungen und die Verantwortung, wenn ein Ausfall das Business stört.
Die Belege liegen in der eigenen Forschung der Plattformanbieter
MuleSoft befragt jährlich IT-Verantwortliche. Der Connectivity Benchmark 2026, basierend auf 1.050 IT-Verantwortlichen, berichtet, dass das durchschnittliche Unternehmen 957 Anwendungen verwaltet, davon 27 % angebunden, und dass IT-Teams 36 % ihrer Zeit mit Design, Bau und Test individueller Integrationen verbringen. Die Ausgabe 2025 meldete 897 Anwendungen, 29 % angebunden und 39 % der Zeit.
Die Landschaft wuchs, der angebundene Anteil sank, und der Zeitaufwand bewegte sich kaum. Zwei Jahrzehnte immer leistungsfähigerer Plattformen haben eine Umgebung hervorgebracht, in der rund drei Viertel der Anwendungen unverbunden bleiben und Integration weiterhin mehr als ein Drittel der IT-Zeit verbraucht. Die Einschränkung, die diese Zahlen beschreiben, ist Betriebskapazität. Die Produkte sind gut, und die Stunden, um zu betreiben, was sie bauen, sind nicht da.
Das Ausfallmuster ist konsistent
Vier Dinge passieren, nachdem eine Self-Service-Plattform eingeführt wurde, und sie passieren ungefähr in dieser Reihenfolge.
Der Backlog bewegt sich nicht. Die Plattform kommt, zwei oder drei Personen werden geschult, und dasselbe Team, das bereits am Limit war, besitzt jetzt ein neues Tool zusätzlich zur Arbeit. Schneller bauen hilft nur, wenn jemand Zeit zum Bauen hat.
Ein Engineer wird zur Integrationsabteilung. Plattformwissen konzentriert sich bei dem, der sie am meisten genutzt hat. Diese Person wird zum Eskalationspfad für jeden Flow, und die Dokumentation lebt in ihrem Kopf. Das ist der mit Abstand häufigste Befund in einem Übergangsinventar.
Die Kosten kommen nach der Lizenz. Der Build ist die sichtbare Zahl. Betrieb, Incident Response und Änderung fallen jährlich an, über die Lebensdauer jeder Verbindung, und sie landen in der Gehaltsabrechnung, wo die Plattformrechnung sie nie zeigt. Unsere Aufschlüsselung der wahren Kosten von Unternehmensintegrationen stellt den vollständigen Stack dar, und verbrauchsbasierte Tarife fügen ein zweites Problem hinzu, weil die Rechnung proportional dazu wächst, wie gut die Integrationen funktionieren.
Niemand steht vertraglich in der Pflicht, wenn eine Integration ausfällt. Ein Plattform-Service-Level deckt die Plattformverfügbarkeit ab. Eine Integration, die ausfällt, weil ein Partner ein Feld geändert hat, weil ein Zertifikat abgelaufen ist oder weil ein Kunde seinen Service Desk migriert hat, müssen Sie selbst reparieren. Und während Ihr Team Brände löscht, bleibt die Störung nicht in der IT: Der Prozess, den die Integration trägt, ist gestoppt, Bestellungen oder Tickets stauen sich, Kunden spüren die Verzögerung, und jede folgende SLA-Strafe oder jedes Verlängerungsrisiko liegt bei Ihnen.
Dieser letzte Punkt entscheidet die meisten Evaluierungen: wer es betreibt, wer es repariert, wenn es bricht, und wer für das Ergebnis verantwortlich ist, nicht nur für die Plattformverfügbarkeit.
Self-Service beschreibt, wer die Plattform betreibt
Diese Unterscheidung macht den Wechsel praktikabel. „Self-Service" beschreibt, wer die Plattform betreibt, und das ist eine von der Frage, welche Plattform Sie besitzen, trennbare Frage. Ein Managed Service übernimmt die Betriebshälfte und lässt die Technologie an Ort und Stelle. Das wird manchmal Managed iPaaS genannt, also die Ergebnisse, die die Plattform verspricht, geliefert als betriebener Service mit einer Zusage. Unser Erklärartikel zu Managed iPaaS behandelt das Modell, und unsere Antwortseite zu Managed Integration Services gegenüber DIY-Integrationsplattformen zieht den Vergleich direkt.
Self-Service bleibt für manche Landschaften die richtige Antwort, und die Bedingungen dafür stehen am Ende dieses Artikels. Wo es aufhört zu funktionieren, ist dort, wo die Landschaft groß ist, die Änderungsrate kontinuierlich, externe Parteien beteiligt sind und das interne Team bereits der Engpass ist.
Was der Wechsel zu einem Managed Service tatsächlich umfasst
Er umfasst die Übertragung der Verantwortung für Monitoring, Incident Response, Änderung und Service-Level-Zusage für eine definierte Menge von Integrationen an einen Anbieter, während der Kunde die Ownership für die Geschäftslogik, die Endpunktsysteme und die Entscheidungen darüber behält, was die Integrationen tun sollen. Der Service umfasst die Integrationsinfrastruktur, sodass der Endzustand eine Landschaft ist, in der der Kunde keine eigene Plattform mehr betreibt.
Diese Definition schließt die Annahme aus, die die meisten Evaluierungen entgleisen lässt, nämlich dass irgendetwas davon als einmalige Umschaltung passieren muss. Verantwortung wandert vor der Infrastruktur, Integrationen ziehen in Wellen um, und die bestehende Plattform bleibt darunter live, bis die Flows, die von ihr abhängen, verschwunden sind.
Wenn Sie noch ein Bereitstellungsmodell wählen, behandelt unser Vergleich von Systemintegratoren, iPaaS-Beratern und Managed Integration Services diese Frage, und unsere Analyse dazu, wann das Projektmodell bei Integrationsarbeit versagt, behandelt den Fall für einen Modellwechsel überhaupt.
Warum das kein Replatforming-Projekt ist
An dieser Stelle werden zwei Dinge verwechselt, und die Verwechslung hält Organisationen auf einer Plattform, der sie bereits entwachsen sind. Selbst zu replatformen bedeutet, Integrationslogik von einer Plattform, die Ihr Team betreibt, auf eine andere Plattform zu verlagern, die Ihr Team betreibt. Eine iPaaS-Lösung, die Migrationstooling verkauft, beschreibt eine realistische Migration von mehreren hundert Workflows als Projekt von sechs bis zwölf Monaten, weil angesammelte Feld-Mappings, Fehlerbehandlung, Retry-Logik und bedingtes Routing in proprietären Formaten liegen, dokumentiert über interne Wikis und institutionelles Gedächtnis. Diese Schätzung ist glaubwürdig, und sie ist der Hauptgrund, warum Teams bleiben, wo sie sind.
Der Wechsel zu einem Managed Service ist eine andere Übung, weil Ihr Team nicht dasjenige ist, das neu baut. Der Anbieter bringt die Integrationsinfrastruktur mit und nimmt die Flows in Wellen hinüber, nach einem Zeitplan, der von Kritikalität und Ihrem Lizenzverlängerungstermin bestimmt wird, während alles noch nicht Verschobene dort weiterläuft, wo es ist. Die Arbeit, die Replatforming zu einem Projekt über mehrere Quartale macht, muss weiterhin geschehen. Sie geschieht auf der Seite des Anbieters, unter einer Servicezusage, eingepreist in ein Abonnement, das Ihre Engineering-Kapazität nicht mehr finanzieren muss.
Dieser Unterschied erklärt auch die Reihenfolge der Phasen unten. Verantwortung wandert zuerst, weil sie innerhalb von Wochen Wert erzeugt. Infrastruktur folgt, weil sie Kosten herausnimmt.
Die sechs Phasen eines Integrationsbetriebsübergangs
Das Modell unten ist kompatibel mit den SIAM-Roadmap-Stufen Discovery and Strategy, Plan and Build, Implement sowie Run and Improve, und mit der Leiter aus Wissenstransfer, Shadowing und Reverse-Shadowing, die ISG für Managed-Services-Übergänge allgemein dokumentiert. Die Phasennamen sind bewusst schlichte Verben, weil jede einen Wechsel darin beschreibt, wer verantwortlich ist.
Zwei Merkmale dieses Modells laufen kommerziellen Interessen zuwider, und beide sind Absicht. Phase 0 kommt zuerst, vor jeder Onboarding-Arbeit. Und Phase 3 ist von Phase 4 getrennt, sodass Verantwortung nach eigenem Zeitplan wandert und der Leser genau sehen kann, welche Phase Zuverlässigkeit liefert und welche die Kostensenkung.
Wer macht was nach dem Übergang
Die klarste Analogie ist das Shared-Responsibility-Modell aus der Cloud, bei dem der Anbieter für die Infrastruktur verantwortlich ist und der Kunde für das, was er darauf betreibt. Die entsprechende Rahmung für Integration ist Verantwortung für die Integrationsebene gegenüber Verantwortung in ihr.
Nach der üblichen RACI-Konvention, bei der R die Partei ist, die die Arbeit erledigt, und C konsultiert wird:
Der Kunde behält die Geschäftsebene:
Der Anbieter übernimmt die Betriebsebene:
Die umstrittene Ebene, auf der Verträge schiefgehen:
Diese letzte Zeile verdient Betonung. Shared-Responsibility-Modelle in der Cloud tragen denselben Vorbehalt: Die Verantwortung wandert überall dorthin zurück, wo der Kunde selbst provisioniert. Wenn Ihre Entwickler nach dem Übergang weiter Flows direkt auf der Plattform bauen, liegt die Verantwortung für diese Flows bei Ihnen, und das Service Level deckt sie nicht ab. Jeder Anbieter, der das nicht vorab sagt, bereitet einen Streit vor.
Was mit Ihrem Team passiert
Meist weniger, als befürchtet wird, und die rechtliche Lage hängt davon ab, wie dediziert die Mitarbeiter sind. Nach den Betriebsübergangsregeln in Großbritannien und der EU gilt der Schutz für Mitarbeiter, die eindeutig als Erbringer des übertragenen Service identifiziert werden können. In den meisten Unternehmen ist Integrationsarbeit ein Bruchteil der Aufgaben mehrerer Personen und niemandes ganze Rolle, sodass diese Regeln typischerweise nicht greifen und niemand den Arbeitgeber wechselt. Was sich ändert, ist, woran diese Menschen arbeiten.
Es gibt zwei reale Verluste, die benannt werden sollten. Der Engineer, der der einzige Wissensträger war, verliert eine Form von Status, und das braucht ein persönliches Gespräch mit ihm. Die Organisation verliert außerdem etwas Optionalität, weil die Entscheidung rückgängig zu machen jetzt eine Termination-Assistance-Phase erfordert.
Es gibt auch einen Gewinn, der der üblichen Erwartung widerspricht. Die europäische IT-Sourcing-Studie von Whitelane Research fand, dass der wichtigste Grund, warum Organisationen Arbeit wieder ins Haus holen, der Erhalt des eigenen Schlüsselwissens ist, genannt von 53 % der Befragten. Ein richtig durchgeführter Übergang erzeugt das Gegenteil. Phase 1 erzeugt meist das erste vollständige, korrekte Inventar der Integrationslandschaft, das die Organisation je besessen hat, und diese Dokumentation sollte vertraglich Eigentum des Kunden sein.
Was mit Ihrer Plattformlizenz passiert
Sie bleibt eine Weile, und aus ihr herauszukommen ist der Sinn der Übung. Lizenzen für Integrationsplattformen sind Laufzeitabonnements, üblicherweise nach Cores oder virtuellen Cores bemessen, mit getrennter Behandlung von Produktions- und Vorproduktionsumgebungen. Am ersten Tag zu ändern, wer die Plattform betreibt, ändert nichts daran, was Sie vertraglich dafür zu zahlen haben, also erscheint die Ersparnis nicht im ersten Monat. Sie erscheint zur Verlängerung, sobald die Flows in Phase 4 auf die Infrastruktur des Anbieters umgezogen sind und der Verbrauch hinter der Lizenz tatsächlich gesunken ist.
Das gibt dem Übergang seine Sequenzierungsregel. Planen Sie rückwärts vom Verlängerungstermin. Verantwortung verlagern, Flows aufnehmen, tatsächlichen Verbrauch messen, dann die Lizenz reduzieren oder beenden. Kapazität zu kürzen, bevor Phase 4 abgeschlossen ist, ist ein zuverlässiger Weg, einen Ausfall zu erzeugen, mit einem gestoppten Geschäftsprozess daran, der dann dem Übergang angelastet wird.
Die Lizenz ist auch der kleinste Teil dessen, was wegfällt. Plattformadministration, Monitoring, Incident Response und Änderungsarbeit gehen mit ihr, und die sitzen in der Gehaltsabrechnung, wo sie schwerer zu sehen und größer als das Abonnement sind. Unsere Aufschlüsselung der wahren Kosten von Unternehmensintegrationen, oben verlinkt, stellt den vollständigen Stack dar.
Was passiert, wenn Sie gehen wollen
Das sollte bei Vertragsunterzeichnung geklärt sein, weshalb es in Phase 0 sitzt. Termination-Assistance-Phasen in realen Outsourcing-Verträgen laufen üblicherweise von 90 Tagen bis zu einem Jahr. Unter 90 Tagen ist knapp für alles operativ Bedeutsame. Die Dauer zählt weniger als die daran hängende Artefaktliste. Diese Liste sollte Quell-Flows und Konfiguration, Feld-Mappings und Transformationslogik, das Inventar der Zugangsdaten, Runbooks, Monitoring- und Alerting-Konfiguration sowie die Incident-Historie benennen.
Es lohnt sich auch, zwei Arten von Abhängigkeit zu unterscheiden. Plattform-Lock-in ist technisch und teuer aufzulösen, in der oben beschriebenen Größenordnung von sechs bis zwölf Monaten. Betreiber-Lock-in ist vertraglich und löst sich innerhalb der Termination-Assistance-Phase auf. Die zweite ist eine wesentlich günstigere Abhängigkeit als die erste, und dieser Unterschied ist das eigentliche Argument dafür, den Betreiber zu wechseln und die Plattform in Ruhe zu lassen.
Wie lange es dauert und was es kostet
ISGs Analyse von Managed-Services-Übergängen beziffert einen typischen Übergang auf fünf bis sechs Monate, bei Kosten von drei bis vier Prozent des Gesamtvertragswerts, wobei die personelle Abdeckung durch den Anbieter von über 50 % während des Wissenstransfers auf über 75 % während des Shadowings und 100 % beim Reverse-Shadowing steigt. ISG merkt außerdem an, dass ungefähr auf jeden Managed-Services-Vertrag, der problemlos läuft, einer kommt, der schlecht läuft.
Zwei Dinge folgen daraus für die Planung. Integrationsbetriebsübergänge liegen am kürzeren Ende dieser Spanne, weil der Umfang enger ist als ein vollständiger IT-Tower. Und die Besetzungsleiter ist der eigentliche Kostentreiber, weil beide Parteien mehrere Wochen lang für dieselbe Arbeit finanziert werden. Diese Phase gehört in den Business Case, und meist taucht sie stattdessen im zweiten Monat auf.
Behandeln Sie jede Behauptung eines Unternehmensübergangs in 30 bis 60 Tagen mit Vorsicht. Sie ist in Marketingmaterial kleinerer Managed-IT-Services üblich und mehrfach schneller als der einzige verfügbare Analysten-Benchmark.
Wann das nicht die richtige Wahl ist
Wenn Ihre Integrationslandschaft klein, stabil, intern und bereits dokumentiert ist, fügt ein Übergang Governance-Overhead hinzu, ohne viel Arbeit zu entfernen. Wenn Integration für Ihre Organisation tatsächlich ein Differenzierungsmerkmal ist und Sie die Fähigkeit im Haus haben wollen, ist es eine vertretbare strategische Entscheidung, sie zu behalten. Und wenn Sie mitten in einer Plattformmigration stecken, beenden oder stoppen Sie diese zuerst, denn eine Migration und einen Übergang gleichzeitig zu fahren macht die Zuordnung jedes Ausfalls unmöglich.
Der Fall wird stärker mit der Größe der Landschaft, der Zahl der beteiligten externen Parteien, der Änderungsrate der angebundenen Systeme und dem Grad, in dem das interne Team bereits der Engpass ist. Unser Leitfaden dazu, welche IT-Services ausgelagert werden sollten, behandelt die übergeordnete Entscheidung.
Fazit zur Verlagerung des Integrationsbetriebs zu einem Managed Service
Der Wechsel ist eine Verantwortungsübertragung, die Integration für Integration erfolgt, nach einem Wellenplan ohne einzelnes Go-live-Datum. Die Zuverlässigkeit verbessert sich, sobald der Eskalationspfad nicht mehr auf Ihr Team zeigt, und das Business spürt das vor der IT, in Prozessen, die laufen, und Kunden, die nichts mehr bemerken. Kosten fallen später weg, wenn die Flows auf der Infrastruktur des Anbieters liegen und Ihre eigene Lizenz, Administration und Betriebsaufwand den Run Rate verlassen.
Drei Dinge entscheiden darüber, ob es funktioniert, und alle drei werden vor Beginn des Onboardings entschieden. Exit-Bedingungen, die bei Unterzeichnung geschrieben werden. Ein Phase-1-Inventar, das ehrlich genug ist, um den Umfang zu ändern, wenn nötig. Und eine Verantwortungsteilung, die die umstrittenen Punkte explizit benennt, einschließlich der Frage, wem Flows gehören, die Ihre eigenen Entwickler nach dem Go-live bauen.
Alles andere ist Terminplanung, und der Zeitplan sollte rückwärts vom Verlängerungstermin Ihrer Plattform laufen.
Nicht sicher, wo Ihre Integrationsebene steht? Das Integration Ops Reifegrad-Assessment gibt Ihnen eine strukturierte Einschätzung zu Ownership, Monitoring und Change-Bereitschaft in Ihrer gesamten Systemlandschaft.
