InSyca IT Solutions GmbH

04/06/2026

Vor dem Go-Live hatten wir ehrlich gesagt eine ziemlich klare Erwartung. Nach einer Migration verschwindet Komplexität normalerweise nicht einfach. Sie verlagert sich. Neue Plattform, neue Prozesse, neue Abläufe – und meistens entstehen an anderer Stelle neue Fragen. Deshalb sind wir davon ausgegangen, dass die ersten Monate vor allem eines bringen würden: Supportfälle.

Umso überraschter waren wir nach dem Abschalten des letzten BizTalk-Prozesses. Die neue Plattform läuft inzwischen seit rund sechs Monaten produktiv und rückblickend hatten wir weniger Supportfälle als vorher. Nicht weil plötzlich alles perfekt geworden ist und auch nicht, weil Azure irgendein magisches Problem gelöst hätte.

Rückblickend glauben wir eher, dass der Unterschied an einer ganz anderen Stelle lag. Während der Migration haben wir Prozesse nicht einfach kopiert. Wir haben sie hinterfragt, vereinfacht und an vielen Stellen bewusst neu gedacht. Genau das merkt man später im Alltag.

Denn am Ende zeigt sich die Qualität einer Architektur nicht beim Go-Live, sondern Monate später im Betrieb. Und manchmal erkennt man Erfolg nicht daran, was neu dazugekommen ist – sondern an den Dingen, die plötzlich nicht mehr passieren.

Im nächsten und letzten Beitrag geht es um die wichtigste Erkenntnis der gesamten Reise. Und überraschenderweise hat sie nur wenig mit Technologie zu tun.

03/06/2026

Während der Migration gab es einen Effekt, den wir anfangs überhaupt nicht auf dem Schirm hatten. Je mehr Prozesse nach Azure umgezogen sind, desto häufiger tauchte eine ganz praktische Frage auf: Wie kommen Kunden, Lieferanten oder Partner eigentlich an Informationen?

Über die Jahre hatte sich ein Muster entwickelt, das wahrscheinlich viele kennen. Sobald irgendwo etwas unklar war, wurde gefragt: Wurde die Nachricht verarbeitet? Welcher Status liegt vor? Ist etwas schiefgelaufen? Und irgendwann wurde uns klar, dass das eigentliche Problem oft gar nicht fehlende Informationen waren.

Das Problem war die Abhängigkeit.

Denn jedes Mal jemanden fragen zu müssen, erzeugt Wartezeiten, Rückfragen und unnötige Schleifen. Also haben wir angefangen, Informationen und Funktionen kontrolliert nach außen bereitzustellen – nicht als technische Spielerei, sondern damit Partner und Stakeholder Dinge selbst nachvollziehen konnten, ohne auf Rückmeldungen angewiesen zu sein.

Rückblickend war die Erkenntnis überraschend einfach: Viele Supportanfragen entstehen nicht durch Fehler. Sie entstehen, weil Transparenz fehlt.

Im nächsten Beitrag geht es um etwas, das uns nach dem Go-Live selbst überrascht hat: Warum es plötzlich weniger Supportfälle gab als früher.

02/06/2026

Während der Migration ist uns noch etwas aufgefallen, das anfangs ziemlich harmlos wirkte.

Über fast zehn Jahre hatten sich unzählige Regeln angesammelt. Manche waren fachlich wichtig, andere historisch gewachsen und einige existierten einfach deshalb, weil sie irgendwann einmal sinnvoll waren.

Das Problem war nicht die Regel selbst.

Das Problem war, wo sie lebte.

Denn über Jahre wandern Entscheidungen oft direkt in Systeme. Irgendwann steckt Fachlichkeit in Konfigurationen, Plattformfunktionen oder fest eingebauter Logik. Und plötzlich wird aus einer kleinen Änderung ein eigenes Projekt.

Je länger wir Prozesse hinterfragt haben, desto häufiger kam dieselbe Frage auf:

Muss diese Entscheidung wirklich fest im System verankert sein?

Oder braucht sie einfach einen Ort, an dem sie sich kontrolliert ändern lässt?

