veren.
Serie Fixes · 04

Die Integration, die ihren Server überlebt hat

„Die Integration läuft einwandfrei. Das Problem ist, dass das Hosting, auf dem sie läuft, nächsten Monat abgeschaltet wird, und die Person, die sie gebaut hat, ist nicht mehr da.“
AutorVictor Daj
Veröffentlicht24. Februar 2026
Lesezeit5 Min. Lesezeit
Geschrieben fürLeitung Marketing Operations oder IT in einem regulierten Konzern

Die E-Mail, mit der die Uhr zu laufen beginnt

Die Mitteilung kommt selten von jemandem, mit dem man verhandeln könnte. Eine Hosting-Umgebung wird stillgelegt, eine Konzern-IT konsolidiert ihre Plattformen, oder ein Dienstleister stellt einen Service ein. Die Nachricht enthält ein Datum und keinen Absender, der dieses Datum verschieben könnte. Irgendwo in dieser Umgebung läuft eine Integration, über die seit Jahren niemand nachgedacht hat, weil sie nie Anlass dazu gegeben hat. Leads landen dort, wo sie hingehören. Die Datensätze auf beiden Seiten bleiben synchron. Es passiert einfach.

Jetzt haben Sie einen Termin, den Sie nicht gesetzt haben, für ein System, das Sie nicht gebaut haben, und die Person, die es gebaut hat, ist nicht mehr im Unternehmen. Die Integration ist nicht defekt. Sie verliert demnächst ihr Zuhause, und aufgefallen ist das Ihnen.

Dass sie läuft, heißt nicht, dass jemand sie verantwortet

Eine Integration, die seit Jahren ohne Beanstandung läuft, sieht aus wie ein Vermögenswert. Genauer: einer, den niemand verwaltet. Sie wurde als Projektergebnis gebaut, abgenommen und nie in einen Service überführt, den jemand betreibt. Das Hosting hat einmal jemand ausgesucht, der gerade greifbar war, und danach nie wieder jemand hinterfragt. Die Dokumentation, sofern es sie gibt, beschreibt, wie die Integration gebaut wurde, und nicht, wie sie sich im Betrieb verhält: was sie tut, wenn ein Datensatz die Validierung nicht besteht, was sie tut, wenn die Gegenseite nicht erreichbar ist, wer davon erfährt.

Die eigentliche Lücke ist die Verantwortung. Die Integration sitzt zwischen zwei Systemen, und jeder der beiden geht davon aus, dass der andere für die Mitte zuständig ist. Solange alles fließt, ist das unsichtbar. An dem Tag, an dem es stoppt, erklären zwei Personen, dass der Fehler auf der jeweils anderen Seite liegt, und der Vertrieb fragt, wo die Leads dieser Woche geblieben sind.

Der Umzug ist also nur die halbe Arbeit. Die andere Hälfte ist ein Verantwortlicher, der erreichbar ist.

Inventur vor dem Umzug

Ziehen Sie nichts um, bevor Sie vier Fragen zur Integration schriftlich beantworten können.

  1. Welche Datensätze. Nicht die Objektnamen aus der ursprünglichen Spezifikation, sondern was heute tatsächlich übertragen wird: welche Entitäten, welche Felder, und welche davon unterwegs umgewandelt werden. Ziehen Sie eine Stichprobe aus dem letzten Monat und vergleichen Sie sie mit der Spezifikation. Meist weichen sie voneinander ab.
  2. Welche Richtung. In eine Richtung, in beide Richtungen, oder in eine Richtung mit Ausnahmen. Ein Abgleich in beide Richtungen hat Konfliktregeln, und die gibt es oft nur im Kopf einer einzelnen Person.
  3. Wie oft. Zeitgesteuert, ereignisgesteuert oder gemischt. Ein nächtlicher Batchlauf und ein Trigger in Echtzeit schlagen auf unterschiedliche Weise fehl und werden unterschiedlich überwacht.
  4. Was bei einem Fehler passiert. Wiederholen, in die Warteschlange stellen, verwerfen oder alarmieren. Wer erhält den Alarm heute, und arbeitet diese Person noch für Sie.

Die Antworten werden zu den Abnahmekriterien für den Umzug. Ohne sie heißt „läuft auf dem neuen Hosting“ nur „bisher hat sich niemand beschwert“, und genau so sind Sie hierhergekommen.

Umzug mit festem Termin

