Wer eine Anwendung von Vaadin 8 auf 24 migrieren will, begründet das fast immer technisch. Die alte Version läuft aus, Sicherheit und Wartbarkeit leiden, also muss etwas passieren. Diese Gründe reichen für eine Budgetfreigabe.

Nach mehreren solchen Migrationen sehen wir einen weiteren Effekt, der in keinem Antrag stand: Die Anwendungen sind danach für ihre Nutzer deutlich besser bedienbar.

Ein Praxisfall: 300.000 Codezeilen und 5.000 Klassen

Eines dieser Projekte war eine Anwendung für das Beteiligungsmanagement mit 300.000 Codezeilen und 5.000 Java-Klassen. Die alte Version stammte aus dem Jahr 2017, und so sah die Oberfläche auch aus. Nach der Migration wirkt sie modern, frisch und aufgeräumt.

Der sichtbare Unterschied war nur ein Teil des Ergebnisses. Vier Verbesserungen waren für den Kunden entscheidend:

• Mehr Sicherheit. Die alte Version brauchte kostenpflichtigen Legacy-Support, die neue nicht mehr.
• Die Anwendung passt sich an alle Bildschirmgrößen an und ist jetzt auch auf dem Smartphone nutzbar.
• Sie ist kompatibel zu WCAG, den Richtlinien für barrierefreie Webinhalte, und zum Barrierefreiheitsstärkungsgesetz (BFSG).
• Neue Komponenten und Funktionen des Frameworks sind wieder nutzbar.

Zwei dieser Punkte sind mehr als Technik. Eine Anwendung, die auf dem Smartphone funktioniert, erreicht auch Nutzer, die nicht am Arbeitsplatzrechner sitzen. Und bei der Barrierefreiheit geht es um gesetzliche Anforderungen. Ob das BFSG für eine bestimmte Anwendung gilt, ist eine rechtliche Frage im Einzelfall. Eine Oberfläche, die technisch darauf vorbereitet ist, macht die Antwort aber deutlich einfacher.

Welche Optionen es gibt, wenn eine Version ausläuft, und wie sie sich wirtschaftlich vergleichen lassen, beschreibt der Beitrag Software am Lebensende.

Was das Team nach einem Jahr Migrationen gelernt hat

Im Jahresgespräch sind wir die Vaadin-Migrationen des vergangenen Jahres durchgegangen. Was lief gut, was haben wir gelernt, wie starten wir die anstehenden Migrationen auf Vaadin 25? Erwartet hatten wir technisches Feedback und technische Planung. Das Fazit des Teams ging darüber hinaus: Seit der Migration von Vaadin 8 auf Vaadin 24 läuft die Entwicklung deutlich flüssiger, und es entstehen spürbar schönere und benutzerfreundlichere Oberflächen.

Konkret nannte das Team vier Effekte:

• Die Entwicklung läuft flüssiger, Änderungswünsche kommen schneller beim Anwender an.
• Oberflächen lassen sich besser für unterschiedliche Bildschirmgrößen gestalten.
• Das Framework bringt modernere Bedienelemente von Haus aus mit.
• Am Ende stehen spürbar bessere Anwendungen für die Nutzer.

Eine technische Notwendigkeit kommt damit direkt bei den Menschen an, die täglich mit der Software arbeiten. Zwischen „angenehm zu entwickeln“ und „schön zu benutzen“ muss man nicht wählen.

Warum gerade Vaadin

Vaadin ist seit Jahren einer unserer Schwerpunkte. Die gesamte Entwicklung findet in Java statt, ohne den Mix aus HTML, CSS, mehreren JavaScript-Frameworks und REST-Schnittstellen: ein Stack, ein Team, ein Arbeitsablauf. Für datengetriebene Business-Anwendungen sehen wir keine effizientere Lösung. Die Entwicklung braucht weniger Aufwand als etwa mit Angular und Spring Boot, und die gewonnene Zeit fließt in den Nutzen für die Anwender. Wann sich diese Bauweise lohnt und wann nicht, steht im Beitrag Vaadin oder Angular.

Dem Anwender ist der Technologie-Stack allerdings gleichgültig. Er will eine Oberfläche, die funktioniert, ordentlich aussieht und sich ohne lange Einarbeitung bedienen lässt. Genau dort zahlt sich die Migration aus.

Vaadin 8 auf 24 migrieren: den Nutzen ins Budget holen

Für Budgetverantwortliche ist das ein praktisches Argument. Eine Migration wird bisher vor allem über Risiken begründet: Ende der Unterstützung, Sicherheitslücken, steigende Wartungskosten. Das ist stichhaltig, wirkt im Fachbereich aber oft abstrakt, weil ein Risiko, das noch nicht eingetreten ist, schwer zu spüren ist. Eine Oberfläche, die besser funktioniert, sieht dagegen jeder.

Zur ehrlichen Einordnung gehört eine Grenze. Die Verbesserungen betreffen Darstellung, Bedienkomfort und Entwicklungstempo. Fachliche Abläufe ändern sich durch eine Migration nicht. Wer neue Prozesse will, braucht dafür ein eigenes Vorhaben.

Für die Planung empfehlen wir drei Schritte:

1. Vor dem Start die Anwender fragen, welche Bedienprobleme sie seit Jahren melden. Diese Liste zeigt, wo die Migration den größten Nutzen stiften kann.
2. Im Angebot trennen, was die Migration ohnehin mitbringt und was bewusst zusätzlich an der Oberfläche umgebaut wird. Wie viel Verbesserung beim Anwender ankommt, hängt davon ab, wie viel der Oberfläche im Projekt angefasst wird.
3. Die Anwendung vorher vermessen lassen: Codeumfang, Anteil eigener Komponenten, Zahl der Bildschirmmasken, Stand der Tests. Die Zahl der Codezeilen allein sagt wenig über den Aufwand. Entscheidend ist, wie viel davon an der Oberfläche hängt und wie viel Fachlogik unverändert bleiben kann.

Solange die Migration nicht abgeschlossen ist, bleibt ein kostenpflichtiger Legacy-Support ein laufender Posten, der in diese Rechnung gehört.

Fazit

Wer eine Anwendung von Vaadin 8 auf 24 migrieren will, tut das meist aus technischen Gründen und bekommt mehr als erwartet: mehr Sicherheit, Nutzbarkeit auf dem Smartphone, Barrierefreiheit und spürbar bessere Oberflächen. Wer diesen Nutzen von Anfang an mitplant, kann die Migration nicht nur mit Risiken begründen, sondern mit besseren Arbeitsplätzen für die Anwender.