Rückblickend war das eine überraschend wichtige Erkenntnis. Denn je geschäftskritischer Prozesse werden, desto wichtiger wird nicht nur Stabilität.

Sondern auch Veränderbarkeit.

Im nächsten Beitrag geht es um etwas, das wir anfangs völlig unterschätzt haben:

Warum API Management plötzlich mehr wurde als nur ein Gateway.

28/05/2026

Während der Migration gab es eine Entscheidung, über die wir anfangs selbst kurz gestolpert sind.

Je mehr Transparenz wir aufgebaut haben, desto häufiger kamen Rückfragen aus den Fachbereichen. Nicht technische Fragen, sondern ganz praktische: Wo finde ich eine bestimmte Nachricht? Was wurde an einen Geschäftspartner gesendet? Was genau ist bei einer Reklamation passiert?

Unsere erste Reaktion war ziemlich naheliegend. App Insights, Logs, Dashboards – technisch gab es genug Möglichkeiten. Aber irgendwann wurde uns klar, dass wir gerade ein IT-Problem lösen wollten, obwohl die eigentliche Frage eine ganz andere war.

Die Menschen wollten keine Telemetriedaten durchsuchen und keine Plattform verstehen. Sie wollten einfach Antworten.

Also haben wir die Nachrichten strukturiert nach System, Geschäftspartner und Prozess abgelegt. Stakeholder konnten sich den Pfad sogar lokal einbinden und Informationen direkt dort finden, wo sie ohnehin täglich arbeiten.

Rückblickend war die Erkenntnis überraschend einfach:

Nicht jede gute Lösung muss besonders modern wirken.

Manchmal ist die beste Lösung einfach die, die Menschen ohne Erklärung sofort verstehen.

Im nächsten Beitrag geht es um etwas, das wir während der Migration komplett neu denken mussten:

Warum Konfiguration plötzlich wichtiger wurde als feste Regeln.

27/05/2026

Eine Sache haben wir während der Migration komplett unterschätzt: Transparenz.

Am Anfang dachten wir, die eigentlichen Herausforderungen liegen in der Architektur, der Migration oder den Prozessen selbst. Aber je mehr Prozesse wir Schritt für Schritt aus der alten Plattform herausgelöst haben, desto öfter kamen im Alltag Fragen auf, die wahrscheinlich jeder kennt, der geschäftskritische Integrationen betreibt:

Ist die Nachricht angekommen? Wurde sie verarbeitet? Was passiert gerade im System?

Und irgendwann ist uns aufgefallen, dass diese Fragen eigentlich etwas anderes aussagen. Sie zeigen vor allem, dass man versucht zu verstehen, was im Hintergrund gerade passiert.

Solange wenige Prozesse laufen, funktioniert das noch. Aber wenn täglich tausende geschäftskritische Abläufe darüber laufen, reicht ein einfaches „läuft“ irgendwann nicht mehr aus.

Relativ früh wurde uns klar, dass wir nicht einfach eine neue Plattform aufbauen wollten. Wir wollten einen Zustand schaffen, in dem nachvollziehbar ist, was passiert – nicht erst dann, wenn etwas schiefläuft, sondern jederzeit.

Rückblickend war das wahrscheinlich eine der größten Veränderungen überhaupt. Denn aus einem eher reaktiven Supportmodell wurde Schritt für Schritt ein Betrieb, bei dem deutlich mehr Transparenz und Kontrolle entstanden ist.

Im nächsten Beitrag geht es um eine Entscheidung, die uns selbst überrascht hat:

Warum wir plötzlich wieder angefangen haben, über Dateifreigaben nachzudenken.

26/05/2026

Während der Migration gab es einen Moment, der zunächst völlig unspektakulär wirkte – und sich später als ziemlich interessante Erkenntnis herausgestellt hat.

Je tiefer wir Prozesse auseinandergenommen haben, desto häufiger sind wir auf Dinge gestoßen, die seit Jahren einfach liefen. Nicht, weil sie bewusst irgendwann als optimale Lösung entworfen wurden, sondern weil sie sich über die Zeit etabliert hatten.

