Was ist OpenImmo und warum ist es relevant?

Ein seit Jahren etabliertes XML-Format, in dem praktisch jede deutsche Immobiliensoftware ihre Objektdaten exportiert. Genau deshalb ist es der richtige Ansatzpunkt: Statt für jedes Maklerprogramm eine eigene Anbindung zu bauen, genügt eine Verarbeitung für das Format, das sie alle beherrschen.

Warum ein eigener Container pro Auftrag?

Wegen der Abschottung. Objektexporte sind fremde Dateien aus fremden Systemen, oft mit unerwarteten Inhalten. Ein Auftrag, der in seinem eigenen kurzlebigen Container läuft, kann bei einem Fehler weder andere Kunden noch den Dienst selbst mitreißen — und der Speicher wird mit dem Container ohnehin wieder frei.

Warum FTP für die Datenannahme?

Weil die Maklerprogramme es können. Eine technisch modernere Schnittstelle nützt nichts, wenn sie voraussetzt, dass der Kunde seine Fachsoftware wechselt. Die Anbindung muss dort andocken, wo die Daten heute schon hinauslaufen — nicht dort, wo es dem Entwickler besser gefiele.

Was spart so eine Automatisierung konkret?

Den doppelten Pflegeaufwand und die Fehler, die dabei entstehen. Wie viel das in Stunden ist, hängt vom Objektbestand ab — belastbare Zahlen dazu liegen mir für diesen Kundenkreis noch nicht vor, deshalb steht hier keine.

Live

Wenn dieselbe Handarbeit jede Woche wieder anfällt

Maklerbüros pflegen ihre Objekte in einer Fachsoftware und danach ein zweites Mal auf der eigenen Website. ImmoSync liest die Standard-Exportdateien dieser Programme und hält die Website automatisch synchron — pro Auftrag in einem eigenen Container, der danach wieder verschwindet.

Projekt ansehen

Belegte Zahlen

Commits: 382Quelle: git log, 24.02.2026 bis 12.07.2026
Betriebsvarianten: 3Quelle: docker-compose.yml, .production.yml und .vps.yml, Stand 11.08.2026
Automatisierte Auslieferungen: Bei jedem MergeQuelle: .github/workflows/deploy.yml

Ausgangslage

Immobiliensoftware exportiert Objektdaten in einem Branchenformat, das seit Jahren Standard ist. Websites können damit trotzdem nichts anfangen, also werden Objekte doppelt gepflegt: einmal im Fachprogramm, einmal von Hand auf der Website. Das kostet jede Woche Zeit und führt zuverlässig zu Beständen, die auseinanderlaufen.

Ergebnis

Ein laufender Dienst unter eigener Domain, der Exportdateien entgegennimmt und Objektbestände synchron hält. Die eigentliche Verarbeitung läuft in kurzlebigen Containern, die pro Auftrag gestartet und danach verworfen werden — ein fehlerhafter Datenbestand eines Kunden kann damit keinen anderen beeinflussen.

Das Problem ist Doppelpflege, nicht fehlende Technik

Immobiliensoftware kann exportieren. Websites können importieren. Trotzdem pflegen viele Büros ihre Objekte zweimal — weil zwischen dem Exportformat und dem, was eine Website versteht, niemand vermittelt.

Das Ergebnis ist der klassische Zustand, den man in vielen kleinen Unternehmen findet: eine Aufgabe, die jede Woche anfällt, die niemand gern macht, die niemandem gehört, und bei der Fehler erst auffallen, wenn ein Kunde nach einem Objekt fragt, das längst verkauft ist.

Der Ansatzpunkt war das Format, nicht die Software

Es gibt viele Maklerprogramme. Für jedes eine eigene Anbindung zu bauen, wäre Arbeit ohne Ende. Sie exportieren aber alle in dasselbe Branchenformat.

Also setzt die Verarbeitung am Format an, nicht am Programm. Das ist der Unterschied zwischen einem Produkt und einer Reihe von Einzelanbindungen: Ein neuer Kunde mit einer anderen Software braucht im Normalfall keine neue Entwicklung.

Aus demselben Grund läuft die Datenannahme über FTP. Nicht, weil es modern wäre, sondern weil die Fachprogramme es können. Eine Schnittstelle, die voraussetzt, dass der Kunde seine Software wechselt, wird nicht benutzt.

Warum jeder Auftrag seinen eigenen Container bekommt

Der Dienst verarbeitet fremde Dateien aus fremden Systemen. Solche Dateien sind regelmäßig anders, als die Spezifikation es vorsieht: unerwartete Zeichensätze, fehlende Pflichtfelder, Bilder mit kaputten Verweisen, gelegentlich absurde Größen.

Statt das im Hauptdienst abzufangen, startet der Manager pro Auftrag einen eigenen kurzlebigen Container und verwirft ihn danach. Ein Auftrag, der scheitert, reißt weder andere Kunden noch den Dienst mit — und der belegte Speicher verschwindet mit dem Container.

Das ist die Architekturentscheidung, die dieses Projekt am ehesten von einem Skript unterscheidet.

Was hier ehrlicherweise fehlt

Kundenzahlen und eingesparte Arbeitsstunden. Beides wären die überzeugendsten Zahlen dieser Case Study, und beides kann ich derzeit nicht belegen. Was belegbar ist, steht oben: der Umfang der Arbeit, die Betriebsvarianten und die automatisierte Auslieferung.

Eine Zahl, die ich nicht belegen kann, schreibe ich nicht hin — auch dann nicht, wenn sie sich gut lesen würde.

Häufige Fragen

Was ist OpenImmo und warum ist es relevant?: Ein seit Jahren etabliertes XML-Format, in dem praktisch jede deutsche Immobiliensoftware ihre Objektdaten exportiert. Genau deshalb ist es der richtige Ansatzpunkt: Statt für jedes Maklerprogramm eine eigene Anbindung zu bauen, genügt eine Verarbeitung für das Format, das sie alle beherrschen.
Warum ein eigener Container pro Auftrag?: Wegen der Abschottung. Objektexporte sind fremde Dateien aus fremden Systemen, oft mit unerwarteten Inhalten. Ein Auftrag, der in seinem eigenen kurzlebigen Container läuft, kann bei einem Fehler weder andere Kunden noch den Dienst selbst mitreißen — und der Speicher wird mit dem Container ohnehin wieder frei.
Warum FTP für die Datenannahme?: Weil die Maklerprogramme es können. Eine technisch modernere Schnittstelle nützt nichts, wenn sie voraussetzt, dass der Kunde seine Fachsoftware wechselt. Die Anbindung muss dort andocken, wo die Daten heute schon hinauslaufen — nicht dort, wo es dem Entwickler besser gefiele.
Was spart so eine Automatisierung konkret?: Den doppelten Pflegeaufwand und die Fehler, die dabei entstehen. Wie viel das in Stunden ist, hängt vom Objektbestand ab — belastbare Zahlen dazu liegen mir für diesen Kundenkreis noch nicht vor, deshalb steht hier keine.

← Alle Referenzen