Gefragt werden wir zuerst, ob es vor dem Termin zu schaffen ist. Die Antwort ist ja, wenn drei Dinge zutreffen. Die Inventur oben existiert oder lässt sich in der ersten Woche erstellen. Jemand auf Ihrer Seite kann Zugang zu beiden Systemen und zur alten Umgebung gewähren, ohne dass die Anfrage einen Monat durch Ticketsysteme läuft. Und die alte Umgebung bleibt lange genug erreichbar, damit beide parallel laufen können, denn bis zur Abnahme ist sie Ihre Rückfallebene.

Wir behandeln Migration und Stabilisierung als ein Arbeitspaket mit einem Abnahmepunkt, nicht als Projekt und danach ein Supportgespräch. Abnahme heißt nicht „ausgerollt“. Abnahme heißt: Die Datensätze aus der Inventur werden in der erwarteten Richtung und nach dem erwarteten Zeitplan übertragen, und ein absichtlich ausgelöster Fehler erzeugt den Alarm an die benannte Person. Diese Prüfung braucht die alte Umgebung im Betrieb, also liegt die Abnahme vor dem Abschaltdatum. Planen Sie von der Abnahme rückwärts, nicht von der Mitteilung vorwärts.

Nach der Umstellung

Der Tag der Umstellung sagt Ihnen sehr wenig. Zeitgesteuerte Jobs brauchen mehrere Durchläufe, bevor man ihnen trauen kann, und Monatsabschlussprozesse zeigen sich erst zum Monatsende. Behandeln Sie die Zeit nach dem Umzug als eigene, benannte Phase, die Stabilisierung: Jemand beobachtet die Logs und die Alarme, statt zu warten, bis es einem Anwender auffällt. Die Integration hinter diesem Beitrag lief produktiv, und die Abnahme erfolgte am Ende der Stabilisierungsphase, nicht am Tag der Umstellung.

Der Einwand an dieser Stelle ist meist das Budget: Es gibt keine Position für eine laufende Supportvereinbarung. Für diesen Notfall gab es auch keine, und von beiden ist der Notfall der teurere und kommt zum ungünstigeren Zeitpunkt. Die Rechnung dazu steht in Supportstunden, die verfallen.

Damit der nächste Fall langweilig wird

Zwei Dinge machen aus der nächsten Abschaltungsnachricht eine Aufgabe statt einer Krise.

Das erste ist ein Übergabedokument, das das Verhalten im Betrieb beschreibt und nicht die Bauweise: welche Datensätze übertragen werden, in welche Richtung, nach welchem Zeitplan, wer die Zugangsdaten verwaltet, wie sich jeder Fehlerfall von außen zeigt, wen man anruft, und an welchem Datum das alles zuletzt jemand überprüft hat. Dieses letzte Feld verändert das Verhalten: Ein Prüfdatum, das sich seit Jahren nicht bewegt hat, ist selbst der Alarm. Die Vorlage unten ist die, die wir übergeben.

Das zweite ist ein erreichbarer Verantwortlicher. Wenn das Ihr eigenes Team ist, sind das Dokument und die Fehlerfälle genau das, was es braucht. Wenn nicht, ist unseres ein vorab bezahltes Stundenkontingent mit einem festen Ansprechpartner, das nicht verfällt. Eine Fehlerbehebung, eine Änderung an der Infrastruktur oder eine weitere Integration werden aus demselben Kontingent bedient, sodass keine Zeit mit der Frage verloren geht, ob eine Aufgabe als Support oder als Änderung zählt. Für den Einkauf: eine Vereinbarung statt einer monatlichen Pauschale, und nichts, was Ihr eigenes Team daran hindert, später zu übernehmen.

Quellprojekt: ein europäischer Pharmakonzern.

Dazu gehört · Vorlage

Übergabevorlage für Integrationen

Eine Seite pro produktiver Integration mit Systemen und Richtung, Datensätzen und Feldern, Zeitplan, Verantwortlichem für die Zugangsdaten, Fehlerfällen, Eskalationskontakt und dem Datum, an dem sie zuletzt jemand überprüft hat.

Interaktiv. Füllen Sie es direkt auf der Seite aus, das Ergebnis aktualisiert sich laufend, und Ihre Antworten bleiben in Ihrem Browser.

Vorab bezahlte Supportstunden, die nicht verfallen.

Ein Kontingent und ein fester Ansprechpartner, damit die nächste Frage eine Aufgabe ist und keine Verhandlung. Es funktioniert auch, wenn Sie nur den Umzug brauchen und Ihr eigenes Team danach übernimmt.

Ebenfalls in dieser Serie
Ein pragmatischer Einstieg

Den richtigen KI-Einstieg finden.

Business Case, Governance und erste Umsetzung abstimmen – ohne direkt ein Großprogramm zu starten.

Kurze Anfrage

Wie erreichen wir Sie?

Dauert etwa zwei Minuten.