Wassertreten in drei Odoos – wie Kneipp Österreich online ging

Namen von Personen und Vereinen sind weggelassen. Die Zahlen sind aus der Datenbank, die Pannen sind echt – und ja, ein paar davon gehen auf mich.

Der Trailer (für Eilige)

Der Österreichische Kneippbund hat seit dem 24. September 2026 ein neues Mitgliedersystem. Rund 23.500 aktive Mitglieder, gut 200 Vereine, ein Büro, das alles zusammenhält – und ein Altsystem, das nach vielen Jahren in Pension gegangen ist. Das ist die Geschichte dazwischen.

• Wir hatten nicht ein Altsystem, sondern drei Odoos: eines, das führte, eines, das Daten einsammelte, und eines, das irgendwann übernehmen sollte. Die meiste Arbeit war nicht das Bauen, sondern die Frage, wer gerade recht hat.
• Der Go-Live war ein einziger Tag mit dreizehn Arbeitssitzungen. Am Abend stellte sich heraus, dass kein Verein ein Mitglied öffnen konnte – und zwar schon seit einer Woche. Es hatte nur noch niemand probiert.
• In der Woche danach kamen über 40 Versionen dazu. Nicht weil alles kaputt war, sondern weil endlich echte Menschen damit gearbeitet haben – und echte Menschen klicken anders als Testkonten.

Wer nur die Technik sehen will, springt ans Ende zu den Hardfacts.

Drei Odoos und ein Kneipp-Becken

Sebastian Kneipp hat Menschen ins kalte Wasser geschickt, damit sie gesünder herauskommen. Genau so fühlt sich eine Datenmigration an, nur ohne Handtuch.

Das Ausgangsbild: Das alte System lief seit Jahren auf Odoo 12 und war die Wahrheit. Daneben stand ein Odoo 16, in dem die Vereine per Fragebogen ihre Daten ergänzt hatten – Geburtsdaten, Funktionen, Kontakte. Und dann gab es das neue Odoo 18, das irgendwann beides ablösen sollte. Damit das neue System nicht veraltet, lief ein Abgleich: alle fünf Minuten vom alten ins neue.

Drei Systeme, ein Abgleich, eine Regel – das klingt beherrschbar. Es ist ungefähr so beherrschbar wie drei Uhren in einer Wohnung, von denen eine vorgeht, eine nachgeht und eine stehen geblieben ist, aber mit sehr überzeugtem Gesichtsausdruck.

Eine Frage hat uns von Anfang bis Ende begleitet: Welches System hat recht? Bei den Geburtsdaten war es das Fragebogen-System, beim Mitgliedsstatus das alte, bei den Zahlungen – dazu gleich mehr. Wir haben gelernt, diese Frage pro Feld zu stellen, nicht pro System.

Board-Archäologie

Das Projekt hatte ein Aufgaben-Board, wie sich das gehört. Als ich im Juli zum ersten Mal ernsthaft durchgegangen bin, standen dort 62 offene Karten. Elf davon waren längst erledigt. Die Funktion lief, das Büro nutzte sie, nur die Karte war nie weitergewandert. Das Board war kein Plan mehr, sondern ein Museum für gute Absichten.

Seitdem gibt es eine Regel, die ich jedem Projekt empfehle: Bevor man eine Aufgabe baut, schaut man nach, ob sie nicht schon da ist. Am echten System, nicht im Ticket.

Im Code war es ähnlich. In einer Klasse fanden sich zwei Methoden mit demselben Namen. Die zweite überschrieb die erste still, und die erste – die das Beitrittsdatum automatisch setzen sollte – lief deshalb nie. Vermisst hatte es niemand. Das ist die tückischste Sorte Fehler: der, der aussieht wie ein Feature, das es nie gab.

Der Abgleich, der alles besser wusste

Im August haben wir den Vereinen eine schöne Seite gebaut: „Wer hat bezahlt?“ Große Zeilen, ein Klick pro Mitglied, bezahlt oder offen. Die Vereine sollten ihre Beiträge selbst pflegen.

Das Problem: Der Abgleich aus dem alten System lief weiter, alle fünf Minuten, und das alte System war für Zahlungen der Chef. Jeder Klick eines Vereins wurde also nach spätestens fünf Minuten höflich, aber bestimmt zurückgesetzt. Die schöne Seite war in Wahrheit eine Anzeige mit Knöpfen ohne Wirkung. Wir haben die Knöpfe ausgebaut und einen ehrlichen Hinweis dazugeschrieben.