Systeme haben geprüft, ob neue Daten da sind. Gewartet. Wieder geprüft. Nochmal gewartet.

Und ehrlich gesagt hinterfragt man das irgendwann nicht mehr. Solange etwas stabil läuft, wirkt es plötzlich ganz normal.

Bis man anfängt, wirklich hinzusehen.

Irgendwann saßen wir zusammen und stellten uns eine erstaunlich einfache Frage:

Warum beschäftigen wir Systeme eigentlich dauerhaft damit festzustellen, dass gerade nichts passiert?

Je länger wir darüber gesprochen haben, desto klarer wurde: Viele Integrationen sind permanent aktiv, obwohl fachlich oft überhaupt keine Aktivität stattfindet.

Und plötzlich war das keine technische Diskussion mehr.

Denn jedes dauerhaft laufende System erzeugt Betrieb, Aufmerksamkeit und Komplexität. Und genau diese Dinge wachsen über Jahre oft still mit, ohne dass sie jemand wirklich bemerkt.

Ab diesem Punkt haben wir angefangen, Prozesse anders zu betrachten. Nicht mehr mit der Frage:

„Wer schaut regelmäßig nach?“

Sondern eher:

„Wer meldet sich, wenn wirklich etwas passiert?“

Klingt erstmal nach einem kleinen Unterschied.

Rückblickend hat genau diese Denkweise aber erstaunlich viel verändert.

Im nächsten Beitrag geht es um etwas, das wir anfangs komplett unterschätzt haben:

Warum Transparenz plötzlich wichtiger wurde als Funktionen.

21/05/2026

Einer der spannendsten Momente kam überraschend früh.

Nicht bei der Infrastruktur.

Nicht bei Azure.

Sondern bei einer einfachen Frage:

Was migrieren wir hier eigentlich wirklich?

Denn sobald man tiefer einsteigt, merkt man schnell: Man migriert selten nur Technologie.

Man migriert Gewohnheiten.

Architekturen.

Und manchmal sogar Abhängigkeiten, die über Jahre ganz selbstverständlich geworden sind.

Plötzlich standen Fragen im Raum, über die vorher kaum jemand nachgedacht hatte:

Brauchen wir dafür wirklich eine spezielle Plattformfunktion?

Brauchen wir proprietäre Designer?

Brauchen wir Spezialwissen, das nur wenige Menschen beherrschen?

Oder lösen wir eigentlich ein Problem, das vor zehn Jahren entstanden ist?

Und genau dort kam eine Erkenntnis, die ich rückblickend extrem spannend finde:

Je geschäftskritischer Systeme werden, desto gefährlicher wird Spezialwissen.

Nicht weil es schlecht ist.

Sondern weil Unternehmen dadurch abhängig werden.

Deshalb haben wir bewusst versucht, Standardwissen stärker zu nutzen: native Entwicklung, bekannte Technologien und Architekturen, die auch in Zukunft einfacher verständlich und erweiterbar bleiben.

Rückblickend ging es dabei nie um BizTalk oder Azure.

Es ging um Kontrolle.

Und darum, Komplexität nicht einfach weiterzuvererben.

Im nächsten Beitrag geht es um eine Entscheidung, die fast alle überrascht hat:

Warum wir plötzlich angefangen haben, mehr auf Events zu setzen – und weniger auf Polling.

20/05/2026

Vor rund einem Jahr dachten wir zunächst, dass wir vor einer klassischen Migration stehen.

BizTalk raus. Azure rein.

Fertig.

Zumindest war das der Plan.

Aber je tiefer wir in die bestehende Landschaft eingestiegen sind, desto deutlicher wurde: Wir migrieren hier nicht einfach eine Plattform.

Wir migrieren zehn Jahre Entscheidungen.

Und genau das war der Punkt, an dem es spannend wurde.

Denn über Jahre entsteht etwas, das fast jede gewachsene Plattform irgendwann entwickelt:

Kleine Sonderwege.
Zusätzliche Regeln.
Workarounds.
Historische Entscheidungen.

Nichts davon ist falsch.

