University of Jena: Vue 3 Migration

Problem & constraints

Friedrich-Schiller-Universität Jena’s web presence spans more than a hundred departments. My slice of it was the Physikalisch-Astronomische Fakultät: nine institute websites, from the Astrophysical Institute and University Observatory to the Otto Schott Institute of Materials Research and the Fraunhofer Institute for Applied Optics and Precision Engineering (IOF).

The sites ran on Vue 2, which was approaching end of life, and every year of growth made the codebase harder to maintain. The framework wasn’t the only problem: a shared component library existed, but adoption across the sites was inconsistent (some teams used it, some didn’t), so it had drifted into an obsolete, chaotic state with per-site variants of the same UI.

Two constraints shaped everything. The sites had to stay live throughout; a university can’t take its institutes offline for a rewrite. And this was a cross-functional team (backend developers, UI/UX designers, DevOps engineers), so the migration had to move without blocking anyone else’s work. The Vue migration itself, its testing, and the component library were my responsibility.

Architecture

These were not SPAs. Each institute site was a multi-page application with Vue mounted where interactivity was needed, on dashboards and interactive components, built with Webpack. State lived in Vuex, and data came over RESTful APIs (via Axios) from a plain Java backend. The shared component library sat across all nine sites.

The migration itself ran in a separate repository: the codebase was converted there, incrementally and under test, while production stayed untouched. Only once the converted code was thoroughly tested did it replace the live sites; there was never a cutover of a half-migrated codebase. The decisions behind it are logged below, each with the alternative it beat.

Outcomes

Tree-shaking and Vue 3’s smaller runtime cut the JavaScript bundle by 40%. Accessibility improved to WCAG compliance through ARIA attributes and semantic HTML, and Cypress-based integration tests, introduced together with the team, gave the migration end-to-end coverage.

Just as important were the structural wins: the platform could keep up with current Vue features again, old hand-rolled logic was replaced with well-supported Vue ecosystem addons, the component library was consistent and current across all nine sites, and the codebase came out of the migration noticeably cleaner than it went in.

Lessons

If I did it again, I would convert everything to the Composition API and leave no Options API behind. Keeping the stable sections felt pragmatic at the time, but a mixed-style codebase carries a quiet cost: every future upgrade and every new contributor has to deal with two mental models, and the leftover Options code is exactly where future friction will surface. The incremental, separate-repo strategy, on the other hand, I would repeat without hesitation: it’s what let nine live university sites migrate frameworks with no drama.