Ein paar Tage später fiel uns auf, dass die ganze Beitragsübersicht für niemanden sichtbar war. Sie hing an einer Berechtigungsgruppe, und diese Gruppe hatte genau null Mitglieder. Es war die sicherste Funktion des ganzen Systems.

Seit dem Go-Live gilt dafür eine Regel, die im Projekt-Gedächtnis fett markiert ist: Der Zahlungsabgleich aus dem alten System wird nie wieder eingeschaltet. Er würde jede Zahlung, die ein Verein im neuen System erfasst, auf „offen“ zurückdrehen. Das alte System ist jetzt Archiv, und Archive haben keine Meinung mehr.

Zwei Länder, ein Ordner

Auf demselben Server lief auch die deutsche Kneipp-Schwester. Zwei Instanzen, zwei Datenbanken – aber ein gemeinsamer Ordner mit dem Programmcode. Jede Korrektur für Österreich war damit automatisch auch eine Änderung für Deutschland, ob Deutschland wollte oder nicht.

Am 8. September haben wir das getrennt. Seitdem hat jedes Land seinen eigenen Code-Ordner und seinen eigenen Zweig in der Versionsverwaltung. Es war ein Tag mit dem schönen Namen „Sanierungs- und Trennungstag“, und er hat sich angefühlt wie eine Scheidung, bei der beide Seiten erleichtert sind.

Ganz vorbei war es trotzdem nicht. Einen Tag nach dem Go-Live stellten wir fest, dass ein deutsches Modul bei jedem neu angelegten Mitglied eine Begrüßungsmail verschicken wollte: „Willkommen beim Kneipp-Bund e.V.“, inklusive Beitragsrechnung. Für ein österreichisches Mitglied eines österreichischen Vereins ist das ungefähr so passend wie ein Brief vom falschen Finanzamt. Die erste dieser Mails stand schon in der Warteschlange. Wir haben sie vor dem Versand gestoppt und die Automatik für Österreich abgeschaltet. Seitdem prüfen wir bei jeder neuen deutschen Automatik zuerst, ob sie Mitglieder anschreibt.

Und dann war da noch das Netzwerk: Ein Dienst auf dem Server schrieb ab und zu still die DNS-Einstellungen zurück. Die Folge waren Mails, die nicht rausgingen, weil der Server kurz vergessen hatte, wo das Internet wohnt. Heute gibt es feste Einstellungen und einen Wiederholungsjob, der liegen gebliebene Mails nachschickt.

Der 24. September

Der Go-Live-Tag hatte dreizehn Arbeitssitzungen. Die Liste, ungefähr in dieser Reihenfolge:

• die neue Adresse für das Mitgliedersystem freigeschaltet,
• den Testzugang mit Kennwort-Schranke abgebaut und den Server gehärtet,
• das alte System eingefroren, eine vollständige Kaltkopie gezogen, ein Lesearchiv unter einer eigenen Adresse aufgebaut und den alten Server stillgelegt,
• für jede Person, die einen Verein betreut, einen eigenen Zugang angelegt – statt der alten Sammelkonten pro Verein,
• drei rein lesende Prüf-Durchgänge mit getrennten Blickwinkeln: Empfänger, Daten und Rechte, Betrieb,
• und dann die Einladungen verschickt. Rund 150 Stück.

Am Abend habe ich mich selbst als Verein angemeldet und ein Mitglied geöffnet. Ergebnis: ein Zugriffsfehler auf die Buchhaltung. Eine Woche vorher hatten wir den Vereinen das Leserecht auf Buchungen entzogen – sie sollten keine Rechnungen anderer sehen, völlig vernünftig. Nur rechnet das Mitglieds-Formular beim Öffnen ein paar Werte aus genau dieser Buchhaltung aus, und ohne Leserecht bricht das ganze Formular ab. Unsere Prüfungen hatten Listen und Menüs getestet, aber kein einziges Formular. Der Fix war klein: Leserecht zurück, aber mit einer Regel, die keinen einzigen Datensatz zeigt. Die Lektion war größer: Rechte nie nur am Code prüfen, sondern als echter Vereinsnutzer, mit Liste und Formular.

Die Woche danach

Am Go-Live-Tag stand das Kernmodul auf Version 1.47. Sechs Tage später stand es auf 1.91. Ein paar Beispiele, was dazwischen passiert ist:

• Die Maske, mit der das Büro neue Zugänge anlegt, hatte eine gut gemeinte Voreinstellung: „bisherigen Zugang ablegen“. Wer eine zweite Person für einen Verein dazunahm, hat damit die erste still hinausgeworfen. Erwischt hat es unter anderem unser eigenes Testkonto, was zumindest den Vorteil hatte, dass es uns aufgefallen ist.
• Die geführten Touren, die den Vereinen das neue System zeigen sollten, starteten für Vereine nie. Ein Türsteher im System ließ nur Adressen durch, die auf seiner Liste standen, und die Tour-Adresse stand nicht drauf. Das Fehlerbild im Browser: nichts. Keine Meldung, keine Tour, einfach Stille.
• Der interne Systembenutzer bekam plötzlich E-Mails. Weil er deaktiviert ist, behandelte ihn das System wie einen externen Kontakt und schrieb ihm fleißig Benachrichtigungen an eine Adresse, die es nicht gibt.
• Ein Verein trug seinen neuen Vorstand ein, klickte dabei auf die Namen statt sie auszuwählen und überschrieb so sechs bestehende Mitglieder mit den Daten des neuen Vorstands. Wir haben die sechs aus der Sicherung vom Go-Live-Tag zurückgeholt, Feld für Feld, und die Maske so umgebaut, dass man dort nur noch auswählen kann.
• Und mein Agent, der aus dem Beitrag über das „Restore nach Rausflug“, hat dem Büro einmal mitgeteilt, eine Antwort sei nicht verschickt worden. Sie war verschickt. Er hatte neben der richtigen Nachricht einen leeren Protokolleintrag angesehen. Wir haben uns entschuldigt und es korrigiert. Seitdem schaut er beim Nachprüfen auf die Zustellung, nicht auf die letzte Zeile.

Dazwischen kamen die Wünsche, für die man so ein Projekt eigentlich macht: Etiketten im richtigen Format, Haushalte, die nur einen Brief bekommen, eine Liste „Daten prüfen“, die Ungereimtheiten aufzeigt, bevor sie jemand auf Papier druckt, ein Knopf „Wieder aktivieren“ und eine Übersicht, wer schon angemeldet war und wer noch nie.

Und heute

Seit dem Go-Live läuft jede Nacht um halb sechs Uhr früh ein Rundgang: Ein Testverein und ein Testbüro klicken die wichtigsten Wege durch, nur lesend. Findet er etwas, landet eine Aufgabe auf meinem Board.

Heute habe ich mir die Fehler im Server-Protokoll angesehen. 37 Stück, alle gleich, alle um halb sechs. Die Ursache war der Rundgang selbst. Er ging an der Eingangstür vorbei direkt in den Server, und dort gibt es für die Live-Verbindung keinen Anschluss. Die Vereine waren nie betroffen, die kommen durch die Tür. Jetzt kommt auch der Rundgang durch die Tür und prüft dabei gleich mit, ob die Live-Verbindung steht. Beim Aufräumen fiel uns außerdem eine Testkopie der Datenbank auf, die seit dem 30. September friedlich auf dem Produktivserver mitlief. Sie ist jetzt weg.

Das ist, glaube ich, die ehrlichste Zusammenfassung eines Go-Lives: Am Ende findet man die meisten Fehler bei sich selbst.

Was bleibt

• Das alte System einfrieren, nicht ewig synchronisieren. Ein Abgleich, der weiterläuft, ist eine zweite Meinung, die nie schlafen geht.
• Pro Feld klären, wer recht hat. Nicht pro System.
• Rechte immer als echter Nutzer testen. Mit Liste, mit Formular, mit dem Zoom, den die Leute in den Vereinen wirklich eingestellt haben.
• Für jede Panne ein Rückweg. Sicherung vor jedem Schritt, und ein Rezept, wie man aus der Sicherung einzelne Datensätze zurückholt, ohne den Rest anzufassen.
• Das Büro ist kein Abnahme-Gremium, sondern das eigentliche Testteam. Über 40 Versionen in sechs Tagen waren kein Zeichen von Chaos, sondern von Leuten, die das System sofort ernsthaft benutzt haben.

Die Kneipp-Idee stammt aus der Mitte des 19. Jahrhunderts. Das neue System ist ein paar Tage alt. Wenn die beiden sich so gut vertragen wie in der ersten Woche, bin ich zufrieden. Kalt angefangen, warm angekommen.

---