Jede einzelne Entscheidung hatte irgendwann ihren Grund.

Aber plötzlich stellt man sich eine unbequeme Frage:

Brauchen wir das heute überhaupt noch?

Und genau hier haben wir eine Entscheidung getroffen, die sich später als einer der größten Erfolgsfaktoren herausgestellt hat:

Wir wollten nicht einfach BizTalk nach Azure verschieben.

Wir wollten bewusst vermeiden, alte Probleme in eine neue Plattform mitzunehmen.

Denn neue Technologie löst keine alten Entscheidungen.

Sie macht sie oft nur teurer.

Im nächsten Beitrag geht es um einen Punkt, der uns dabei überrascht hat:

Warum Plattformmigration am Ende weniger mit Technik zu tun hatte als gedacht.

19/05/2026

Die schwierigsten Entscheidungen trifft man selten, wenn Systeme ausfallen.

Sondern dann, wenn sie noch funktionieren.

Vor etwas mehr als einem Jahr standen wir vor genau so einer Entscheidung: Was machen wir mit einer geschäftskritischen BizTalk-Landschaft?

Der Auslöser war dabei nicht Technologie. Es war Wirtschaftlichkeit.

Der Kunde hatte eine klare Entscheidung getroffen: weg von eigener Infrastruktur, weg von hohen Betriebs- und Lizenzkosten, hin zu einer zukunftsfähigen Cloud-Architektur.

Klingt zunächst nach einer typischen Plattformmigration.

War es aber nicht.

Denn hinter BizTalk hing nicht einfach irgendein Integrationssystem. Rund 50 Systeme und Partner waren angebunden. Täglich liefen tausende geschäftskritische Prozesse über diese Plattform – von Logistik und Lagerwirtschaft bis hin zu Qualitätssicherung, Auftragsverwaltung und CO₂-Reporting.

Kurz gesagt:

Wenn hier etwas stehen bleibt, bleibt nicht die IT stehen.

Dann steht das Geschäft.

Und genau dort kam eine Erkenntnis, die ich rückblickend für wichtiger halte als jede Technologieentscheidung:

Die größte Gefahr war nicht die Veränderung.

Die größere Gefahr war Stillstand.

Denn geschäftskritische Plattformen fallen selten plötzlich aus.

Sie werden über Jahre einfach immer schwieriger zu verändern – bis irgendwann niemand mehr anfassen möchte, was eigentlich längst angefasst werden müsste.

Vor rund sechs Monaten haben wir den letzten BizTalk-Prozess abgeschaltet.

Und genau an diesem Punkt haben wir die erste Entscheidung getroffen, die sich später als entscheidender Erfolgsfaktor herausstellen sollte.

Mehr dazu im nächsten Beitrag.

17/05/2026

Es gibt diese Momente in Integrationsprojekten, die man kaum erklären kann.

Wenn nach Tagen oder Wochen plötzlich alles zusammenkommt. Systeme sprechen miteinander. Daten fließen. Prozesse laufen einfach. Kein Copy & Paste mehr, keine Excel-Listen, keine Medienbrüche.

Für Außenstehende wirkt das oft unspektakulär.

Für Menschen aus unserer Welt ist es fast Magie. 😉

Genau darüber durfte ich in einem Podcast mit Detlef Korus sprechen: über Integrationsprojekte, Erfahrungen aus der Praxis und warum ich bis heute Freude daran habe, wenn aus vielen einzelnen Bausteinen plötzlich ein funktionierendes Ganzes wird.

Integration bedeutet für mich mehr als Schnittstellen. Es geht darum, Unternehmen ein Stück einfacher zu machen.

🎧 Hier geht’s zum Video:
https://www.youtube.com/watch?v=4gGk5c2aCgU

Mich würde interessieren:
Welcher Moment in einem Projekt gibt euch das Gefühl: „Dafür mache ich den Job“?

Iwe Kardum und Detlef Korus über Systeme, die niemand mehr verstehtDas System läuft. Aber du weißt nicht mehr, warum.Das ist keine Ausnahme. Das ist der Norm...