Das Palisis Backoffice wird auf Angular neu aufgebaut. Kein erzwungener Umstieg, keine Geschäftsunterbrechung — modulweise, im Parallelbetrieb.
Das Palisis Backoffice ist der operative Kern für Reise- und Tour-Operator — Buchung, Ticketing, Ressourcenplanung und Reporting laufen darüber. Es basierte auf Google Web Toolkit (GWT), einem Framework, das Java zu JavaScript kompilierte und dem Produkt jahrelang gute Dienste leistete.
Mit der Zeit engten die strukturellen Grenzen von GWT das Produkt ein: monolithische Bundles, DOM-Trägheit, Framework-Obsoleszenz und ein stetig schrumpfender Talentpool. Noch war nichts kaputt — genau deshalb war frühes Handeln entscheidend.
Die aktive Entwicklung kam faktisch zum Erliegen, die Community wurde dünner — das Framework auf einem langsamen Weg in die Obsoleszenz.
Responsive Layouts, dynamische Komposition und interaktive Overlays bedeuteten, gegen das Framework zu arbeiten statt mit ihm.
Das Kompetenzprofil war eng, der Kreis verfügbarer Entwicklerinnen und Entwickler wurde kontinuierlich kleiner.
Angular — wegen der komponentenbasierten Architektur und der aktiven LTS-Roadmap. Das Frontend wurde per API-Verträgen vom Spring-Backend entkoppelt.
GWT- und Angular-System laufen gleichzeitig produktiv. Nutzer werden nie auf unfertige Oberflächen gezwungen.
Jedes Modul wird vollständig verstanden, bevor es neu gebaut wird — jede GWT-Annahme wird hinterfragt statt übernommen.
v14 → v15 → v16 → v17 → v18, ohne eine Version zu überspringen. Die Fähigkeiten jedes Releases werden bewusst aufgenommen.
Jedes GWT-Modul wird neu gebaut und validiert, bevor es abgeschaltet wird. Vollständiger Cutover geplant für Ende 2025.
| Aspekt | Vorher (GWT) | Nachher (Angular) |
|---|---|---|
| Frontend-Framework | Google Web Toolkit (Entwicklung eingestellt) | Angular v18 (aktives LTS) |
| Bundle-Modell | Monolithisches Kompilat | Modular, lazy-loaded |
| Release-Kadenz | Rebuilds des Gesamtsystems | Einzelne Feature-Rollouts |
| Backend-Kopplung | Gemeinsam kompiliert (Java → JS) | Entkoppelt über API-Verträge |
| Modul-Komposition | Undurchsichtiger Widget-Baum | Komponentenbasiert, testbar |
| UX-Grenze | Gegen das Framework arbeiten | Komposition als Standard |
Die aktive Entwicklung an GWT war faktisch eingestellt und die Community ausgedünnt. Moderne UX-Anforderungen liessen sich nur gegen das Framework umsetzen, und der Markt für diese Kompetenz wurde laufend kleiner. Nichts war kaputt — genau deshalb war der frühe Umbau der risikoärmere Weg.
Nein. GWT und Angular laufen parallel in Produktion, die Migration erfolgt Modul für Modul. Niemand wird auf eine unfertige Oberfläche gezwungen.
Auf Angular v18, erreicht über v14, v15, v16 und v17 im Quartalsrhythmus und ohne ausgelassene Version — jede Release-Fähigkeit wurde aufgenommen, als sie verfügbar war, statt in einem Sprung.
Das Frontend wurde über explizite API-Verträge vom Spring-Backend entkoppelt. Beide entwickeln und veröffentlichen seither in eigenem Takt — das war ein Ziel der Arbeit, kein Nebeneffekt.
